Feature #4902
open
Better logging when Interest & Data don't match
0%
Description
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.
As Junxiao pointed out, this is a bug in the producer for responding with a prefix when the interest didn't allow it. But it's NFD that has the info that this mismatch has occurred -- it looks up the prefix, finds the pending interest, and decides that the two can't be paired. At that point it would be really easy to log a warning to that effect, or at least a debug/trace level message.
Updated by Junxiao Shi over 5 years ago
Currently Pit type has no logging at all. This should be addressed during the refactoring for Packet03Transition.
Trying to determine why a Data does not match a PIT entey would add a lot of complexity.
What the PIT could do is printing the Interest as URI rather than just a name. It would be something like:
[Pit] /A/B/1 non-match=/A/B
[Pit] /A/B/1 non-match=/A/B/1/sha256digest=xxxx
[Pit] /A/B/1 match=/A/B?cbp=1
The default is cbp=0 so you still see nothing on the first line, but a trained eye would know “cbp=1” is needed for a prefix match.
On the other hand, the library could issue a warning when the producer replies to an Interest with a Data that does not satisfy the Interest. This would require a change to Face::put API: instead of face.put(data), the invocation should be face.put(interest, data), i.e. the producer needs to tell the library which Interest it is replying to.
Updated by Davide Pesavento over 5 years ago
- Category set to Tables
- Start date deleted (
04/01/2019) - Estimated time deleted (
0.50 h)
Updated by Fred Douglis over 5 years ago
Junxiao Shi wrote:
Currently
Pittype has no logging at all. This should be addressed during the refactoring for Packet03Transition.Trying to determine why a Data does not match a PIT entey would add a lot of complexity.
I wasn't aware this would be as difficult as it is, but I like that idea, and hope you can implement.
On the other hand, the library could issue a warning when the producer replies to an Interest with a Data that does not satisfy the Interest. This would require a change to
Face::putAPI: instead offace.put(data), the invocation should beface.put(interest, data), i.e. the producer needs to tell the library which Interest it is replying to.
I actually like this idea a lot. Right now, you can potentially have multiple interests that match some data, and letting a producer be explicit as to what is intended for what can't hurt. And it would simplify NFD, since instead of doing "best match" it could just jump to the pending interest.
Updated by Davide Pesavento over 5 years ago
Fred Douglis wrote:
Junxiao Shi wrote:
On the other hand, the library could issue a warning when the producer replies to an Interest with a Data that does not satisfy the Interest. This would require a change to
Face::putAPI: instead offace.put(data), the invocation should beface.put(interest, data), i.e. the producer needs to tell the library which Interest it is replying to.I actually like this idea a lot. Right now, you can potentially have multiple interests that match some data, and letting a producer be explicit as to what is intended for what can't hurt. And it would simplify NFD, since instead of doing "best match" it could just jump to the pending interest.
That would be the PIT token (#4532). An API such as put(interest, data) would allow pushing the PIT token processing from NFD to each application (or library). The problem is that NFD still has to do it until all apps are converted to the new API. Or we could use a feature flag to turn this on/off for each app independently.
Updated by Davide Pesavento over 5 years ago
- Subject changed from Better debugging info when Interest & Data don't match properly to Better logging when Interest & Data don't match properly
Updated by Davide Pesavento over 5 years ago
- Subject changed from Better logging when Interest & Data don't match properly to Better logging when Interest & Data don't match