=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.3 retrieving revision 1.13 diff -u -p -r1.3 -r1.13 --- OpenXM/doc/issac2000/session-management.tex 2000/01/04 09:14:14 1.3 +++ OpenXM/doc/issac2000/session-management.tex 2000/01/17 08:50:57 1.13 @@ -1,212 +1,165 @@ -% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.2 2000/01/02 07:32:12 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} %MEMO: key words: %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 the following I/O streams at its startup. The numbers -indicate stream descriptors. - -\begin{description} -\item{\bf 1} standard output -\item{\bf 2} standard error -\item{\bf 3} input from a client -\item{\bf 4} output to a client -\end{description} - -A server reads data from the stream {\bf 3} and writes results to the -stream {\bf 4}. The streams {\bf 1} and {\bf 2} are provided for -diagnostic messages from the server. As {\bf 3} and {\bf 4} are -streams for binary data, the byte order conversion is necessary when a -client and a server have different byte orders. There are several -methods to treat it and we adopted the following scheme. - -\begin{itemize} -\item A server writes 1 byte representing the preferable byte order. -\item After reading the byte, a client writes 1 byte representing the -preferable byte order. -\item On each side, if the preference coicides with each other then -the byte order is used. Otherwise the network byte order is used. -\end{itemize} - -This implies that all servers and clients can 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} -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. +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 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 conection with the -specified port number. -\item The launcher create a process and execute the server after -setting the streams {\bf 3} and {\bf 4} appropriately. -An application to display messages written to the streams {\bf 1} and -{\bf 2} may be invoked if necessary. +\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} -Though the above is all the task as a launcher, the launcher process +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 +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} -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. -On a usual session on UNIX it is done by an interruption from a keyboard. -Internally it is realized by an exeption processing initiated by -a {\bf signal}, but it is not easy to send a signal to a server. -Especially if a server and a client run on different machines, -the client cannot send a signal to the server directly. -Though Some operating systems provide facilities to attach -signals such as {\tt SIGIO} and {\tt SIGURG} to a stream data, they are -system dependent and lack robustness. -On 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 controling computations. The +data for computations and the other for controlling computations. The control channel is used to send commands to control execution on the -server. There are several ways of implementing the control channel. -Among them it is common to use the launcher introduced in Section -\ref{launcher} 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 maniputalate the engine, especially to -send a signal from the control server. A control server is also an -OpenXM stackmachine and the following {\tt SM} commands are provided. +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 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. -\begin{description} -\item {\tt SM\_control\_reset\_connection} -It requests a control server to send the {\tt SIGUSR1} signal. +\subsection{Resetting an engine} -\item {\tt SM\_control\_kill} -It requests a control server to terminate 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. -\item {\tt SM\_control\_intr} -It requests a control server to send the {\tt SIGINT} signal. -\end{description} - -\subsection{Resetting a connection} - -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: - \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. +\vskip 2mm \noindent -\fbox{client} - +{\it Client side} \begin{enumerate} -\item The client sends {\tt SM\_control\_reset\_connection} to the -control server. -\item The client enters the resetting state. it skips all {\tt -OX} messages from the engine until it recieves {\tt OX\_SYNC\_BALL}. +\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} \noindent -\fbox{engine} - +{\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 -recieves {\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 the stream is empty -and that a request from a client correctly corresponds to the response -from the server. For a safe resetting, it is important that the -following actions are executed always in that order. +\begin{figure}[htbp] +\epsfxsize=8.5cm +\epsffile{reset.eps} +\caption{OpenXM reset procedure} +\label{reset} +\end{figure} -\begin{enumerate} -\item A signal is sent to an engine by a request from a client. -\item The engine sends {\tt OX\_SYNC\_BALL} to the client. -\item The client sends {\tt OX\_SYNC\_BALL} to the engine after -receiving {\tt OX\_SYNC\_BALL}. -\end{enumerate} +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}. -This assures that the peer is in the resetting state when one receives -{\tt OX\_SYNC\_BALL}. By this fact we don't have to associate it with -any special action to be executed by the server. Especially it can be -ignored if processes are in the usual state. If the above order is not -preserved, then both {\tt SM\_control\_reset\_connection} and {\tt -OX\_SYNC\_BALL} must initiate an engine into entering the resetting -state, and it makes the resetting scheme complicated and it may -introduce unexpected bugs. For example, if a client sends {\tt -OX\_SYNC\_BALL} without waiting {\tt OX\_SYNC\_BALL} from the engine, -then it is possible that the engine recieves it before the arrival of -the signal. We note that we really encountered serious bugs caused -by such an inappropriate protocol before reaching the final specicication. - -\subsection{Debugging} -An OpenXM server may allow definition and execution of functions -written in the user language proper to the server. To help debugging -such functions 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, which -makes it possible to display messages from the engine. Furthermore, if -the engine provides an inteface to input commands which directly -controls the engine, then debugging of user define programs will be -possible. For example {\tt Risa/Asir} provides a function {\tt -debug()} to debug user defined functions. {\tt ox\_asir}, which is -the OpenXM server of {\tt Risa/Asir}, pops up a window to input -debug commands when {\tt debug()} is executed on the server. -As the responses to the commands are displayed on the {\tt xterm}, -the debugging similar to that on usual terminals is possible. -Moreover one can send {\tt SIGINT} by using {\tt SM\_control\_intr} -and it provides a similar functinality to entering the debugging +\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.