Código de comercio

Data perspective migration enables perspectives to quickly migrate from floor holder to floor holder, where the “floor” can be switched explicitly, or can be implic- itly determined by the infrastructure based on participant activity. Migration can happen extremely quickly, because perspectives can be replicated in a master/slave

relationship as discussed earlier and shown in Figure 3.11. (Note that latency is twice the network transmission time for all participants in this diagram.) The result of such a migration is shown in Figure 3.12. No actual data must be switched when the floor

Figure 3.12: Master/Slave Migration in a Centralized System

changes hands. (Note that latency is zero for the current floor holder, and four times network transmission time for all others.) Data perspectives are migrated indepen- dently, so that different perspective master replicas can be near different participants at any given point in time.

Timer perspectives need not migrate; their entire purpose is to provide state change for a particular participant, in synchrony with other participants.

Mobile models can migrate similarly to data perspectives. The main difference is that the model application observes the central slave replica of the mobile model so that it can react to its state changes (Figure 3.13). Applications can also explicitly demand the master role for the mobile model for a time, should they need to gain more control over the model for synchronization or other reasons. For example, an application may wish to become the master of all the paragraph mobile models in a document so that it can perform an atomic global replace operation in the entire

Figure 3.13: Mobile Models

document. The mobility of mobile models solves the most egregious latency problems in centralized systems, where such operations as typing or moving objects using direct manipulation are too slow because of frequent round trips to the central model.

Let’s revisit Figure 3.12 for a moment. If the master is not in the center and its machine or connection dies, the central slave will have a reasonably up-to-date version of the perspective or model, and can take over or reassign the master role. For data perspectives, having the most up-to-date value would normally be unimportant, since these interactions are transient and are never seen by the application. The lost up- to-date value at the failed master would most likely represent interactions of the floor holder, in which case the floor holder may have invoked the lost operation(s) and may have even seen feedback from those operations (which other participants would not have seen). In the latter case, the feedback seen would be rolled back when the floor holder participant rejoins the conference. If the lost updates were from a non- floor-holder they would represent actions taken by the non-floor-holder participant for which he has not yet seen feedback (but for which the floor holder may have seen

feed-through5_{). In this case and in the former case where the floor holder has not yet}

seen feedback from his interaction, the lost interactions would act as no-ops from the participant’s perspective.

For data perspectives, if this degree of fault tolerance is not necessary, the central slave can be eliminated and the central component can simply route perspective operations. In this case, perspective state may simply be lost, e.g., if there are no slaves and the master dies. The perspective can then be reset to a default state. This might be appropriate, e.g., for scroll bars or selections. One advantage of this special but common case is that if a perspective is not being shared at all, only a peripheral master copy need be maintained, eliminating all network traffic and central node processing for that perspective.

In the end, the centralized architecture has been adapted so that there are many independent centralized architectures, one for each data perspective or mobile model. This dramatically reduces latency issues and also spreads some of the load around, reducing classical centralized system bottlenecks. Immobile models would need to remain in a static central location, but mobile entities would be free to change the “center” (master) location freely and quickly. There would still be a static physical “center” through which all non-local communication would pass, but the current master would be the authority on the value of the entity. Usually social protocols and fine-grained entities will eliminate the cases where more than one participant is interacting with the same mobile entity simultaneously, but when this does happen the infrastructure can migrate the entity to the physical center to attain fair, consistent responsiveness for all users.

Migrating entities are often a better solution than locking, because locking implies 5_{Feed-through is evidence one participant sees of another participant’s actions.}

that everyone without the lock must wait. With migrating entities no one need wait for a lock, though responsiveness for non-floor holders will suffer. Migrating entities are also much easier to implement and are more predictable for users than replicated schemes, because concurrency control is accomplished through serialization at the master.