Re: [wsn] What does it mean for the NP to "send" a message?

[Samuel Meder <meder@mcs.anl.gov>]

On Thu, 2005-01-13 at 11:43 -0500, David Hull wrote:
> Intuitively, sending a message means something like putting it on the
> wire so that the Consumer will receive it, but as it stands, this
> notion is not precise enough for our purposes.   The distinction
> between sending a message and putting it on the wire has just come up
> in the context of continuity, and it's clearly important for
> reliability as well.  I suspect that defining the concept rigorously
> will also clarify the semantics of other delivery-oriented policies
> such as durability, queuing, one-of-N delivery and so forth.
> 
> Since this is a sticky question, it seems best to steal leverage
> someone else's work.  As it happens, the two Reliability standards
> both define a two-tiered model which I think will fit nicely here.
> Since we're OASIS, I'll use the WS-Reliability TC's terminology.  In
> this view, getting a message from producer to consumer is a three-step
> process involving four entities.
>      1. The producer submits a message to the sender (WS-RM actually
>         calls it a "Sending RMP", that is a "Sending Reliable
>         Messaging Processor", but I want to use the same notion for
>         other purposes as well).
>      2. The sender sends the message to the receiver, wrapping it
>         appropriately, noting serial numbers, handling
>         acknowledgments, etc.
>      3. The receiver delivers the message to the consumer.
> In WS-R, the consumer also responds to the receiver and the receiver
> and sender cooperate to allow the sender to notify the producer that
> the message has arrived.  This is clearly central to WS-R, but in the
> present context I'm just trying to emphasize the split between the
> producer/consumer tier and the sender/receiver tier.
> 
> In the case of continuity in the face of subscription property
> changes, the issue is that certain messages may never be submitted,
> not that submitted messages will never be sent.
> 
> I believe that the cleanest semantic for BaseN is that
>       * Each notification message relevant to a subscription will be
>         submitted exactly once.
>       * The messages on a given topic will be submitted in the order
>         their corresponding events occurred.
> There is a further question of how messages on multiple topics may be
> interleaved, and whether separate subscriptions see the same
> interleaving.  For now, I'd like to raise this as an open issue.

I guess I should read messages in least recently sent order...

I'd just like to say that I disagree with specifying these semantic in
BaseN. I feel that these things should be left to policy statements.

/Sam

> In this view, all further semantics, including reliability, security,
> durability and so forth, are between the sender and the receiver.  The
> reliability standards are very careful not to say what kind of
> connection exists between producer and sender, or between receiver and
> consumer.  The exact meaning of submit and deliver are left
> implementation dependent.  The strong implication is that they are
> generally local calls with a single process space, and thus are
> reliable and secure barring catastrophes.  In any event, guarantees of
> reliability are only made between the sender and receiver, and I
> believe we should follow this pattern for all non-trivial delivery
> semantics.
> 
-- 
Sam Meder <meder@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752