[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
That would be my interpretation of the new resolution for issue 33 (Acknowledgment Message). If you really want to avoid the extra messages that are inherent in the new meaning of the Acknowledgment, the protocol would need to include a new message with the old meaning of Acknowledgment (I got it and will process once earlier messages come in). thanx, doug On 16-Dec-03 14:24, Tom Rutt wrote: > Doug Bunting wrote: > >> Doing nothing, identical to the handling of the original message that >> remains in the "hold for rest of sequence" queue. > > > Does that mean when the message is delivered out of its held state, you > send back the chain of delayed acks > that has been "queuing" up? > >> >> >> On 16-Dec-03 13:50, Tom Rutt wrote: >> >>> 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 >>> >>> >>> >>> >>> The case is a resend of a message which has not been acked because >>> the message is held >>> on the receiver side waiting for an ack. >>> >>> How does the receiver rmp reply to this resend, It MUST not ack >>> because the message >>> has not been delivered. >>> >>> I beliieve a special fault message, with the proper semantics, should >>> be send back immediately >>> to stop the sender from resending, since the message was already >>> received. >>> >>> How would you recommend to handle this case? >>> >>> Tom Rutt >> >> >> ... >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]