Typical firewall setting for tcp session timeout is an hour or so.
> -----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.
>
>
