Re: [cf-dev] Potential bug...

["Kovatsch Matthias" <kovatsch@xxxxxxxxxxx>]

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

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.