NFD » ndn-cxx

First, I will reject this one unless someone convinces me that there is such an app that really needs to generate more than 1000 signed interests.

Second, for app that may generate two signed interests in a short time, the problem can be easily avoided at the signing side. As in current KeyChain, we forbid assigning the same timestamp to two interests signed by the same key. We keep a soft state for used signing keys to remember the most recently used timestamp, if the timestamp assigned to the next interest happens to be the same as the last one, we will not assign the same timestamp, but assign (last_timestamp + 1).

I do not think the re-ordering problem exists as well. If the order really matters, then the interest sender should wait for the confirmation from the receiver side.

The solution in note-1 is irrelevant to this issue.

The solution in note-2 is same as the first suggested fix. This recommendation should appear in SignedInterest page.

but that is application's own problem, it is not a bug of the library.

It's neither a problem in application or in library. This bug is about the protocol, not any implementation of the protocol.

The protocol should acknowledge the network's lack of in-order delivery guarantee, and provide a recommendation about how to avoid rejected signed Interests due to out-of-order delivery.

There is no protocol of signed interest. It is just a format. How to use it is up to app...

In case SignedInterest page is a format instead of the protocol, delete the Signed Interest processing section from the page, and describe that in a separate protocol document, along with the stop-and-wait recommendation for consumers.