[Nfd-dev] problem with selector for implicit digest?
Alex Afanasyev
aa at CS.UCLA.EDU
Sun Dec 13 13:35:54 PST 2015
Hi Christian,
Thanks for discovering the issue. Even though we unit test everything and do integration tests for many things, this important function is for some reason got broken.
I have created a follow up redmine ticket (http://redmine.named-data.net/issues/3363) with a simplified scenario to reproduce the problem. We will fix the issue asap.
--
Alex
> On Dec 12, 2015, at 9:10 AM, christian.tschudin at unibas.ch wrote:
>
> Jeff, thanks for this insight.
>
> This seems to indicate that so far digest-based lookup was not used by anyone, and therefore now would be a good moment to revisit that part of the mechanics?
>
> Since the beginning of ccn-lite I thought that the handling of the implicit digest was not elegant and will lead to implementation accidents. Conceptually it is a selector and should be handled there, instead of a name component.
>
> One could even go a step further and reserve a special field for it in the interest (instead of inside the selector block) because it is a knock-out restriction: Any selector then becomes irrelevant.
>
> Thoughts?
>
> best, c
>
>
> On Sat, 12 Dec 2015, Thompson, Jeff wrote:
>
>> I tested in PyNDN and I confirm the same problem: NFD does not match an incoming data
>> packet with an interest in the PIT which has an implicit digest component (but it does
>> match from the content store).
>> Looking at the NFD code, Pit::findAllDataMatches calls
>> m_nameTree.findAllMatches(data.getName(), …) which does a longest prefix match of the
>> data name to the interest name.
>> https://github.com/named-data/NFD/blob/5e5e44518286e89a0092ea0ad93c22e64128bdd2/daemon/t
>> able/pit.cpp#L97
>> But the interest name with the implicit digest component in the PIT is longer than the
>> data name, so how can LPM match it? Should NFD strip the implicit digest component before
>> putting the interest name in the PIT’s name tree?
>> - Jeff T
>> On 2015/12/11, 16:12:07, "Nfd-dev on behalf of christian.tschudin at unibas.ch"
>> <nfd-dev-bounces at lists.cs.ucla.edu on behalf of christian.tschudin at unibas.ch> wrote:
>>
>> I'm hitting a wall with nfd behavior when it comes to the implicit digest.
>> a) What is working correctly:
>> - first retrieve a packet by ordinary name
>> - compute the digest of the received packet
>> - then retrieve the same packet, but this time with the
>> special digest component appended and MaxSuffix=0
>> - this works, the data will probably now be served from the CS
>> (digest is a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d)
>> b) What is not working:
>> - directly retrieve another packet with its (other) name and including
>> the special digest component for that data, and MaxSuffix=0
>> - nfd accepts this request and forwards it upstream
>> - nfd receives that data packet
>> - but the received data is not delivered to the downstream
>> client (timeout of ndnpeek although I can see that nfd
>> received the right packet).
>> (digest is 65d5baf5960a4151ee64f8aa93ed19c90c50932308d3019848f23b2f59bc0623)
>> The content comes in both cases from an upstream node (running
>> ccn-lite), see the topology below.
>> One potential catch is that the two names are almost identical:
>> The name in step a) is
>> /ndn/ch/unibas/repo256/movie7.mp4/_
>> The name in step b) is
>> /ndn/ch/unibas/repo256/movie7.mp4
>> Is this a bug in PIT matching? Or has the second data object an internal
>> problem that lets nfd refuse it (see the attached packet)? Below I also
>> add the command line logs, FYI.
>> Best, christian
>> ---
>> # topology
>>
>> ndnpeek --> nfd (UDP 6363) --> ccn-lite-relay (UDP 3636) --> ccn-lite-repo256
>> (UDP 7777)
>> # case a), showing correct behavior
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v /ndn/ch/unibas/repo256/movie7.mp4/_
>> >pkt-1.bin
>> INTEREST: /ndn/ch/unibas/repo256/movie7.mp4/_
>> DATA, RTT: 5ms
>> tschudin at cs-ndn-testbed1:~$ shasum -a 256 pkt-1.bin
>> a3c19829edf901ff9d1a87f6da82af050a1cc302784b9b18ecd3812deef6795d pkt-1.bin
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
>> 2784b9b18ecd3812deef6795d
>> pkt-2.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/_/sha256digest=a3c19829edf901ff9d1a87f6da82af050a1cc30
>> 2784b9b18ecd3812deef6795d
>> DATA, RTT: 5ms
>> tschudin at cs-ndn-testbed1:~$ cmp pkt-1.bin pkt-2.bin
>> tschudin at cs-ndn-testbed1:~$
>> # case b), showing the error
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
>> 2adf74a4572b100c5f12885 >pkt-3.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie6.mp4/sha256digest=bc5f1a0e0712304cb9790aad2639397c6ad3d01fb
>> 2adf74a4572b100c5f12885?ndn.MaxSuffixComponents=0
>> TIMEOUT
>> tschudin at cs-ndn-testbed1:~$
>> # Log file captured with tcpdump (case b)
>> tschudin at cs-ndn-testbed1:~$ sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or
>> udp port 7777' >traffic.log &
>> [2] 20530
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
>> tschudin at cs-ndn-testbed1:~$ ndnpeek -v -M 0/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
>> 8d3019848f23b2f59bc0623 >pkt-3.bin
>> INTEREST:/ndn/ch/unibas/repo256/movie7.mp4/sha256digest=65d5baf5960a4151ee64f8aa93ed19c90c5093230
>> 8d3019848f23b2f59bc0623?ndn.MaxSuffixComponents=0
>> TIMEOUT
>> tschudin at cs-ndn-testbed1:~$ fg
>> sudo tcpdump -i lo 'udp port 6363 or udp port 3636 or udp port 7777' > traffic.log
>> ^C6 packets captured
>> 12 packets received by filter
>> 0 packets dropped by kernel
>> tschudin at cs-ndn-testbed1:~$ less traffic.log
>> 00:47:08.269244 IP cs-ndn-testbed1.cs.unibas.ch.6363 >
>> cs-ndn-testbed1.cs.unibas.ch.3636: UDP, length 87
>> 00:47:08.270061 IP localhost.3636 > localhost.6363: UDP, length 87
>> 00:47:08.270181 IP localhost.6363 > localhost.3636: UDP, length 100
>> 00:47:08.270362 IP localhost.3636 > localhost.7777: UDP, length 87
>> 00:47:08.271063 IP localhost.7777 > localhost.3636: UDP, length 3862
>> 00:47:08.271227 IP cs-ndn-testbed1.cs.unibas.ch.3636 >
>> cs-ndn-testbed1.cs.unibas.ch.6363: UDP, length 3862
>> traffic.log (END)
>> # log from the ccn-lite relay (which links to the upstream repo256, both running
>> # on the same machine as nfd but using UDP ports 3636 and 7777, respectively)
>> [D] 100.1443: ccnl_core_RX ifndx=0, 87 bytes
>> [D] 100.1443: face 9, peer=192.43.193.111/6363
>> [I] 100.1444: incoming
>> interest=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013
>> from=192.43.193.111/6363
>> [D] 100.1444: searching in CS
>> [D] 100.1446: created new interest entry 0x1364f70
>> (prefix=/ndn/ch/unibas/repo256/movie7.mp4)
>> [D] 100.1446: ccnl_interest_propagate
>> [D] 100.1447: ccnl_interest_propagate, fwd==0x13650d0
>> [I] 100.1447: outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
>> to=127.0.0.1/6363
>> [D] 100.1449: udp sendto(87 Bytes) to 127.0.0.1/6363 returned 87/0
>> [D] 100.1450: ccnl_interest_propagate, fwd==0x100e1f0
>> [I] 100.1450: outgoing interest=</ndn/ch/unibas/repo256/movie7.mp4>
>> to=127.0.0.1/7777
>> [D] 100.1450: udp sendto(87 Bytes) to 127.0.0.1/7777 returned 87/0
>> [D] 100.1450: ccnl_core_RX ifndx=0, 100 bytes
>> [D] 100.1451: face 2, peer=127.0.0.1/6363
>> [I] 100.1457: ndnlp packet
>> [D] 100.1458: ccnl_core_RX ifndx=0, 3862 bytes
>> [D] 100.1458: face 6, peer=127.0.0.1/7777
>> [I] 100.1458: incoming
>> data=</ndn/ch/unibas/repo256/movie7.mp4>[65d5..0623]ndn2013 from=127.0.0.1/7777
>> [I] 100.1458: outgoing data=</ndn/ch/unibas/repo256/movie7.mp4>ndn2013
>> to=192.43.193.111/6363
>> [D] 100.1460: udp sendto(3862 Bytes) to 192.43.193.111/6363 returned 3862/0
>> [D] 100.1460: adding content to cache
>> ---
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20151213/ce184f67/attachment.bin>
More information about the Nfd-dev
mailing list