Re: Choreography State Definition (was: RE: More requirement

I fail to see what the relation between RM and pi-calculus is.

The problem here is that reaching concensus with two participants is 
simply impossible. No matter how you twist it, play with the messaging, 
add signals, etc, you'll never be able to do it. You need a quorum and 
even then concensus is reached only between quorum members. So no 
solution either.

However, you can very easily define a protocol such that the possibility 
of disagreement is very low, or that the majority of such cases are 
resolved in a finite amount of time (preferrably one you can predict). 
So you end up with a situation where things can definitely go wrong, but 
mostly they don't, and the level of relability can approximate 100%.

To arrive at such a protocol you can re-invent the wheel or buy a 
pre-owned set of wheels. Meaning, you can write your own protocol based 
on some tried-and-tested algorithms, or you can use some pre-existing 
protocols for RM and coordination. Either way you do it, pi-calculus is 
a viable approach. You can define your protocol to the level of packets 
using pi-calculus, or you can degine a high-level representation using 
pi-calculus assuming some existing low-level protocols. And you can 
translater form the later to the former (one of the novel uses of 
pi-calculus).

In short, whether or not you use pi-calculus is orthogonal to whether or 
not you build the specification with the assumption of a RM protocol or 
introduce your own RM protocol explicitly. And whether you use 
pi-calculus or not is unrelated to the impossibility of reaching 
concensus and way around it.

However, if you are interested in referencing existing 
algorithms/research/ideas on this subject as proof of reliability of 
your solution, you may prefer to take the pi-calculus approach since 
most such algorithms/research/ideas are written in similar terms (i.e. 
the send/receive model).

arkin


Burdett, David wrote:

> Nick
>  
> Thanks for the explanation - it makes complete sense. The essence of 
> the idea id I understand it correctly is that Pi-c *relies* on the 
> reliable delivery of messages which translates, as you describe, into 
> the requirement that Pi-c would *have* to be used with a Reliable 
> Messaging (RM) protocol. If RM is not used, then you have to introduce 
> some way of compensating when the inevitable problems occur.
>  
> However even if you do use a RM protocol, the RM protocol can still 
> fail and leave the two roles in an inconsistent state where one side 
> thinks the message was delivered and therefore is continuing while the 
> other does not and is therefore halted. I won't go into the reasons 
> why here since it has been discussed on various RM working groups 
> before. Bottom line you "can't" completely guarantee that both sides 
> know that a message has been delivered AND that therefore the one side 
> won't start while the other is halted.
>  
> So I think the key question we have to answer is:
> 1. Do we want to restrict our choreography definition language to be 
> used *only* in conjunction with RM, so that we can support Pi-c, or
> 2. Do we want remove that restriction and let each side to carry on 
> processing independently and therefore not use Pi-c
>  
> *My* answer would be to go for the second option as:
> 1. RM is never 100% guaranteed and therefore
> 2. You have to allow for the specification of the exception handling 
> that occurs when processes get out sync anyway
> 3. Forcing processes to wait while the RM protocol takes place could 
> result in extended execution times. For example if you are using SMTP 
> to deliver the messages.
> 4. Carrying out process in parallel sometimes and handling 
> inconsistencies when they occur is a natural way of doing many 
> different types of processing.
>  
> ... but this is just my $0.02c ... what do others think?
>  
> David

Received on Thursday, 26 June 2003 22:17:02 UTC