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

Possible solution: CoAP server, if the final response will be
available after RESPONSE_TIMEOUT, must send a response with code 100
Continue (HTTP).

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1

However in this discussion application level and transport level
issues are handled at the same time... Is it convenient?

Angelo

On Wed, Jun 23, 2010 at 18:55, Carsten Bormann <cabo@tzi.org> wrote:
> 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
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>