Closed darkopetrovic closed 8 years ago
I am aware of this issue. It is described in: https://tools.ietf.org/html/draft-ietf-lwig-coap-03#section-2.3.2 I think it will be better to solve the problem by introducing separate namespaces (dictionaries) for local and remote IDs.
I uploaded new version of the library (0.1.3) to pypi.
You're right. Thanks for the speed!
Hello, first thanks for the update concerning #5. Here a new proposal for another issue :)
I let my device working during this week-end and after ~20h the communication stops working. The log showed me a lot of
Duplicate NON, ACK or RST received
preventing the CoAP client to enterprocessResponse
and print the final result.I've found that this issue has occurred because the client has generated the same message ID for an exchange than a previous received message from the server. And since this generation has occurred within
EXCHANGE_LIFETIME
, the message ID being still present in therecent_messages
dictionary, the client found a duplicate NON message while treating the response of the added exchange.To prevent this to append I modified the function
nextMessageID
as follow:Otherwise we could reduce EXCHANGE_LIFETIME but it is not guaranteed that even with a smaller lifetime the client doesn't generate the same message ID within this delay.
From the standard perspective (RFC 7252 document) it is stated in chapter 4.4 :
I guess the application must take care of the incoming message ID too before generating the next one by itself. As it is implemented in your code though since you store every incoming message in
recent_messages
.