Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] cf-dev Digest, Vol 9, Issue 6

Indeed, for deduplication, ACK & RST should not be considered at all.

 

Due to the unreliable transport, CoAP must also deal with duplication along the path. Hence, also ACKs and RSTs should be included in the deduplication. However, also see the notes in draft-ietf-lwig-coap on how deduplication can be realized. In Cf, we have enough resources to implement a proper filter at the message layer.

 

About this, I even changed my patch not to call deduplicator.findPrevious() in case of ACK. Furthermore, for repetitions (exchanges initiated by the client), KeyMIDs seem oversized. Raw MIDs should be enough since CF manages a global one for all peers (perfectly specification compliant).

No. MIDs must be managed within their namespace, which is the source endpoint of a CON or NON. A wrong namespace (the remote instead of the local one) is exactly the cause of the bug discussed here.


About contributing, apart from time left by my customer to deliver our C stack, I would be pleased to give back what Cf (and your wonderful Cu !) brought to us, but I feel reticent because:

  1. I'm not used to Git/Github (especially pull requests) and even left Java/Maven for C some years ago (but the last is not a real problem...). Anyway, it could be a reason to start but may be long to get the fix...
  2. I did not study Cf design and even did not explore its API (a colleague did it, then I faced the issue). Hence, any fix would be "blind". If I prepare a pull request, will there be some kind of harness ? Regression testing ?

The behavior described here must definitely be added as a unit test for the matcher.
Pull requests are reviewed by the committers and we usually provide feedback to improve pull-requests until they are ready to merge. The continuous integration with Hudson already tells us, if all tests pass after the patch.

However, I can understand your concerns. Cf has become very big and fixes are applied much more efficient when there is already knowledge about the architecture.

Best regards
Matthias


Back to the top