Hi,
Thank you for the pointer. I will read it carefully but it already
reminded me that de-duplication was a CoAP tricky part...
Reading again at your first message, I understand that you propose
to add the "origin" in the KeyMID and continue to put the exchange
found in exchangesByToken in the deduplicator to deduplicate
ACKs (that would be then correctly filtered by the origin) ?
But in our case, with no other change, the keyMID would
always contain the same source (the server address), same mid
(because of client/server collision), potentially the same token
(nothing prevents to use the same token for successive requests, am
I wrong ?) and even the same LOCAL origin (since all request were
initially sent from the Cf client) ? In my opinion, in order to
work, every sent request would then also have to be added to the
deduplicator, for instance with the local address.
Our idea was to use deduplication only for exchanges from remote
origin, and then forget deduplication for ACKs (a non-matching ACK
will simply be ignored). I did not find requirements in the
specification to process ACK duplicates. Do you have a pointer on
the subject ?
About the other point, which was another subject in fact, what I was
trying to tell, is that as generated mids are managed globally
(variable currendMID), segmenting exchanges by destination
in exchangesByMid was not really necessary. The namespace
for generated mids is in fact the local endpoint (except if I made a
mistake and if the map contains all exchanges, even "remote" ones),
so that does not break your rule ? But it was an embedded C remark,
focusing on optimization. This can allow detecting bad peer
implementations.
Don't bother if I'm all wrong, you surely better know CoAP than I do
and will find the best fix for Cf.
Best regards,
Stéphane ROUGES
|
|
Phone:
Mobile:
Fax:
Address:
|
+33 9 72 32 80 99
+33 6 51 98 34 64
+33 9 72 32 79 17
6, avenue Lulli - 92310 SEVRES - FRANCE
|
Contact us for any kind
of support about XML/EXI, embedded Web Services and DPWSCore software.
Le 22/04/2015 10:53, Kovatsch Matthias
a écrit :
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:
-
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...
-
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
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
|
