Go backward to 4 Notebook Control
Go up to Top
Go forward to 6 Interceptor Operation
Our basic model for the operation of a distributed education session is as follows:
In order to demonstrate the basic operation principles, we will start with a only-lecturer mode from which the distributed operation modes are derived.
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
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.
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
creates a notebook duplicate in the respective frontend (see left diagram in
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).
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
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.
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.