Subject: Re: [core] Observing Resources in CoAP: re-ordering

From: Oscar Novo <[email-masked]>
Date: Wed, 3 Aug 2011 12:06:33 +0200

Hi,

Klaus wrote:
>A simple counter for notifications is actually an acceptable implementation, provided that the server does not reuse the same counter value within 2^16 seconds.

The counter increments in one for every notification, once the value reach the max value (2^16), the counter starts from 0 again. There is not any time constraint of 2^16 seconds in the solution I proposed.  

Klaus wrote:
>The server needs no state to generate the option value. The client needs just to remember two values per observation relationship; the if-expression is copied literally from the >draft. I'm not sure how this can be further simplified; suggestions are welcome.

Incrementing an integer value in every notification is far more simple to implement. The server and client only need to keep the last counter value, a simple integer value. 

Oscar

On 22 July 2011 12:10, Oscar Novo <[email-masked]> wrote:
>
> Hi,
>
> I think the way the observe draft handles reordering is far too complicated. Besides, I'm wondering how this solution would work for sleeping clients. Have you think about it? At least, I can see some problems with the actual solution.
>
> I think a neat solution would be that the server increments in one an integer value in every notification to indicate the order of the notifications. What do you think about that?
>
> Cheers,
>
> Oscar
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Oscar Novo <[email-masked]>
Date: Wed, 3 Aug 2011 12:27:08 +0200

On Jul 25, 2011, at 12:31, Oscar Novo wrote:

> If we suppose the case of a network which has some sleeping nodes and some caching nodes which store the observation methods and deliver them once the sleeping-nodes are awake. How an sleeping observer could handle the historical notifications data of a subject if the wake up time of the node is higher than 18.2 hours?

Carsten wrote:
>I'm not sure I understand the question, but after 18.2 hours the time limit of t2 < (t1 + (2**14)) is long gone, so there would be no need to check for reordered messages 
>reaching back that long.

I agree the example is a bit unrealistic but I still think it is not good idea to link the re-ordering with the local timestamp. I guess some type of time synchronization scheme will be needed to have the necessary time accuracy in the nodes which will complicate even more the whole solution. 

I consider a simple counter option would be a better solution.

Cheers,

Oscar