Generic and Composable Latecomer Accommodation Service for Centralized Shared Systems

Abstract

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.

Timelines: simplifying the programming of lag compensation for the next generation of networked games

“…Janus currently truncates history to limit storage requirements. We plan to adapt algorithms for compacting history developed for solving the groupware latecomer problem [6], and mechanisms for compressing messages [17].…”

Towards dynamic collaboration architectures

“…With JS (= js 7,6 in Figure 9), t i,i+1 takes the other latecomers that want to use remote program replicas (user 7 in Figure 9), and allows them to join the collaboration session by dynamically replicating the user interface components on their computers, and making appropriate mappings for the user interface components.…”

“…Therefore, we use a technique to reduce the log size (and thus the time to replay it) to order of the number of "state objects" of an upto-date software component [6]. By "state objects", we mean the objects that, we deduce from logged messages, a software component maintains to implement its behavior.…”

Transparent Latecomer Support for Synchronous Groupware

“…Chung et al [3] describe a replay service for a central architecture. The service bases on a latecomer accommodation server which is called the logger.…”

“…The basic idea is to let the latecomer's site select a participating site that supports it with the complete history list H. The latecomer's site uses the stored messages in the history list H to re-execute the state changes and thus to replay how the session state was reached. As the history list only contains the messages that resulted in a state change, compared to the system by Chung et al [3], additional compression techniques are not necessary.…”