[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel 33: some thoughts and proposal...
Sunil, Can we call it "delivery"? Because RM is about "delivery guarantee," we need to somehow define "delivery" anyway by stating the boundary of RM's responsibility. The definition can be something like this -- "Delivery of a message" means to make the message available to the receiver (i.e., the next layer). At the time of delivery, the responsibility of message preservation is transferred to the next layer. Note that the delivery does not mean the message has accepted or processed by the user application. For example massages may be queued or stored (in the next layer) for later processing. ---- The rest of this mail is my thoughs on Ack semantics. Ack semantics can be defined with transfer of message preservation responsibility: [1] peer-to-peer Ack semantics (the current spec) Ack means that the message preservation responsibility has been transferred from a node to the next node. [2] end-to-end Ack semantics (Jaques' proposal) Ack means that the message has been "delivered" I agree with Jaques' point, that is, by taking the semantics [2], the spec and implementation can be simplified significantly. The message preservation responsibility will be transferred in the following order: 1. sender application (layer) 2. sender node 3. receiver application (layer) Note that the receiver node(and intermediaries if any) does not appear in the above transition list. The receiver node is no longer responsible for message content preservasion. The only responsibility of the receiver node is preservation of message metadata (for duplicate elimination and ordering) until expiration time. The receiver can discard received messages anytime. The receiver node may preserve disordered messages for better performance. An intermediary node may preserve, resend, eliminate, or order messages, but it is not responsible for either message content or message metadata preservation. For performance issues, there can be additional peer-to-peer control messages (e.g., between the sender and an intermediary), but it would be out of scope of the first spec. Jun Tatemura Sunil Kunisetty wrote: > > Peter, > > We are indeed referring to RM Ack and not Application/Business App. We > discussed this > in the Oracle F2F and we definitely said the latter is outside our > realm. The current proposal > for REL 33 is more like a transport Ack and Jacques and I are > suggesting to make it more like > a RM Ack. So seems like you are in agreement with us and your only > concern is the usage > of words. > > Before I list the choices, I just want to re-emphasize that this > (correct usage of words) issue is > sort of orthogonal as we use the same phrase in defining the Ordering > semantics also. > > So let me list the choice of words: > 1) "make it available to the application/user". > 2) "make it available to the next layer". > 3) "RMP passing responsibility for the message to the user" > [I copied this from the Tom's meeting minutes as Pete W. saying so] > 4) "Transferring the responsibility to the next layer". > [i vaguely recollect someone saying it in the call.] > > Does any one have any other suggestions? In the above list, I prefer > option 2 with a comment > that the next layer could be the application user itself. > > Thoughts? > > -Sunil
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]