It is important that a shared application allow a latecomer to join other users who are already working together with the application. We have developed a latecomer accommodation service framework for centralized shared systems (applications and infrastructures). It employs an independent latecomer accommodation server that is dynamically composable with its clients. The server, also called the logger, logs a shared application's user interface (UI) changes in response to calls made by the client, also called the loggable. Later, when the time comes to accommodate a latccomer, the logger replays the logged changes to the loggable, which, in tum, creates the latecomer's user interface. To deal with UI protocols at different levels of abstraction, we have defined the API in terms of a generic UI model. This reduces the burden on a loggable from a complete service implementation to a translation between its specific UI protocol and our generic UI model. To reduce the space and time overhead, the logger performs complex log compression. The extent of compression depends on the amount of semantic knowledge that the loggable provides to the logger. In this paper, we motivate, describe and illustrate the approach, and outline how it is implemented.

Migrating collaborative applications to or near the workstations of active users can offer better performance in many scenarios. We have developed {3 client migration mechanism for centralized shared window systems that does not require changes to existing application and system software. It is based on logging input at the old site and replaying it at the new site. This approach raises several difficult questions: How should the log size be kept low? How should response time be kept low white migration is in progress? How should applications that depend on the rate at which input is received be accommodated?How should the transition from the replay phase to the play phase be detected at the new site? How should the software at the old and new sites be synchronized?We have developed a series of alternative approaches for answering these questions and implemented them in the XTV [1] shared window system. In this paper, we motivate, describe, illustrate and evaluate these approaches, and outline how they are implemented.

No abstract

No abstract

We have developed a formal performance model for centralized and replicated architectures involving two users, giving equations for response, feedthrough, and task completion times. The model explains previous empirical results by showing that (a) low network latency favors the centralized architecture and (b) asymmetric processing powers favor the centralized architecture. In addition, it makes several new predictions, showing that under certain practical conditions, (a) centralizing the application on the slower machine may be the optimal solution, (b) centralizing the application on the faster machine is sometimes better than replicating, and (c) as the duration of the collaboration increases, the difference in performances of centralized and replicated architectures gets magnified. We have verified these predictions through new experiments for which we created synthesized logs based on parameters gathered from actual collaboration logs. Our results increase the understanding of centralized and replicated architectures and can be used by (a) users of adaptive systems to decide when to perform architecture changes, (b) users who have a choice of systems with different architectures to choose the system most suited for a particular collaboration mode (defined by the values of the collaboration parameters), and (c) users locked into a specific architecture to decide how to change the hardware and other collaboration parameters to improve performance. Related WorkUnlike in traditional computer science fields such as databases and operating systems, there has been relatively little work in the collaboration domain on studying the performance of system architectures, even though, arguably, performance is more important in this field because of the human in the eventprocessing loop. As mentioned earlier, existing studies have been confined to gathering empirical data. Moreover, there have been very few studies that have directly targeted collaboration. One can, however, make some collaboration implications indirectly from studies of distributed window systems.Nieh, Yang, Novik et al. (2000) conducted experiments that measured the relative performances of two distributed window systems, the Linux implementation of VNC (Hopper, 1998) and Microsoft's Windows 2000 RDP implementation. The architecture used was essentially a two-user centralized architecture with the user at the hosting site inactive. Such a setup gives an idea of the performance experienced by a remote user interacting with a centralized program, assuming the host site does not become a bottleneck. These studies compared two different implementations of the centralized architecture and do not addresses the relative performances of different architecture configurations.Wong and Seltzer (2000) measured the network load for various remote user operations. Danskin and Hanrahan (1994) measured the frequencies of these operations. Together, these two results give an idea of the actual bandwidth requirements for a variety of remote desktop tasks. Two other studi...