[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination behaviour
Doug Bunting wrote: > Jacques, > > I have not reviewed the most recent text at this level of detail but > find it likely some portions have not yet been updated to reflect the > new "ack-on-delivery" semantics. I agree the RMP should not send an > acknowledgment for any message until its delivery. (And, I hope > "delivery" is consistently used and well defined in the specification.) > > I am not sure I follow you after "Personally ..." since duplicates may > certainly arrive both before and after delivery. A duplicate received > before delivery is completely ignored, closing the inbound connection > or, possibly, holding it open until the acknowledgment is available. This might be a problem, if the TCP connection which the original message http request was sent on goes down, the original ack can never be delivered. Thus the second (duplicate) request should also be acked in its HTTP response, when delivery occurs. This might be the only ack which can be sent. > A duplicate received after delivery is acknowledged, identically (from > the sender's perspective) to handling of the same message when nothing > blocks immediate delivery. Are we agreeing or not? > > The expiration question is interesting but somewhat orthogonal. If a > message is received, processed appropriately and acknowledged at some > time and the same message (a duplicate) is received again after it has > expired, what should happen? The most correct information the > receiver could supply would be an acknowledgment since the original > message was processed within its expiration window. The easiest > information the receiver could supply would be an expiration fault > since the duplicate contains enough data to notice that fault without > any additional checks. I would prefer that system return the > acknowledgment if possible -- that is, prior to removing the necessary > information from its store. Might be a RECOMMENDATION in the text? > > thanx, > doug > > On 16-Dec-03 16:23, Jacques Durand wrote: > >> Doug: >> >> I suspect a remaining gray area in the Ack semantics and behavior: >> >> - Given we all agree on Ack-on-delivery (meaning the message has >> actually been "delivered" to the receiver app), >> >> What you point at, is the case where: >> - message was well received and well delivered. >> - the Ack was sent back, >> - the Ack was never received by Sender. >> >> What you expect is: >> - when duplicates for the delivered message are received, >> the RMP will repeat the Ack sending, because the message >> was actually previously delivered, yet the Sender does not seem to >> know this. >> >> So the current spec is still unprecise as what "sending an Ack on >> duplicate" means (3.2.1 line 552), since that seems to be a remnant >> of the old >> "ack-on-receipt" semantics: >> with "ack-on-delivery", we should not send an ack for a duplicate >> of a message that has NOT been delivered for whatever reason. >> >> Personally, I thought this ack of duplicate was obsolete >> with the new ack semantics, yet I see your proposal as an >> optimization that >> may reduce the number of cases where: >> (1) a message was well delivered >> (2) Sender cannot assume it was delivered. >> Note that when a duplicate has expired when arriving, the ID of the >> initial >> message may be removed, and the receiver RMP may never know that this is >> a duplicate of a well-delivered message (this duplicate would be >> discarded >> due to expiration.) >> >> I have no problem with acking duplicates in that case. >> That would improve things, yet only an optimization. >> >> Is that a good summary of where we are? >> >> Jacques >> >> >> -----Original Message----- >> From: Doug Bunting [mailto:Doug.Bunting@sun.com] >> Sent: Tuesday, December 16, 2003 2:40 PM >> To: Jacques Durand >> Cc: tom@coastin.com; Bob Freund; Sunil Kunisetty; wsrm >> Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination >> behaviour >> >> >> Jacques, >> >> I am not sure what you mean. A message may be resent after the >> receiving application has processed it. The previous acknowledgment >> could easily have been lost. In effect, the sender is performing the >> resend in order to retrieve the missing acknowledgment. Of course, that >> sender does not know or care whether the original message or the >> acknowledgment was lost. >> >> This all means we need acknowledgments for all messages sent reliably >> whether duplicates or not. >> >> thanx, >> doug >> >> On 16-Dec-03 14:31, Jacques Durand wrote: >> >> > + 1 on no faults for dups. >> > >> > But the end of your mail is ambiguous on one point: >> > >> > >I would propose we do not add these dupOfWhatever faults in the >> first >> > >place and simply return acknowledgements. >> > >> > given the Ack semantics agreed on (ack-on-delivery), >> > no acks will be sent for dups - which is fine. >> > >> > Jacques >> >> ... >> > > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]