Go backward to 4 Notebook Control Go up to Top Go forward to 6 Interceptor Operation

5 Session Operation

Our basic model for the operation of a distributed education session is as follows:

1. The lecturer starts her local instance of the system consisting of frontend, kernel, and interceptor process.
2. Each other participant starts a corresponding local instance of the system (optionally without the kernel).
3. The interceptor of each participant gets connected to the interceptor of the lecturer.
4. The lecturer's interceptor subsequently multicasts messages to the interceptors of the audience.

In order to demonstrate the basic operation principles, we will start with a only-lecturer mode from which the distributed operation modes are derived.

5.1 Local Mode

When the education session is started, the lecturer triggers by her remote control the loading of a notebook from a file. The interceptor creates a corresponding message that lets the kernel execute a NotebookOpen command which in turn sends a message to the frontend to read in the corresponding notebook (see Figure 5.1).

Likewise, when the lecturer triggers a navigation event, the interceptor sends a message to the kernel to issue, e.g., a SelectionMove command. This in turn triggers a message from kernel to frontend to move the current notebook selection; this message is simply propagated by the interceptor.

If the lecturer triggers the evaluation of some active notebook content in the frontend by pressing the Shift-Return key, the frontend generates a message which the interceptor forwards to the kernel; likewise the response message from kernel to frontend is propagated in the other direction.

5.2 Controlled Mode

In controlled mode, the lecturer presents a notebook to all participants connected to the lecturer's host. This is the default operation mode of a distributed education session.

When the lecturer triggers the loading of the notebook, initially the same operation sequence is performed as in local mode. However, after the frontend has read the notebook, the lecturer's interceptor simulates the kernel command NotebookGet by sending a corresponding message to the local frontend. The frontend responds by a message that contains the content of the notebook loaded. This message is multicast to the interceptors of all participants which in turn simulate the command NotebookPut that creates a notebook duplicate in the respective frontend (see left diagram in Figure 5.2).

In a similar way, every message triggered by the lecturer's kernel in response to a navigation command is not only propagated to the local frontend but also multicast to all other frontends. As a net effect, the lecturer controls the operation of every frontend. Consequently, in controlled mode the audience does not need local kernels for participation (see right diagram in Figure 5.2).

5.3 Independent Mode

In independent mode, the lecturer allows all participants to exercise on the notebook copies loaded in their local frontends.

When the lecturer switches from controlled mode to independent mode, a corresponding release message is multicast to the interceptors of all participants (see Figure 5.3). If no local kernel is available on some host, the corresponding participant remains in controlled mode.

Otherwise, the participant's interceptor issues a message corresponding to a NotebookGet command, receives the current notebook content from the frontend and saves it for later reuse. It then starts a local Mathematica kernel (if available and not yet started) and sends a message to the kernel to execute a NotebookOpen command. This command is responded by the interceptor (since the notebook is already loaded in the frontend) by a reply message corresponding to that one that was delivered by the lecturer's frontend after it had read in the notebook.

During independent mode, each participant's interceptor simply propagates messages from frontend to kernel and vice versa. The participant can thus experiment with active notebook contents, run examples, and update the notebook with corresponding results.

When the lecturer triggers return to controlled mode by a hold message, she may optionally also retrieve the updated notebooks stored in the frontends of the session participants. Each interceptor therefore sends to the local frontend a message simulating a NotebookGet command to which the frontend responds with the current notebook content. This content is returned to the lecturer's interceptor and stored there in a file. Each interceptor returns to controlled operation by placing the original notebook (saved before switching into independent mode) into the frontend again.

5.4 Control Transfer

In controlled mode, the lecturer may also decide to temporarily transfer control to one of the participants (e.g. for presenting results).

The participant's system then may behave in a similar way as the lecturer's system controlling the operation of all other frontends. Different from the lecturer's behavior, however, the participant does not directly multicast messages to all other participants but forwards each message to the lecturer who in turn multicasts it. Consequently, only the lecturer's host needs to hold connection to the audience.