[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[moca] RE: Re: RE: RE : synchronous implementation of Pi calculus with choice?
I hope this does not sound to naive , but -
If all your process have transactioning and can be restored in
the event of failure and if you have a guranteed mesage delivery
system , both of which I belive are possible , why does the
possiblity of message failure matter for an algorithm that solves
the global consensus problem , if there was such an algorithm ?
Regards
Bill
-----Original Message-----
From: Fabrice Le Fessant [mailto:fabrice@xxxxxxxxxxxxx]
Sent: Wednesday, January 15, 2003 2:38 PM
To: Pawel.Wojciechowski@xxxxxxx
Cc: Fabrice Le Fessant; bill@xxxxxxxxxx; dalzilio; moca@xxxxxxxxxxxxxxx
Subject: Re: [moca] Re: RE: RE : synchronous implementation of Pi
calculus with choice?
> The theoretical impossibility results, such as the impossibility of
> solving consensus in an asynchronous system when processes can crash
> (Fisher-Lynch-Paterson'85) can be overcome by strengthening the system
> model a bit, e.g. using failure detectors (Chandra-Toueg'95).
Not really, the impossibility result is just moved from inside the
model to outside, ie the impossibility of implementing the algorithm
is replaced by the impossibility of implementing the detectors, except
again on a LAN or on a limited number of nodes in a WAN.
> network will not make the system unusable. It is just that processes
> would be more often suspected to have failed and exluded from the current
> group view (they should then rejoin under a new name). Those processes
> that are within a current group view can deliver broadcast messages
> undisturbed.
Group communication systems are useful for some problems, not for all
problems. If you are working on peer-to-peer systems with 300 000
nodes, you can hardly build a group or something like
that. Fortunately, in such systems, the tolerance to failure is often
very simple, and you don't have to use a very powerful mechanisms to
cope with them, and to ensure the safety properties of your program.
- Fabrice
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The "models for mobility" mailing list mailto:moca@xxxxxxxxxxxxxxx
http://www-sop.inria.fr/mimosa/personnel/Davide.Sangiorgi/moca.html