Go backward to 5 Session Operation
Go up to Top
Go forward to 7 Conclusions
The task of the interceptor process is threefold (see Figure 6):
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  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:
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 , 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:
The methods sketched above may be implemented in any language or system with appropriate multithreading and networking facilities; Java is probably an excellent choice .