+1.
-Sunil
Doug Bunting wrote:
> Sorry, I must have missed something important a while back. The idea of
> a fault returned when a duplicate is received seems flawed from the
> start and the questions below are only the start of the problems.
>
> From the original sender's perspective, it is irrelevant whether it was
> the previous outbound message or the acknowledgement response that was
> lost. That system is looking for an acknowledgement and will treat a
> dupOfWhatever fault identically to that acknowledgement. Extra
> acknowledgements that arise from duplicates generated in the network are
> certainly not faults from this perspective and the original sender must
> be designed to handle them.
>
> From the receiver's perspective, a duplicate is irrelevant to the
> application at that end and will not be passed along to it. However,
> this again is not a fault situation -- it is part of the normal
> processing of the RMP as it handles duplicates caused by lost
> acknowledgements (sender retries) and the underlying protocols (network
> duplicate generation). It takes identical effort to store and return an
> earlier acknowledgement or to find a previous message identifier with
> its disposition and generate a particular fault. The fault case may
> take more effort in fact, with little or no gain.
>
> I would propose we do not add these dupOfWhatever faults in the first
> place and simply return acknowledgements. This has the added benefit of
> reducing processing requirements when an acknowledgement must be signed
> or encrypted because the work does not have to be done again to sign or
> encrypt a new fault message.
>
> thanx,
> doug
>
> On 12-Dec-03 11:56, Tom Rutt wrote:
>
> > Bob Freund wrote:
> >
> >> Typical firewall setting for tcp session timeout is an hour or so.
> >>
> > Jacques gave me a clarification which removes my concerns.
> >
> > If a sender is piplining requests from a sequence on the same TCP
> > connection,
> > the properties of TCP will ensure ordered receipt by the sender, to the
> > error cases
> > I was concerned about would not happen .
> >
> > The problems of ordered delivery occur when different TCP connections
> > are used per
> > message on the sequence. However in this case, the order of return is
> > not constrained by
> > pipelining.
> >
> > However, I still think we need two faults, one for dupOfHeld and the
> > other for dupOfDelivered.
> >
> > Tom Rutt.
> >
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Tom Rutt [mailto:]
> >>> Sent: Thursday, December 11, 2003 2:01 PM
> >>> To: Sunil Kunisetty
> >>> Cc: wsrm
> >>> Subject: Re: [wsrm] Need to rethink semantics of duplicate elimination
> >>> behaviour
> >>>
> >>>
> >>> Sunil Kunisetty wrote:
> >>>
> >>>
> >>>
> >>>> Tom,
> >>>>
> >>>> This semantics will be very confusing as it will result in
> >>>
> >>> DuplicateMessage
> >>>
> >>>
> >>>> fault (which indirectly indicates an Ack.) before the
> >>>
> >>> actual Ack. itself.
> >>>
> >>> But I think this is a consequence of our new semantics of
> >>> acknowldegment awaiting delivery.
> >>>
> >>> If a sender resends a message which is being held wating for a prior
> >>> message, what should
> >>> the receiver do? He is holding the ack to the original http
> >>> request for that messageID, what
> >>> does he do for the new http request which is duplicate due to
> >>> retry? I say the receiver gives
> >>> a fault message as http response to the second http request with info
> >>> that the original request
> >>> was received, but its response is being held due to wating for a
> >>> prior message.
> >>>
> >>> There are two http requests outstanding from the sender, and the fact
> >>> is that the second
> >>> http request is responded first with a fault (which is really a reply
> >>> with information about
> >>> the status of the message) message. Later, when delivered, the
> >>> receiver returns a response to
> >>> the original http request with an ack.
> >>>
> >>> Note that the first http request could wait a long time for a
> >>> response. If the TCP connection
> >>> goes down, what does HTTP do to get the response back to the sender?
> >>>
> >>> Tom Rutt
> >>>
> >>> PS: this discussion is about a potential new issue, and is not part
> >>> of 52/57 resolution.
> >>>
> >>>
> >>>
> >>>
> >>>> Take the case of ordered group in which msg. 2 was missing
> >>>
> >>> and msg. 3
> >>>
> >>>
> >>>> of received. Since it is not delivered, it will not be
> >>>
> >>> Ack-ed. Assume
> >>>
> >>>
> >>>> your new proposal. If msg. 3 is tried, a NewDuplicateMsg
> >>>
> >>> fault will be
> >>>
> >>>
> >>>> sent. Assume 2 was finally delivered. Then the receiver
> >>>
> >>> will send the
> >>>
> >>>
> >>>> original Ack...
> >>>>
> >>>> For Sender, it will be very confusing to receive the Ack.
> >>>
> >>> AFTER receiving
> >>>
> >>>
> >>>> a DuplicateMsg. fault.
> >>>>
> >>>> -Sunil
> >>>>
> >>>> Tom Rutt wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Based on our current thinking, we are not sending an ack until the
> >>>>> message is actually delivered.
> >>>>>
> >>>>> Thus in the ordered delivery held waiting for prior message
> >>>
> >>> state, an
> >>>
> >>>
> >>>>> RMP may receive several
> >>>>> retransmits of that held, and thus not acknowledged message.
> >>>>>
> >>>>> In such a case, the receiving rmp should respond to sending rmp
> >>>>> regarding its receipt of the duplicate message with an appropirate
> >>>>> DuplicateMessage fault.
> >>>>>
> >>>>> Please correct me if I am wrong, but I think we need to clean up the
> >>>>> semantics of this from what is in the current draft.
> >>>>>
> >>>>> Tom Rutt
> >>>>>
> >>>>> --
> >>>>> ----------------------------------------------------
> >>>>> Tom Rutt email: ;
> >>>
> >>>
> >>>
> >>>
> >>>>> Tel: +1 732 801 5744 Fax: +1 732 774 5133
> >>>>>
> >>>>> 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/leav
> >>> e_workgroup.php.
> >>>
> >>>
> >>>>>
> >>>>>
> >>>>
> >>>> 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/leav
> >>> e_workgroup.php.
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> ----------------------------------------------------
> >>> Tom Rutt email: ;
> >>> Tel: +1 732 801 5744 Fax: +1 732 774 5133
> >>>
> >>>
> >>>
> >>>
> >>> 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/leav
> >>> e_workgroup.php.
> >>>
> >>>
> >>>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >>
> >
> >
