Objetivos y requisitos operacionales de las radiocomunicaciones de

As pointed out in [144], reliability and performance are the two primary reasons for replicating data. When a distributed system such as a RTCES utilizes replicas of the shared document, local response time (performance) is improved, but communication costs increase; further, reliability is increased because each user has a copy of the shared document, so if one user’s replica is lost, the other users may communicate the document state to restore the session for that user.

We may increase the reliability and fault tolerance by replicating the top portion of the document tree among all peers (or a subset of peers). For reliability, a few upper nodes may be replicated (shared) using an OT policy. While this increases the cost in processing the OBTAINLOCK and REMOVELOCK algorithms (since all peers must perform OT to maintain consistency regarding the lock states among the shared top portion of document tree), this approach does overcome the single point of failure of a single server (or a single peer) managing the root. This replica-based approach for the top of the tree is visualized in Figure 66. Here, the top two levels of the tree are replicated among all users in the RTCES, and OT consistency maintenance is applied to ensure each replica contains the same state for node coloring and ownership. At depth 3 and below, individual users (user 1 = blue, user 2 = green, user 3 = red, and user 5 = orange)

maintain the document tree state and handle specific lock release and request operations in these sub-trees.

Figure 66: Replication of the Top of the Document Tree and Localized Management Below

While our initial client-server dynamic locking approach reduces this communication time, since most messages (all non-OT update messages) pass through it, the server suffers as a bottleneck for communication. Our motivation in developing the peer-to-peer version of our dynamic locking algorithms was to avoid this problem by distributing the work of lock management among the peers. Initially, it would seem that this work and communication is distributed uniformly among the peers, but the drawback remains that all messages must be processed from the root down. The grey counts must be maintained from the root down to ensure proper promotion and demotion. Thus if a single peer is responsible for managing each node in the tree, some

peer must maintain the root and will then become the bottleneck as in the client-server approach.

To address this problem of congestion and an imbalance of the workload falling to a single peer who manages the root node, we examine how this workload may be balanced among multiple peers. Note that in Figure 59 the root is managed by User 1 since User 1 was the first user to enter the RTCES, and unless another policy is adopted to balance the workload of the root, User 1 will continue to manage the root until he leaves the RTCES. Thus all OBTAINLOCK and RELEASELOCK requests must pass

through User 1 – creating an imbalance in the workload. We correct this by noting that it is possible to implement a shifting approach to managing the root as follows. When an OBTAINLOCK operation is performed, the user requesting the operation begins managing the nodes along the path in the document tree visited in fulfilling the OBTAINLOCK operation. But when a RELEASELOCK operation is performed, this implies

that the user is leaving a section and thus it is not advantageous to have the user begin managing the nodes along the path in the document tree visited in fulfilling the RELEASELOCK operations. In this manner, we adopt a “most recently requested” policy in that all nodes ni will be managed by the user who’s OBTAINLOCK request was fulfilled

by passing through ni (i.e., n1, n2, … nk is in the path from the root to nk, where nk is the desired node or the node at which the lock request is fulfilled).

If such a “most recently requested” policy for lock management is adopted, then the most consecutive requests a single peer p must serve would be O(n) where n is the number of peers in the collaboration. This is true because if an OBTAINLOCK request is

requests can be fulfilled and keep the same manager p, and there can be at most n consecutive RELEASELOCK request since any more would necessitate a lock request (i.e.,

a peer can’t release a lock it doesn’t have). Given the repetitive nature of lock request and release of users moving from section to section of a document, the workload of managing the nodes within the document tree should be balanced as the amortized time a peer manages a node should be approximately equal to the amortized time the other peers manage the node. We also note that the time a peer manages a node is proportional to the depth of the node in the document tree (since there are fewer paths that travel through a node at a greater depth than a node at a more shallow depth). Thus the root management should change more often than a near-leaf node. This is good because the workload of more shallow nodes in the tree (closer to the root) is more than the workload of deeper nodes. As a result, an in particular if users’ editing patters enable a higher degree of caching (via clustered editing patters), the workload in managing the distributed P2P version of the document tree should be balanced among the peers.