OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Issue i005


 
Hi Anish,

Please see below...

Cheers,
Steve


> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Wednesday, Aug 24, 2005 11:43 PM
> To: Winkler, Steve
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Issue i005
> 
> Winkler, Steve wrote:
> > 
> > Issue i005 was originally brought up at the F2F, not 
> necessarily by me,
> > but I was an active part of the discussion and therefore 
> would like to
> > continue that discussion on the list.  I've included some background
> > information to expound upon the description and I've followed with a
> > concrete proposal that I hope the TC will consider as a 
> starting point
> > for resolving the issue. 
> > 
> > Cheers,
> > Steve
> > 
> > 
> > Background
> > 
> > The asynchronous nature of acks, as well as line 336/337 of the spec
> > indicate that 'The RM Destination MAY send a 
> <SequenceAcknowledgement>
> > header block at any point.'  In certain cases, this could 
> result in an
> > Ack for a given message overtaking an Nack for the same 
> message.  The
> > rationale given for the Nack is that the gap analysis can 
> be performed
> > on the RMD side resulting in performance enhancements (see lines
> > 376-378).  In the case that the Nack overtakes an Ack, the 
> Nack could
> > actually go against the spirit of the spec and result in performance
> > degradation by triggering the retransmission of a message that has
> > already been received by the RMD.  It should be noted that 
> receipt of
> > this message by the RMD a second time is in no way an 
> error, but simply
> > an unnecessary inefficiency in the protocol for this edge 
> case.  Better
> > implementations would have probably avoided this anyway.
> > 
> > Several people during the discussion at the F2F mentioned 
> that there may
> > be some benefit in Nacking a message to trigger resending 
> of a message
> > that has already been received by the RMD.  
> 
> What is the advantage in doing that from a reliable messaging 
> protocol 
> POV? The message has already been received and the sender knows this.
> 

Answer: There isn't any advantage from the RM layer POV.  Several
members of the group suggested that the capabililty of triggering the
source to resend a message that it may already have marked as delivered
would be useful.  The wording of this proposal was to allow such
implementations to make use of the RM machinery to enable this feature
without impacting the semantics of the RM layer.  


> > Whereas I can see that this
> > may be true, it seems like this kind of functionality would need to
> > happen at a layer above RM (i.e. it's out of scope for this spec).
> > However, given that messages can be delivered multiple 
> times anyway, it
> > would not be the end of the world to retransmit a message that has
> > already been delivered to the RMD.  Therefore I would not want to
> > preclude an implementation that wants to '(ab)use' this 
> fact from being
> > allowed to use the RM machinery already in place to achieve this.  
> > 
> > I also noticed while investigating this issue that there 
> doesn't seem to
> > be any explicit indication in the spec that a Nack message should
> > trigger the resend of a message.  I believe that this is 
> implied, but
> > since it's an optimization, it is also most likely not 
> intended to be a
> > requirement. 
> > 
> > Proposal: Add text to the spec to explicitly state what an 
> RMS should do
> > when it receives a Nack message and tighten the spec for 
> the edge case
> > described above in the following manner (wordsmithing can 
> be done later,
> > but you get the gist):
> > 
> > In Section 3.2, after line 338 add something like this: 'If the RM
> > Source should receive a <SequenceAcknowledgement>containing 
> a Nack, the
> > RM Source SHOULD retransmit the message corresponding to 
> the Nack. After
> > the notification of successful receipt of a given message by the RM
> > Destination, the RM Source SHOULD NOT attempt to retransmit 
> the message
> > in the event that it receives a negative acknowledgement for it at a
> > later point in time.'
> > 
> > 
> > ------------------
> > Steve Winkler
> > SAP AG
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]