Re: [wsrm] Sequencing use cases [was: Re: [wsrm] Preliminary minutesof WSRM TC Conf call -050603]

[Tom Rutt <tom@coastin.com>]

Doug Bunting wrote:
> An interesting use case thread to say the least.
> 
> I would appreciate more information about business situations in which 
> we believe multiple un-acknowledged messages may be outstanding.  If I'm 
> thinking clearly, those cases in which message ordering may become 
> important are a subset of the un-acknowledged request cases.  Those 
> cases in which two parties may have parallel sequences in progress are a 
> further subset of this second class.  We need to ensure the protocol 
> must go that far before we do (validate) all of the work.
> 
> While I can, for example, imagine a messaging system splitting a large 
> transfer into an ordered set of messages sent in a "batch", I'm not sure 
> why the system would act in this fashion (versus performing one large 
> transfer).  I suspect a justification exists and didn't object to making 
> parallel sequences a requirement for our protocol but would like to hear 
> it clearly described.
> 
> Somewhat separately, I'm assuming above that we're talking about a 
> relatively short duration sequence of messages (having short pauses 
> between the sent messages).  "Conversations" (if you will) with gaps 
> between messages longer than the time-to-live for those messages seem to 
> be more about shared context than ordering since the messages must be 
> acknowledged individually.  Please let me and the group know if you're 
> considering long duration sequences (those with long gaps between 
> messages) an important requirement for our protocol.  Otherwise, the 
> "multiple un-acknowledged messages" mentioned above exist in a window of 
> about the same size as the message time to live.
> 
> thanx,
>     doug
> 
I agree we need to clarify this.

I have been thinking that the sequence could have large gaps in time.

This is why it may be an important processing optimization to eliminate 
the presence of two ids.

The amount of time the message receiver has to remember the IDs could be 
very large.  Thus, for duplicate elimination, it has to remember IDs of 
messages it has successfully receieve for a very long time.  If for 
ordered delivery it also has to remember the groupID/SequenceNo pair, 
the it has to have enough storage for logging Both of these IDs for 
messages it has successfully received.

Tom Rutt
Fujitsu

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133