[core] Can all responses be instant? (Re: Fwd: New Version Notification for draft-hartke-coap-observe-00)

[Carsten Bormann <[e-mail]>]

Zach,

that are a number of very good questions.

Let's start discussing this one:

> - I am not sure about the implications of allowing a delayed GET and PUT response on implementations. Currently in coap-00 if an end-point doesn't make use of subscribe/notify it doesn't have to implement code to wait for asynchronous notifications. For example it might simply make a request, open a temporary UDP socket waiting for the response, and then close that and go to sleep. Well, I guess if it gets an intermediate response code it would know to stay awake waiting for the response. Is this an efficient way of using energy in a constrained network though? What if a client doesn't want a delayed response?

Right now, CoAP is silent on how much time a server has to answer a request.

Certainly, that time will never be zero.

Can we live with limiting this time to < RESPONSE_TIMEOUT hard?

If yes, everything gets simpler.
If not, there is always the alternative not to do an inversion of control; in that case, the server would reply with a "please wait and try again", maybe including a duration that gives the estimated time until an answer, and the client would simply repeat asking at its convenience.
(Of course, the server could simply remain silent, prompting retransmissions, but this means that we limit the time to RESPONSE_TIMEOUT * MAX_RETRANSMIT, assuming no errors, and we increase the likelihood of a transfer failing just because of lost packets.)

On the other hand, if we do have a "notify" style packet, there is very little stopping us from implementing an "I'll give it to you later" reply (the "ACK" packet in Figure 1 of coap-observe).  A client that doesn't want to wait can simply treat that as a failure.

As usual, we should probably err on the side of simplicity, but only after having discussed whether we are hitting Einstein's "but no simpler".

Gruesse, Carsten