Project

General

Profile

Feature #4902

Better logging when Interest & Data don't match

Added by Fred Douglis 12 months ago. Updated 12 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Tables
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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.

History

#1

Updated by Junxiao Shi 12 months 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.

#2

Updated by Davide Pesavento 12 months ago

  • Category set to Tables
  • Start date deleted (04/01/2019)
  • Estimated time deleted (0.50 h)
#3

Updated by Fred Douglis 12 months ago

Junxiao Shi wrote:

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.

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::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.

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.

#4

Updated by Davide Pesavento 12 months 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::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.

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.

#5

Updated by Davide Pesavento 12 months ago

  • Subject changed from Better debugging info when Interest & Data don't match properly to Better logging when Interest & Data don't match properly
#6

Updated by Davide Pesavento 12 months ago

  • Subject changed from Better logging when Interest & Data don't match properly to Better logging when Interest & Data don't match

Also available in: Atom PDF