<div dir="ltr">Hi Junxiao,<div><br></div><div>I found this problem on iOS using an "incorrect" implementation of the FaceStatus Dataset consumer. I'm not sure how to reproduce this error on normal computers yet. But here is a dump of log messages from NFD (this is the best I can get to describe the problem...):</div><div><br></div><div><br>2015-03-19 23:49:20.532 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://<a href="http://127.0.0.1:6363">127.0.0.1:6363</a>,remote=tcp4://<a href="http://127.0.0.1:51868">127.0.0.1:51868</a>] Received: 63 bytes <br><br>2015-03-19 23:49:20.532 NFD[5139:69230] DEBUG: [Forwarder] onIncomingInterest face=257 interest=/localhost/nfd/faces/list?ndn.ChildSelector=1&ndn.InterestLifetime=1000&ndn.Nonce=1313767654&ndn.Exclude=...,%FD%00%00%01L5%F1K%21 <br><br>2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] find /localhost/nfd/faces/list R <br><br>2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1K%21 <br><br>2015-03-19 23:49:20.533 NFD[5139:69230] TRACE: [ContentStore] find-under-prefix /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF <br><br>2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [ContentStore] matching /localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 <br><br>2015-03-19 23:49:20.533 NFD[5139:69230] DEBUG: [Forwarder] onOutgoingData face=257 data=/localhost/nfd/faces/list/%FD%00%00%01L5%F1%3D%BF/%00%00 <br><br>2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://<a href="http://127.0.0.1:6363">127.0.0.1:6363</a>,remote=tcp4://<a href="http://127.0.0.1:51868">127.0.0.1:51868</a>] sendData <br><br>2015-03-19 23:49:20.534 NFD[5139:69230] TRACE: [TcpLocalFace] [id=257,local=tcp4://<a href="http://127.0.0.1:6363">127.0.0.1:6363</a>,remote=tcp4://<a href="http://127.0.0.1:51868">127.0.0.1:51868</a>] Successfully sent: 724 bytes <br><br>2015-03-19 23:49:20.637 NFD[5139:69230] DEBUG: [Forwarder] onInterestFinalize interest=/localhost/nfd/faces/list satisfied<br><div class="gmail_quote"><br></div><div class="gmail_quote">You can see that I sent an Interest with exclude filter of [ANY, %FD%00%00%01L5%F1K%21]. But somehow NFD decided to match this interest to the data with suffix "%FD%00%00%01L5%F1%3D%BF/%00%00". Note that "%FD%00%00%01L5%F1K%21" is larger than "%FD%00%00%01L5%F1%3D%BF" because 'K' == 0x4B. So this data should have been filtered out...</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">Wentao</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, Mar 19, 2015 at 10:49 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Wentao<div><br></div><div>As of NFD:commit:eab7249b74d4819f9dc32e2f2d12d392f36acdc1:</div><div><ul><li>Cs::find returns an Entry only if Entry::canSatisfy returns true; this condition is checked in both Cs::findLeftmost and Cs::findRightmostAmongExact.</li><li>Entry::canSatisfy returns true only if Interest::matchesData returns true.</li><li>Interest::matchesData evaluates the Exclude Selector.</li></ul></div><div><br></div><div>If you have a problematic case, please open a Bug on NFD Redmine site.<br></div><div>The Bug report should contain a concise code snippet or tcpdump trace that reproduces the problem.<br></div><div><br></div><div>Yours, Junxiao</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 19, 2015 at 10:28 PM, Wentao Shang <span dir="ltr"><<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi team,<div><br></div><div>When I was testing NFD on iOS, I noticed that NFD doesn't seem to handle Exclude filter correctly in CS lookup. I looked into the code and noticed that in ./daemon/table/cs.cpp, the Cs::find method only handles the child selector but never checks the exclude filter. And I suspect this is a bug. Can someone verify whether this is a real issue or the exclude filter is actually checked somewhere else? If it's a "feature not a bug", I wonder what is the reason behind the design decision to leave out exclude filter in CS lookup.</div><div><br></div><div>Thanks,</div><div>Wentao</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu" target="_blank">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
<br></blockquote></div></div></blockquote></div></div></div>