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
Hi Matthias,

You got it. Your diagram makes it perfectly clear.

Indeed, for deduplication, ACK & RST should not be considered at all. 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).

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 ?
Thanks for all,

Stéphane

Le 22/04/2015 06:56, cf-dev-request@xxxxxxxxxxx a écrit :
Send cf-dev mailing list submissions to
	cf-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
	https://dev.eclipse.org/mailman/listinfo/cf-dev
or, via email, send a message with subject or body 'help' to
	cf-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
	cf-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cf-dev digest..."


Today's Topics:

   1. Re: Potential bug... (Kovatsch  Matthias)


----------------------------------------------------------------------

Message: 1
Date: Wed, 22 Apr 2015 04:56:08 +0000
From: "Kovatsch  Matthias" <kovatsch@xxxxxxxxxxx>
To: "Californium (Cf) developer discussions" <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] Potential bug...
Message-ID:
	<55877B3AFB359744BA0F2140E36F52B535534A45@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hi

Let me try to fully understand the issue:

A Cf client sends a request that results in a separate response:

Client                  Server
  |                       |
  |---CON, MID: 0x1234--->|
  |<---ACK, MID: 0x1234---|
  |                       |
  |<---CON, MID: 0x4711---|
  |---ACK, MID: 0x4711--->|
  |                       |
And then follows with a request that uses the MID of the last separate response:
  |                       |
  |---CON, MID: 0x4711--->|
  |<---ACK, MID: 0x4711---| <--Deduplication problem
  |                       |

The last ACK from the server is then marked as duplicate, right?
Indeed, there appears to be a problem!

The KeyMID is always fed the remote address of the message (source when receiving). However, this must depend on the message type and direction:

(Sending && CON/NON) || (Receiving && ACK/RST) --> local address
(Sending && ACK/RST) || (Receiving && CON/NON) --> remote address

I would say we need to fix all ?KeyMID idByMID = new KeyMID()? appropriately.
Would you have time for that? :)

Ciao
Matthias


From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of St?phane Rouges
Sent: Dienstag, 21. April 2015 19:59
To: cf-dev@xxxxxxxxxxx
Subject: [cf-dev] Potential bug...

Hi,

I'm working on a CoAP stack written in C and use Californium for interoperability tests. I think I found a bug in Californium. This issue is hard to reproduce since it involves randomness, requires heavy load and other specific parameters.

It occurs when CF is invoking a server using separate responses: message IDs sent from the server are logically kept in the Deduplicactor. The problem occurs when the CF client uses a subsequent colliding MID (hence the randomness of the issue) since it then considers the received piggy-backed response to its own request as a duplicate (and trap it). Note that it occurs when the same token is used by the client for successive requests.

I think that the protocol requires message IDs to be managed by each peer and may then collide. This is why, in my opinion, CF should verify the "message exchange pattern" to assert a duplicate. Here is my bug fix attempt in Matcher.java, line 310:

Exchange prev = deduplicator.findPrevious(idByMID, exchange);

if (prev != null && response.getType() != Type.ACK) { // (and thus it holds: prev == exchange)

       LOGGER.fine("Duplicate response "+response);

       response.setDuplicate(true);

} else {

       LOGGER.fine("Exchange got reply: Cleaning up "+idByMID);

       exchangesByMID.remove(idByMID);

}
It consist in not considering a received ACK can be a duplicate. What's your opinion ? I'm not sure about the fix since I did not study the  Matcher/Deduplicator fully.

BR,
--


St?phane ROUGES

[cid:image001.jpg@01D07D00.DEE9CA40]<http://www.odonata.fr>


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<mailto:info@xxxxxxxxxx>  for any kind of support about XML/EXI, embedded Web Services and DPWSCore<http://www.soa4d.org/> software.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/cf-dev/attachments/20150422/cddd4867/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2217 bytes
Desc: image001.jpg
URL: <https://dev.eclipse.org/mailman/private/cf-dev/attachments/20150422/cddd4867/attachment.jpg>

------------------------------

_______________________________________________
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

End of cf-dev Digest, Vol 9, Issue 6
************************************

Back to the top