=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.8 retrieving revision 1.13 diff -u -p -r1.8 -r1.13 --- OpenXM/doc/issac2000/session-management.tex 2000/01/16 03:15:49 1.8 +++ OpenXM/doc/issac2000/session-management.tex 2000/01/17 08:50:57 1.13 @@ -1,4 +1,4 @@ -% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.7 2000/01/15 03:46:27 noro Exp $ +% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.12 2000/01/17 07:15:52 noro Exp $ \section{Session Management} \label{secsession} @@ -11,8 +11,9 @@ 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 an exections and debugging -supports are necessary for intaractive distributed computation. +In addition to that, interruption of execution and +debugging facilities +are necessary for interactive distributed computation. %\subsection{Interface of servers} % @@ -42,14 +43,15 @@ 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. +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 for a control server see Section \ref{control}. +itself. As to the details of 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 @@ -76,81 +78,87 @@ server. The launcher introduced in Section \ref{launch 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 +same machine, it is easy 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 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 without care for remaining data in -the buffers. To reset a server safely the following are required. +which may cause troubles. +To reset an engine safely the following are required. \begin{enumerate} -\item A sending of an {\tt OX} message must be completed. +\item Any OX message must be a synchronized object in the sense of Java. -As an {\tt OX} message is sent as a combination of several {\tt CMO} -data, a global exit without sending all the data confuses the -subsequent communication. +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 a server, a request from a client -must correctly corresponds to the response from the server. +\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 a server. +after restarting an engine. \end{enumerate} -{\tt SM\_control\_reset\_connection} is an {\tt SM} command to -initiate a safe resetting of a server. We show the action of -a server and a client from the initiation to the completion of -a resetting. +{\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. -\centerline{\fbox{client}} - +\vskip 2mm +\noindent +{\it Client side} \begin{enumerate} -\item The client sends {\tt SM\_control\_reset\_connection} to the -control server. The control server sends {\tt SIGUSR1} to the engine. -\item The client enters the resetting state. It skips all {\tt +\item After sending {\tt SM\_control\_reset\_connection} to the +control server, the client enters the resetting state. It discards 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} -\centerline{\fbox{engine}} - +\noindent +{\it Engine side} \begin{enumerate} -\item After receiving {\tt SIGUSR1} from the control server, +\item +After receiving {\tt SIGUSR1} from the control server, the engine enters the resetting state. -\item The engine sends {\tt OX\_SYNC\_BALL} to the client. -We note that the operation does not block because -the client reads and skips {\tt OX} messages soon after sending -{\tt SM\_control\_reset\_connection}. -\item The engine skips all {\tt OX} messages from the engine until it -receives {\tt OX\_SYNC\_BALL}. -\item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the -usual 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 discards 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 server. +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 server because it is -assured that the peer is in the resetting state when one has received +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 supports} -Debugging is not easy for distributed computations. -If servers are executed on X window system, then the control server can -attach an {\tt xterm} to the standard outputs of the engine to display -diagnostic messages from the engine. -Furthermore, if the engine provides an interface to input commands, -then debugging of user defined programs will be -possible on the engine. For example {\tt ox\_asir}, which is -the OpenXM server of {\tt Risa/Asir}, can pop up a window to input +\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