=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.2 retrieving revision 1.12 diff -u -p -r1.2 -r1.12 --- OpenXM/doc/issac2000/session-management.tex 2000/01/02 07:32:12 1.2 +++ OpenXM/doc/issac2000/session-management.tex 2000/01/17 07:15:52 1.12 @@ -1,8 +1,165 @@ -% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.1 1999/12/23 10:25:09 takayama Exp $ +% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.11 2000/01/17 06:10:41 noro Exp $ -\section{Session Management} (Noryo) - -MEMO: key words: -Security (ssh PAM), initial negotiation of byte order, -mathcap, interruption, debugging window, etc. - \ No newline at end of file +\section{Session Management} +\label{secsession} +%MEMO: key words: +%Security (ssh PAM), initial negotiation of byte order, +%mathcap, interruption, debugging window, etc. + +In this section we explain our control integration in +OpenXM. We assume that various clients and servers +establish connections dynamically and communicate to each +other. Therefore it is necessary to give a dynamical and unified +method to start servers and to establish connections. +In addition to that, interruption of executions and +debugging facilities +are necessary for interactive distributed computation. + +%\subsection{Interface of servers} +% +%A server has additional I/O streams for exchanging data between +%a client and itself other than ones for diagnostic +%messages. As the streams are for binary data, +%the byte order conversion is necessary when a +%client and a server have different byte orders. It is determined by +%exchanging the preferable byte order of each peer. If the preference +%does not coincide with each other, +%then the network byte order is used. +%This implies that all servers and clients should be able to +%handle the network byte +%order. Nevertheless it is necessary to negotiate the byte order to +%skip the byte order conversion because its cost is often dominant over +%fast networks. + +\subsection{Invocation of servers} +\label{launcher} + +An application called {\it launcher} is provided to start servers +and to establish connections as follows. + +\begin{enumerate} +\item A launcher is invoked from a client. +When the launcher is invoked, the client +informs the launcher of a port number for TCP/IP connection +and the name of a server. +\item The launcher and the client establish a connection with the +specified port number. One time password may be used to prevent +launcher spoofing. +\item The launcher creates a process and executes the server after +setting the data channel appropriately. +\end{enumerate} + +After finishing the above task as a launcher, the launcher process +acts as a control server and controls the server process created by +itself. As to the control server see Section \ref{control}. + +As the data channel is used to exchange binary data, +the byte order conversion is necessary when a +client and a server have different byte orders. It is determined by +exchanging the preferable byte order of each peer. If the preference +does not coincide with each other, +then the network byte order is used. +This implies that all servers and clients should be able to +handle the network byte +order. Nevertheless it is necessary to negotiate the byte order to +skip the byte order conversion because its cost is often dominant over +fast networks. + + +\subsection{Control server} +\label{control} +In OpenXM we adopted the following simple and robust method to +control servers. + +An OpenXM server has logically two I/O channels: one for exchanging +data for computations and the other for controlling computations. The +control channel is used to send commands to control execution on the +server. The launcher introduced in Section \ref{launcher} +is used as a control process. We call such a process a {\it +control server}. In contrast, we call a server for computation an {\it +engine}. As the control server and the engine runs on the +same machine, it is easy to manipulate the engine, especially to +send a signal from the control server. A control server is also an +OpenXM stack machine and it accepts {\tt SM\_control\_*} commands +to send signals to a server or to terminate a server. + +\subsection{Resetting an engine} + +A client can send a signal to an engine by using the control channel +at any time. However, I/O operations are usually buffered, +which may cause troubles. +To reset an engine safely the following are required. + +\begin{enumerate} +\item Any OX message must be a synchronized object in the sense of Java. + +As an OX message is sent as a combination of several {\tt CMO} +data, a global exit without sending all may generate broken data. + +\item After restarting an engine, a request from a client +must correctly corresponds to the response from the engine. + +An incorrect correspondence occurs if some data remain on the stream +after restarting an engine. +\end{enumerate} + +{\tt SM\_control\_reset\_connection} is a stack machine command to +initiate a safe resetting of an engine. +The control server sends {\tt SIGUSR1} to the engine if it receives +{\tt SM\_control\_reset\_connection} from the client. +Under the OpenXM reset protocol an engine and a client act as follows. + +\vskip 2mm +\noindent +{\it Client side} +\begin{enumerate} +\item After sending {\tt SM\_control\_reset\_connection} to the +control server, the client enters the resetting state. It skips all {\tt +OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}. +\item After receiving {\tt OX\_SYNC\_BALL} the client sends +{\tt OX\_SYNC\_BALL} to the engine and returns to the usual state. +\end{enumerate} + +\noindent +{\it Engine side} +\begin{enumerate} +\item +After receiving {\tt SIGUSR1} from the control server, +the engine enters the resetting state. +The engine sends {\tt OX\_SYNC\_BALL} to the client. +The operation does not block because +the client is now in the resetting state. +\item The engine skips all OX messages from the engine until it +receives {\tt OX\_SYNC\_BALL}. After receiving {\tt OX\_SYNC\_BALL} +the engine returns to the usual state. +\end{enumerate} + +\begin{figure}[htbp] +\epsfxsize=8.5cm +\epsffile{reset.eps} +\caption{OpenXM reset procedure} +\label{reset} +\end{figure} + +Figure \ref{reset} illustrates the flow of data. +{\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the +I/O streams. After reading it, it is assured that each stream is empty +and that the subsequent request from a client correctly +corresponds to the response from the engine. +We note that we don't have to associate {\tt OX\_SYNC\_BALL} with +any special action to be executed by the engine because it is +assured that the engine is in the resetting state when it has received +{\tt OX\_SYNC\_BALL}. + +\subsection{Debugging facilities} +Debugging is sometimes very hard for distributed computations. +We provide two methods to help debugging on X window system: +1. the diagnostic messages from the engine are displayed in a {\tt xterm} +window; +2. the engine can pop up a window to input debug commands. +For example {\tt ox\_asir}, which is +the OpenXM server of Risa/Asir, can pop up a window to input +debug commands and the debugging similar to that on usual terminals is possible. +One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode} +and it provides a similar functionality to entering the debugging +mode from a keyboard interruption.