diff options
author | nobody <nobody@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2004-01-28 16:21:57 +0000 |
---|---|---|
committer | nobody <nobody@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2004-01-28 16:21:57 +0000 |
commit | 85efe56995409004bcde3ce2b65ab874c04c9c86 (patch) | |
tree | 27ec5e2d177b88ca894bbafd3ff32804f4bd139f | |
parent | 08afa96a95aa09651a7fda230e8789f9cc2cddb2 (diff) | |
download | ATCD-85efe56995409004bcde3ce2b65ab874c04c9c86.tar.gz |
This commit was manufactured by cvs2svn to create branch
'unlabeled-1.2.2'.
-rw-r--r-- | protocols/ace/TMCast/README | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/protocols/ace/TMCast/README b/protocols/ace/TMCast/README new file mode 100644 index 00000000000..43e35c52388 --- /dev/null +++ b/protocols/ace/TMCast/README @@ -0,0 +1,58 @@ + + +Architecture + +TMCast (stands for Transaction MultiCast) is an implementation of a +transactional multicast protocol. In essence, the idea is to represent +each message delivery to members of a multicast group as a transaction - +an atomic, consistent and isolated action. A multicast transaction can +be viewed as an atomic transition of the group members to a new state. +If we define [Mo] as a set of operational (non-faulty) members of the +group, [Mf] as a set of faulty members of the group, [Ma] as a set of +members that view transition [Tn] as aborted and [Mc] as a set of members +that view transition [Tn] as committed, then this atomic transition [Tn] +should satisfy one of the following equations: + +Mo(Tn-1) = Ma(T) U Mf(T) +Mo(Tn-1) = Mc(T) U Mf(T) + +Or, in other words, after transaction T has been committed (aborted), +all operational (before transaction T) members are either in the +committed (aborted) or failed state. + +Thus, for each member of the group, outcome of the transaction can +be commit, abort or a member failure. It is important for a member +to exhibit a failfast (error latency is less than transaction cycle) +behavior. Or, in other words, if a member transitioned into a wrong +state, it is guaranteed to fail instead of delivering a wrong result. + +In order to achieve such an error detection in a decentralized +environment, certain limitations were imposed. One of the most +user-visible limitation is the fact that the lifetime of the group +with only one member is very short. This is because there is not way +for a member to distinguish "no members yet" case from "my link to the +group is down". In such a situation, the member assumes the latter case. +There is also a military saying that puts it quite nicely: two is one, +one is nothing. + + +State of Implementation + +The current implementation is in a prototypical stage. The following +parts are not implemented or still under development: + +* Handling of network partitioning (TODO) + +* Redundant network support (TODO) + +* Member failure detection (partial implementation) + + +Examples + +There is a simple example available in examples/TMCast/Member with +the corresponding README. + + +-- +Boris Kolpackov <boris@dre.vanderbilt.edu> |