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

[Lan Wang (lanwang)]

Fred,

Thank you very much for the feedback.  I think both are excellent points.  Could you file the corresponding redmine issues?

Lan

On Mar 27, 2019, at 4:18 PM, Fred Douglis <fdouglis at perspectalabs.com<mailto:fdouglis at perspectalabs.com>> wrote:


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=>
--
<signature.png>
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20190328/db5d5be1/attachment-0001.html>