[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Issue i078
Matt, Few comments below. -Anish -- Matthew Lovett wrote: > > Hi all, > > I'd like to kick off some discussion about issue i078. I see where it is > coming from, and I do have some sympathy with the issue, but I'm not > sure that making the operation 2-way really helps. Consider the > following cases (where I assume that terminate sequence is still one-way): > > a1. RMS sends a <wsrm:TerminateSequence> and the RMD receives it > - all ok, but the RMS doesn't know that > - If the RMS wants to it can retry until it gets an UnknownSequence > fault (always one more message than we needed) > Yes, RMS can do that, but it will have to do that (and get a fault) even when there is no message loss. > a2. RMS sends a <wsrm:TerminateSequence>, which is lost > - The RMD will probably rely on some implemetation-specific cleanup > - If the RMS wants to it can retry until it gets an UnknownSequence > fault (always one more message than we needed) > > a3. A badly behaved RMS does not send a <wsrm:TerminateSequence> > - The RMD will probably rely on some implemetation-specific cleanup > > If we put a 2-way terminate sequence into the mix then we get an > increase in the number of cases, but I don't see much advantage > > b1. RMS sends a <wsrm:TerminateSequence> and the RMD receives it, and > the reply gets back to the RMS > - all ok > > b2. RMS sends a <wsrm:TerminateSequence> and the RMD receives it, but > the reply gets lost > - all ok, but the RMS doesn't know that > - If the RMS wants to it can retry until it gets an UnknownSequence fault Or the RMD may (if it chooses to do so) retransmit the TerminateSequenceResponse message. > > b3. RMS sends a <wsrm:TerminateSequence>, which is lost > - The RMD will probably rely on some implemetation-specific cleanup > - If the RMS wants to it can retry until it gets a > TerminateSequenceReply or an UnknownSequence fault > If we were to make TS a req-response then RMS will have to retry wsrm:TerminateSequence until it gets back a wsrm:TerminateSequenceResponse message or a fault. > b4. A badly behaved RMS does not send a <wsrm:TerminateSequence> > - The RMD will probably rely on some implemetation-specific cleanup > > So, we have complicated the protocol, but a defensive RMD still needs > some way to clean up stale sequences. The advantage is that sometimes > the RMS will get an unambiguous TerminateSequenceReply, though the RMS > still needs to handle the case where it gets a UnknownSequence fault. > Regardless of what we do in the protocol, there will always be the case where the RMS or RMD or the underlying network has a problem and the RMD and RMS must be able to handle that (cleanup/rollback/whatever). I thought what Bob was going for was to allow the RMS and RMD to be sure of normal termination in the no-message loss case. > I also believe that the overwhelming majority of > <wsrm:TerminateSequence> messages will get to the RMD. Given that I > think that the best thing to do here is leave the operation as a 1-way. > > Does anyone else have any comments? > I think making it req-res is an interesting proposal. Personally, I need to think more on this. > Matt > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]