=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.7 retrieving revision 1.13 diff -u -p -r1.7 -r1.13 --- OpenXM/doc/issac2000/session-management.tex 2000/01/15 03:46:27 1.7 +++ 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.6 2000/01/15 00:20:46 takayama Exp $ +% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.12 2000/01/17 07:15:52 noro Exp $ \section{Session Management} \label{secsession} @@ -6,20 +6,54 @@ %Security (ssh PAM), initial negotiation of byte order, %mathcap, interruption, debugging window, etc. -In this section we show the realization of control integration in -OpenXM. In OpenXM it is assumed that various clients and servers +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 unify the communication interface -and the method of communication establishment. Besides, interruption -of an execution and debugging are common operations when we use -programming systems. OpenXM provides a method to realize them for -distributed computation. +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 execution and +debugging facilities +are necessary for interactive distributed computation. -\subsection{Interface of servers} +%\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. -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, +\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 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 client and a server have different byte orders. It is determined by exchanging the preferable byte order of each peer. If the preference @@ -31,120 +65,100 @@ order. Nevertheless it is necessary to negotiate the b skip the byte order conversion because its cost is often dominant over fast networks. -\subsection{Invocation of servers} -\label{launcher} -In general it is complicated to establish a connection over TCP/IP. -On the other hand a server itself does not have any function to -make a connection. In order to fill this gap an application called -{\bf launcher} is provided. A connection is established by using -the launcher as follows. - -\begin{enumerate} -\item A launcher is invoked from a client or by hand. -When the launcher is invoked, a port number for TCP/IP connection -and the name of a server should be informed. -\item The launcher and the client establish a connection with the -specified port number. -\item The launcher create a process and execute the server after -setting the binary I/O channels 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}. - \subsection{Control server} \label{control} -When we use a mathematical software, an execution time or necessary -storage is often unknown in advance. Therefore it is desirable -to be able to abort an execution and to start another execution. -In OpenXM we adopted the following simple and robust method. +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 {\bf -control server}. In contrast, we call a server for computation an {\bf -engine}. In this case the control server and the engine runs on the -same machine and it is easy to manipulate the engine, especially to -send a signal from the control server. A control server is also an -OpenXM stackmachine and it accepts {\tt SM\_control\_*} commands +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 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 connection} +\subsection{Resetting an engine} -By using the control channel a client can send a signal to an engine -at any time. However, I/O operations are usually buffered and several -additional operations on buffers after sending a signal is necessary -to reset connections safely. Here a safe resetting means the -following: +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 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 connection. 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 If an {\tt OX} message is being sent or received, then -the engine completes it. This does not block because -the client reads and skips {\tt OX} messages soon after sending -{\tt SM\_control\_reset\_connection}. -\item The engine sends {\tt OX\_SYNC\_BALL} to the client. -\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} -{\tt OX\_SYNC\_BALL} means an end mark of the data remaining in the -I/O streams. After reading it it is assured that each stream is empty +\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 receives +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} -To help debugging on the server, various supports are possible. 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. 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