RE: counting prepares

[Peter Furniss <peter.furniss@choreology.com>]

> > We currently allow a superior that has received VOTE/ready from a
> > subordinate to issue another PREPARE. It must then wait for the
> new VOTE.
>
> I haven't got my notes to hand, but at the last face-to-face
> didn't we agree
> that a participant that says read/10/cancel (or whatever the syntax is for
> saying "I'll cancel after 10 seconds though") wouldn't have to be
> contacted
> by the coordinator again, because the coordinator can infer from this that
> if, after 10 seconds it hasn't sent a confirm, it knows the
> participant has
> cancelled, and can act accordingly? I also seem to remember that
> this was a
> "the coordinator could send a re-PREPARE if it wanted to" but it
> didn't have
> to. In any event, I don't think this contradicts what you are saying.

I believe the "assume the timeout happened" feature was an option, indicated
explicitly (on the vote), on the grounds that some timeouts will be "hard"
(we will definitely cancel at 10 seconds), and some "soft" (we reserve the
right to cancel, and so you shouldn't rely on the vote promise, but we won't
actually cancel unless there is competing need for the resource). It's the
latter sort where re-PREPARE is useful.

> > Effectively, the issuing of a PREPARE after receiving the VOTE means the
> > superior has lifted the obligation on the inferior to hold the ready
> state -
> > accordingly the superior cannot decide to confirm until it gets the new
> vote
> > in. Otherwise you could have CONFIRM crossing with VOTE/cancel, which
> would
> > require different logging/persistence rules.
>
> Agreed. I thought we briefly discussed this possibility at the last
> face-to-face but perhaps not. It's definitely an issue though.
>
> [problem statement deleted]
>
> > This counter can replace the spontaneous/response flag that is currently
> on
> > VOTE - the counter starts at 1, and a spontaneous VOTE has a counter of
> > zero.
>
> Basically your proposing the addition of sequence numbers to tie up the
> request/response in an asynchronous message passing environment. Seems
> reasonable to me.

pretty much, yes.

> > We can't demand that the most recent counter is present on the
> > INFERIOR_STATUS/ready, because it is not reasonable to demand
> that the log
> > record be re-written every time there is a re-vote. But the
> > INFERIOR_STATUS/ready could carry the counter - if this is that of the
> last
> > PREPARE, there is no need to send another one.
>
> We don't need to demand that the issuer of PREPARE actually increase the
> sequence number in all situations though. This can be on a per "round"
> basis, so that if PREPARE N to the 3rd participant in the
> coordinator's list
> doesn't get a response because the VOTE N got lost en route, it could
> re-send PREPARE N. At the participant side if I wanted to implement a
> retained results policy in the message gateway or somewhere else
> on the path
> to the actual participant, I could get the original returned VOTE
> N response
> out the results cache and resend it from there, without having to
> go to the
> participant again. If the original PREPARE N was lost en route then there
> wouldn't be a VOTE N in the cache, and I would have to go to the
> participant, who wouldn't be able to differentiate this from
> having received
> the first PREPARE N attempt.

That kind of twists the semantics, I think. Resending PREPARE N, with N
unincremented, would mean that the sender was not lifting the vote
obligation (if one had been sent but lost), but that merely re-asking "what
was your answer". If the message does get down to the participant (in a
slightly different configuration), the participant would not be allowed to
change its mind.

But the message gateway case can give the same answer as a response PREPARE
N+1, incrementing the number in the vote (it had to parse the PREPARE either
way, so it can certainly reconstruct the VOTE), depending on its contract
with participant. (The message gateway is sort of acting like an attorney -
if I've said my offer remains good, my attorney can reply to repeated
queries without having to come back to me each time)

(Note that a re-ote with a (relative) timelimit will need adjusting anyway)

> However, I agree that if the coordinator needs to issue a truly "new"
> PREPARE (as a result of receiving an INFERIOR_STATUS) then the sequence
> number needs to be incremented.

wouldn't have to be INFERIOR_STATUS - superior might be wanting to
check/extend the timelimit, or see if a soft timelimit has fired.

> This raises the question of whether we want to have this sequence
> number as
> a general field in all BTP messages in order to tie up other message
> request/response messages.

Most of the other messages, by design, don't have a strict request/response
relation, at present. RESIGN and ENROL do (sometimes), but they're special
cases (and multiple ENROLs would have to be handled differently anyway).
CONFIRM/CONFIRMED and CANCEL/CANCELLED don't always come in that order (in
the case of autonomous decisions) either.

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX