ChangeLogTag: Wed Jan 28 10:26:17 2004 Boris Kolpackov <boris@dre.vanderbilt.edu>

1 files changed, 23 insertions, 23 deletions

diff --git a/protocols/ace/TMCast/README b/protocols/ace/TMCast/README
index d061c7b2cba..43e35c52388 100644
--- a/protocols/ace/TMCast/README
+++ b/protocols/ace/TMCast/README
@@ -4,42 +4,42 @@ Architecture
 
 TMCast (stands for Transaction MultiCast) is an implementation of a
 transactional multicast protocol. In essence, the idea is to represent
-message delivery to members of a multicast group as a transaction - 
-atomic, consistent and isolated action. Multicast transaction can
-be viewed as an atomic transition of 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
-can be described as one of the following:
+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 
+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 member failure. It is important for a member
+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 the member transitioned into a wrong 
-state, it is guaranteed to fail instead of delivering wrong result.
-
-In order to achieve such error detection in decentralized environment,
-certain limitations should be 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 situation, the member assumes the latter case. 
+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
 
-Current implementation is in prototypical stage. The following parts 
-are not implemented or still under development:
+The current implementation is in a prototypical stage. The following 
+parts are not implemented or still under development:
 
 * Handling of network partitioning (TODO)
 
@@ -51,8 +51,8 @@ are not implemented or still under development:
 Examples
 
 There is a simple example available in examples/TMCast/Member with 
-corresponding README.
+the corresponding README.
 
 
 -- 
-Boris Kolpackov <boris@dre.vanderbilt.edu>
\ No newline at end of file
+Boris Kolpackov <boris@dre.vanderbilt.edu>