Implementation

In this section I will point out two issues with the above systems that compli- cate infrastructure and/or application implementation: state machine problems and container requirements.

State Machines

In general, moving or copying state machines and keeping state machine replicas up to date can be both inefficient and difficult to implement, as is attested to by the literature on XTV and other window sharing systems and Chung’s logging in- frastructure[LJLR90][Pat90][CJAW93][AWJ94][CD96][CDR98][Chu02]. This applies to both model state, which is usually unavoidably represented by a state machine, and view state, which often is but need not be represented by a state machine. It also applies to local state in view components that update other state using constraints or functions. Difficulties include:

• Divergent containers. Usually replica containers (execution environments) are mostly, but not entirely, identical. Examples are differences in available fonts and color representations in the X Window System, applications or in- frastructures installed on some systems but not others, and applications or infrastructures installed to different revision levels.

• Uncontrolled inputs. Generalizing on the divergent container issue, it is very often the case that state machines have inputs which are not under the control of the infrastructure attempting to set the component’s state. Examples are files, environment variables, and interrupts. This can cause non-deterministic state changes, making it difficult or impossible to ensure that the desired state has been achieved. Non-deterministic state changes are often impossible to detect,

and their effects on a component’s behavior can be hidden until arbitrarily distant times in the future.

• Timing dependencies. A special case of uncontrolled inputs is timing depen- dencies (where time is the uncontrolled input). Timing dependencies can also lead to non-determinism. They are much more difficult to control than other inputs.

• Non-idempotent operations. State machines not only change state in re- sponse to inputs, they also emit outputs. Often, especially in the case of models, the outputs they emit are non-idempotent. Writing to a file, sending email mes- sages, and communicating with external processes are three examples. A more subtle example is making changes to a display that are visible to a user, since the user is capable not only of observing the current state, but of remembering the sequence of observed events. Non-idempotent operations in general can oc- cur when a state machine changes state that is outside the bounds of the state machine itself, which it therefore cannot fully control.

• Representation mappings. Logically identical state in two replicas may require physically different representations. This requires representation map- pings to be performed when creating or updating a replica. Examples are re- source identifiers and color specifications in the X Window System.

• State accessibility. It may be difficult or impossible to retrieve or set the desired state.

Of the systems described, XTV and Chung’s infrastructure manipulate state ma- chine components. Rendezvous and Weasel3 _{also have local state which must be}

treated as a state machine.

Container Requirements

Container requirements are critical in distributed systems, whether the compo- nents executing in these containers are represented as state machines or not. In distributed systems, container requirements go beyond the obvious need for contain- ers to provide all the facilities and resources required by a contained component. Distributed systems imply multiple, independent execution environments (contain- ers). Infrastructures must have guarantees about these containers in order to ensure that the operations they perform will have the specified effect. At a minimum, the infrastructure must be able to detect container properties that may differ from sys- tem to system. Ideally, containers should make guarantees of identicality. Two useful methods that help achieve such guarantees are to ensure that the container require- ments are extremely simple and well-defined, and to restrict inputs to a container to a minimum. Security and idempotency concerns motivate restricting container outputs to a simple, well-defined minimum as well.

Another strategy for achieving container identicality is to distribute sub-containers from a central location. For example, if the operating system satisfies the necessary guarantees as an outer container, portable application code can be delivered from a central location to ensure that the application-level container is identical at all sites, rather than depending upon the operating system to have the proper application at the proper revision level installed.

The container requirements of the systems described above are as follows:

• XTV:For each model container, it requires an operating system with the same version of the X client application installed, any external resources the client

might need, and TCP/IP. For the view container, it requires an X server. Any differences in X servers are discernable using the X protocol. The infrastructure (pseudo-server) only needs an operating system supporting TCP/IP and the infrastructure code itself.

• Chung’s infrastructure: For each model container, it requires an operating system with the same version of the application installed, any external resources the application might need, and TCP/IP. The view container requirements de- pend on the system being logged. The infrastructure requirements are the same as XTV’s.

• Rendezvous: The central container requires the Rendezvous infrastructure, model and view code, any external resources the model code might need, and access to an X server. Since the model and views are not distributed, this is only required on one machine. The distributed version of Rendezvous is different in that it also requires the Rendezvous infrastructure on the view machines, and the view code is on the view machines instead of the central machine.

• Weasel: The model and view containers both require the Weasel infrastructure. The model code and any necessary external resources are only required on the model side, and the RVL runtime and the view code are only required on the view side. The model does not migrate.

• Clock: The model and view containers both require the Clock infrastructure. The model container also requires the model code and resources it needs, and the view container also requires the view code and access to an X server. The model does not migrate.