[Nfd-dev] [EXTERNAL] Re: minor suggestion regarding prefix matching logging in NFD

Fred Douglis fdouglis at perspectalabs.com
Wed Mar 27 14:18:17 PDT 2019


That's an excellent point, in terms of the producer having a bug here.

But, I stand by my comment that it would be helpful for NFD to flag the 
bug when it's encountered.  Here, it's outputting something that says 
"hey, I got a match on a prefix".  That's presumably because until it 
does that lookup, it doesn't know if there is something in the PIT that 
says that prefixes are OK.  So I'm simply suggesting that when it does 
that lookup and finds something, it includes a debug message to the 
effect that it's being ignored because the thing that matched specified 
that prefix matches weren't OK.

Lots of stuff gets logged in NFD.  This seems like the sort of logging 
message that would be useful, IMHO.

Fred

On 3/27/2019 5:08 PM, Junxiao Shi wrote:
> Hi Fred
>
> This isn’t a forwarder problem, but a producer problem. The producer 
> shouldn’t respond to an Interest with a Data that violates CanBePrerix 
> element. If logging is required, it should happen at the producer.
>
> Yours, Junxiao
>
> On Wed, Mar 27, 2019 at 12:41 Fred Douglis <fdouglis at perspectalabs.com 
> <mailto:fdouglis at perspectalabs.com>> wrote:
>
>     I've been using NFD 0.6.3; it's possible this has been changed in
>     a later version, or at least a known issue, so if so please just
>     advise.
>
>     I was trying to do a simple test, using the ndnpeek test
>     application.  I could see that the interest was reaching the
>     producer and making its way back to NFD, but NFD was rejecting it
>     as /unsolicited data/.
>
>     It took me longer than it should have to realize that I'd
>     neglected to include the -P flag.  But when I look at the NFD log,
>     it could definitely be a bit more informative.  It shows that it
>     looks up the name provided in the data and fails, then matches the
>     name provided in the interest.  At which point it says it's an
>     unsolicited data packet.
>
>     I assume what is happening under the covers is that when it
>     matches the prefix, it is looking for the CanBePrefix flag, not
>     finding it, and declaring it to be unsolicited.  A DEBUG or
>     TRACE-level message to that effect would, I think, help what must
>     be a somewhat common occurrence.   Or perhaps there is a further
>     debug level or something else that would already have revealed this?
>
>     Thanks,
>
>     Fred
>
>
>     _______________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>     [lists.cs.ucla.edu]
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cs.ucla.edu_mailman_listinfo_nfd-2Ddev&d=DwMFaQ&c=YC-d702opsuYKpiO2Bmlzg&r=EJmyfY3ULfVHBtsckANZFhs27SCvXVOHQdc0rPAI0ag&m=tGOfLlmVV1CMspBynlg2pOGaZRL3ioY7spC_MAXfvBk&s=-K8qOP2N9ElWEBgAPkUE8-5DEfTf4EWP9cS8yWzCQyo&e=>
>
-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20190327/d1d10334/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.png
Type: image/png
Size: 6913 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20190327/d1d10334/attachment.png>


More information about the Nfd-dev mailing list