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

[Zach Shelby <[e-mail]>]

Bingo, I have been thinking about this more and to me it seems like dealing with asynchronous responses to delayed normal requests (not subscriptions) is actually the key piece we have been missing. We need this kind of asynchronous response (notification) for this purpose. So what if we build this observation thing like:

1. Integrate this asynchronous response message into the core protocol for the purpose of normal requests. This might be similar to the current notify message, or a different kind of response. I think this is what Robert Cragie was getting to before, asynchronous interactions are key here.

2. We consider the observation feature as just another way to invoke asynchronous responses. If we consider that GET can be answered later asynchronously. Then adding a subscription is simply a GET with some more specific meta-data (subscription/observation option). That also makes the HTTP mapping more like what some were hoping for?

Both 1 and 2 are part of the transfer protocol interaction model, and can be done transparently to the REST methods. I start to see a way we could achieve both the observation and notification without requiring new methods and making it possible for a more "transparent" HTTP mapping even for observation.

On Jun 23, 2010, at 7:55 PM, Carsten Bormann 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?

Nope, I think you are right that we need asynchronous responses.  

> 
> 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.


Zach

> 
> 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
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]