Re: Implementation question for RM spec!

[Jim Hughes <jfh@fs.fujitsu.com>]

Chris/All,

I don't recall the exact discussion we had when we got to this very 
simplistic view, but I think it had to do with error processing and the 
need to insure that if the sending MSH gets a sequence of reliable messages 
from the Sender, the sending MSH needed to insure they went sequentially. 
I'd suggest that we leave this restriction in for Phase 1, or until we have 
enough Service Interface semantics defined so that the Sender can tell the 
Sending MSH whether messages must be sequenced. If you remove the 
restriction now, there is no way for the Sender to indicate this 
sequentiality...

RE your third paragraph, this doesn't have anything to do with how the 
receiving MSH identifies duplicate messages.

BTW, this restriction is in lines 123-125 in the RM spec I just posted (v0.08).

Jim

At 11:24 PM 9/29/2000 -0400, christopher ferris wrote:
>Jim/All,
>
>It isn't clear to me why it would be necessary to
>block until the previously sent message is ack'ed.
>That would be one manner of implementing, but not an
>approach I'd choose.
>
>Since each message is ack'ed individually, you can
>send as many messages as you like and process the
>acks or retry (in the case of a timeout) oob.
>
>The specification stipulates that one MAY use either
>the sequence number OR the messageId (refToMessageId)
>for the purposes of determining which message is being
>ack'ed.
>
>This is my understanding of what we have worked out for
>phase one. Possibly, it is misguided, but I for one would
>not advocate a (logically) blocking protocol.
>
>Cheers,
>
>Chris