Subject: [core] Asynchronous exchange

From: [email-masked]
Date: Fri, 20 Aug 2010 12:17:54 +0200

Hi all,

Are you planning to improve the way to relate an asynchrounous response to
a request for CoAP clients ?
In a 4-message exchange the TID changes so currently the only invariant is
the tuple (address, uri) if I'm right.
Decoding this tuple seems quite complex for a constrained node just to find
a response to a request.
And we still have problems with
- multicast addresses
- proxied requests
- a sequence of requests PUT, GET to the same (address, uri) because the
method is not preserved.

The token option in coap-misc could be a solution. But the presence of this
option would be a client-side decision whereas the synchronous/asynchronous
mode is currently a server-side decision.
So there would be different ways of associating an asynchronous response to
a request depending on the presence of the option. Multiplicity is not a
good thing for constrained devices.
Could be the asynchronous mode always a client-side decision ?
The server could return an error code if it knows the request will take too
much time without the asynchronous mode. That way we could also have
implementations supporting only the synchronous mode.

What are the current rules to decide to activate the asynchronous mode or
to stay in synchronous mode for servers ? I presume it should be the
processing time of the request compared to RESPONSE_TIMEOUT to avoid
retransmissions. But RESPONSE_TIMEOUT includes the transfer time which is
fluctuating and not necessarily negligible on a mesh 802.15.4 network.
This kind of rules can only be determined by the server and seems
incompatible with a client-side asynchronous mode.

Regards,
Matthieu