Re: [wsn] Open issues concerning ordering and interleaving.

[Steve Graham <sggraham@us.ibm.com>]

Hi David:

David Hull <dmh@tibco.com> wrote on 01/13/2005
11:55:19 AM:

> For simplicity, assume there are only two topics in the world, topic
A and topic B,
> and that a topic expression may specify any combination of them.  Events
are 
> generated in a given order, and we should at least guarantee that,
for a given 
> topic, the NP submits events for delivery in the order in which they
were 
> generated.  The issues here concern whether we should have policy
utterances to 
> describe stronger guarantees.
> 
> Suppose that topic A carries notifications A1, A2 and A3, and similarly
topic A 
> carries notifications B1, B2 and B3.  At the very least, we guarantee
that A1 will 
> arrive before A2, etc.
Is there indeed such a guarantee?  How can we
make this guarantee, independent of
certain assumptions of QOS in the transport?

>  The first issue is what to do if there
is some inherent ordering 
> across these event streams.  E.g., each carries a timestamp from
an external 
> reference clock.
Or, perhaps a simpler, monotonically increasing sequence
number on the notificaiton
messages?

>  In this case, A1 might be marked as occurring
before (or after) 
> event B1, and the "correct" order of notifications might
be [A1, B1, B2, A2, A3, 
> B3].  Should we provide a way of flagging these situations, or
should we leave that
> as application dependent.
My choice would be to leave this as application dependent.
 There may be some naturally
occurring sequence number (CBE, for example, has naturally
occuring creation time attribute).

> 
> The second issue comes up when there is no externally-defined ordering
across 
> topics.  Should the NP impose one?
IMO, no.  Again, leave the application to define
this.  CBE will have timestamp, I am
not keen on making the WSN specs more complicated.

>  If two separate subscriptions both include
> topic A and topic B, should they see the same interleaving of messages?
 This might
> seem automatic, but I can imagine a distributed implementation in
which different 
> physical processes handle different subscriptions and so may have
different views 
> of interleaving.
> 
> For that matter, under what circumstances is is the original requirement
that 
> notifications should be sent in order of their underlying events meaningful
at all?