Interprocess Communication

Instead of communicating through a repository, user processes can

directly exchange information with each other using some form of interprocess communication (IPC). Several forms of interprocess communication have been developed ranging from simple message passing to remote procedure call. We do not distinguish among them here unless necessary. We assume that they enable a process to communicate data to another process, allow a process to declare its intention to get data from multiple processes, and notify a receiving process when the data arrives, either by unblocking the receiver if it is waiting or invoking an asynchronous callback, if it is not.

Interprocess communication allows programmers to implement collaborative applications in arbitrary ways. There are two main approaches we can use when trying to code such applications:

• Replication: Implement as much of the application functionality as possible at the local workstation of each user, thereby creating an application replica at each site. It is not possible to implement the complete functionality at the local workstation since linkage between users implies that there has to be some communication among their replicas. Moreover, these are not true ``replicas'' as as the linkage between users may not be WYSIWIS.

• Centralization: Implement as much of the application functionality as possible in a single, master, process executing at some central site. It is not possible to implement all of the application functionality in a central site, since some code must be executed at the local site to display output on the local workstation and receive input from it. In general, the extent of this code depends on the I/O package used by the application programmer to (e.g virtual terminal package, curses library, window-system, toolkit ) interact with a user. Assuming that the I/O package allows a process to interact with a single user, we would have to implement a separate I/O manager, for each user, which would interact with the user through the I/O package. It would receive input from I/O package and transmit it to the master; and, conversely, receive output from the master, and give it to the I/O package.

In both cases, we would need a session manager responsible for allowing users to dynamically join and leave the conference, and a name server responsible for associating session managers with session names. Moreover, we would user IPC to communicate among the various application processes.

We will compare these two approaches in depth later - for now it is enough to assume that the centralized application is easier to implement while the replicated application gives better interactive performance by localizing the processing of operations. Here we present them mainly to show some of the ways in which IPC can be used in the construction of a collaborative applications.

Example-Replicated Case: As in the previous cases, a process or replica is created at the local workstation of each user, which displays the greeting string and allows the user to edit it. Also we create a session manager, which creates the session and keeps track of all the replicas and the current value of the greeting.

A user creates a new session by invoking the session manager, giving it the session name:

session -name ourHelloWorld

The session manager registers under the session name

with a name server. When a user joins the session:

helloWorld -join ourHelloWorld

the new replica uses the name server to lookup the session manager, registers itself with the session manager, looks up the current greeting and replicas registered with the session manager, and informs the replicas that it has joined the session.

On each keystroke, a replica uses the IPC mechanism to send the input character to all other replicas and the session manager, which immediately modify their local strings and update the screens. (Could we have done without the session manager process?)

Example-Centralized Case: A single master process is started at some central site:

helloWorld -name ourHelloWorld

join -name ourHelloWorld

An IPC system does not have the drawback of disk-resident data. Since we assume that it notifies processes when messages arrive, w it does not have the problem of polling. If it supports communication of only simple types such as strings, then it does suffer from the impedance mismatch problem, since structured types must be converted to/from the simple types. Some IPC systems do allow processes to exchange values of arbitrary types [], doing automatic marshalling and unmarshalling of data, and thus, do not suffer from this problem.

On the other hand, these benefits come at the cost of several drawbacks: An IPC mechanism does not know which parts of the communicating processes' state are shared or persistent data structures and simply provides a high-level scheme for communicating information. As a result, it cannot automatically offer persistence, concurrency control, access control, versioning, merging, or querying, which have to be implemented by the application programmer. It also does not automate session naming, which must be implemented by a separate name server. Another important drawback of this mechanism is that it require a process interacting with a user to be agent aware, that is, aware of the identities of processes (agents) interacting with other users. In the centralized case, the master process is aware of all the I/O agents, while in the replicated process, each replica is aware of other replicas. As a result, the programmer of a process must write code that reacts to a new user joining and leaving a session. The repository-based approaches have none of these drawbacks.