RE: Application versus protocol "finish work"

[Savas Parastatidis <savas@arjuna.com>]

Alastair, Pete, Mark,

As you probably realised by now I am trying to catch with the messages
of the day. I am glad to see that we are converging.

The proposal I sent based on Alastair's example in an earlier message is
still valid. 

> 
> I -- *REQ* + *FINISH* -- INT(I)
> INT(I) -- *REQ* + *FINISH* + CONTEXT -- S
> S -- ENROL -- C
> C -- ENROLLED -- S
> S -- PREPARE -- P [or some backdoor to say <prepare>]
> P -- VOTE -- C
> S -- *RESP* -- I
> I -- <prepare> -- C
> C -- <outcome> -- I
> 
> Minimum of 5 network messages if we assume that I and C are on one
node of
> the
> network and S and P are on a second. (Obviously this assumption could
be
> relaxed).
> 
> Now introduce boxcarring., which uses the INT(I) and also INT(S) for
the
> service
> side.
> 
> I -- *REQ* + *FINISH* -- INT(I)
> INT(I) -- *REQ* + *FINISH* + CONTEXT -- S
> S -- ENROLL -- INT(S)
> S -- PREPARE -- P [or some backdoor to say <prepare>]
> P -- VOTE -- INT(S)
> S -- *RESP* -- INT(S)
> INT(S) -- *RESP* + ENROLL + VOTE -- INT(I)
> INT(I) -- *RESP*  -- I
> INT(I) -- ENROLL + VOTE -- C
> I -- <prepare> -- C
> C -- <outcome> -- I
> 
> Minimum of 2 network messages.
> 
> Without boxcarring you go from 6 to 5 net messages; with boxcarring
you go
> from
> 6 to 2 messages.
> 

The problem with the last approach is the same that I identified in one
of my earlier messages. Are we supposed to allow the service to respond
when it doesn't yet know whether the participant was able to register
with the coordinator? I think the optimisation looks impressive because
we are missing a message.

Please, refer to my example in the earlier message. I think it is
demonstrated there that the gains are the same.

Enough for tonight. :-)

.savas.