Go backward to 5 Session Operation Go up to Top Go forward to 7 Conclusions

6 Interceptor Operation

The task of the interceptor process is threefold (see Figure 6):

• It must present itself to the frontend as a kernel.
• It must present itself to the kernel as a frontend.
• It must collaborate with one or many other interceptor processes and interact with its own control interface, kernel process and frontend process to implement a consistent distributed session.

The first two requirements ensure that the interceptor is transparent to both the frontend and the kernel. Thus the Mathematica system itself needs not be aware of the distributed application context; all distributed interaction is solely handled by the interceptor. The third requirement touches the actual core of the system's functionality.

The protocols that have to meet these demands were informally sketched in the previous sections. Formally, the interceptor process can be modeled as an input/output automaton [6] that accepts messages from any input channel (frontend, kernel, control interface, other interceptors) and acts accordingly by changing its internal state and/or sending output messages.

In the following, we will focus on one particular technical aspect of the interceptor process, the implementation of multicasting (one-to-many communication) by the interceptor on the lecturer's host to the hosts of the audience. This interceptor has to multicast the following types of data:

• Notebook contents (from frontend, large).
• Control messages and user input (from control interface and frontend, small to medium size).
• Computation results (from kernel, often small but potentially large).

The utilized multicasting scheme must be reliable, i.e., messages must not be lost, duplicated, or reordered, because otherwise inconsistencies among different notebook instances may occur. On the other hand, state changes of different notebook instances need not be synchronized, i.e., it is not necessary to wait until all participants have acknowledged the receipt of a message before the next message may be multicast. On the contrary, if the connection to one particular participant is slow or unreliable, the lecturer and the other participants should not be punished by an overall bad performance of the system.

While there exist a variety of fault-tolerant multicasting algorithms [9], a pragmatic solution that meets the demands sketched above is to apply multiple concurrent threads (see Figure 6). Each thread maintains a reliable connection to one particular host, independently reads the next multicast message from a queue and sends it to the respective receiver. Communication may be based on a reliable basic protocol with explicit message acknowledgments (TCP) or on an unreliable basic protocol (UDP) with application-level reliability established by, e.g., a sequence numbering scheme; each thread may also hold multiple communication lines with different protocols for the different kind of data sketched above.

By this form of multithreaded multicasting scheme, the various session participants are totally decoupled from each other. Moreover, additional participants may join the session late and still experience the same sequence of events (represented by messages in the lecturer's queue). Of course, this raises the question when a message may be erased at all; two possibilities are:

• A message is erased from the buffer when all threads currently connected to the session have transmitted the message. A participant may join the session only at those points that put the local frontend in a state independent of the previous event history (e.g., when a new notebook is loaded).
• A message is buffered until all threads have transmitted a subsequent message that puts their respective frontends into a state independent of the previous history. A participant may join the session at any time since the history since the last such event can be replayed.

The methods sketched above may be implemented in any language or system with appropriate multithreading and networking facilities; Java is probably an excellent choice [5].