summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authornobody <nobody@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2004-01-28 16:21:57 +0000
committernobody <nobody@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2004-01-28 16:21:57 +0000
commit85efe56995409004bcde3ce2b65ab874c04c9c86 (patch)
tree27ec5e2d177b88ca894bbafd3ff32804f4bd139f
parent08afa96a95aa09651a7fda230e8789f9cc2cddb2 (diff)
downloadATCD-85efe56995409004bcde3ce2b65ab874c04c9c86.tar.gz
This commit was manufactured by cvs2svn to create branch
'unlabeled-1.2.2'.
-rw-r--r--protocols/ace/TMCast/README58
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>