=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.3 retrieving revision 1.7 diff -u -p -r1.3 -r1.7 --- OpenXM/doc/issac2000/session-management.tex 2000/01/04 09:14:14 1.3 +++ OpenXM/doc/issac2000/session-management.tex 2000/01/15 03:46:27 1.7 @@ -1,7 +1,7 @@ -% $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.6 2000/01/15 00:20:46 takayama Exp $ \section{Session Management} - +\label{secsession} %MEMO: key words: %Security (ssh PAM), initial negotiation of byte order, %mathcap, interruption, debugging window, etc. @@ -17,32 +17,16 @@ distributed computation. \subsection{Interface of servers} -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 +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. @@ -60,15 +44,13 @@ the launcher as follows. \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 +\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 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. +setting the binary I/O channels 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}. @@ -77,39 +59,20 @@ itself. As for a control server see Section \ref{contr 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. 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 +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 maniputalate the engine, especially to +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 the following {\tt SM} commands are provided. +OpenXM stackmachine 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. - -\item {\tt SM\_control\_kill} -It requests a control server to terminate an engine. - -\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 @@ -137,20 +100,18 @@ initiate a safe resetting of a connection. We show the a server and a client from the initiation to the completion of a resetting. -\noindent -\fbox{client} +\centerline{\fbox{client}} \begin{enumerate} \item The client sends {\tt SM\_control\_reset\_connection} to the -control server. +control server. The control server sends {\tt SIGUSR1} to the engine. \item The client enters the resetting state. it skips all {\tt -OX} messages from the engine until it recieves {\tt OX\_SYNC\_BALL}. +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} +\centerline{\fbox{engine}} \begin{enumerate} \item After receiving {\tt SIGUSR1} from the control server, @@ -161,52 +122,30 @@ the client reads and skips {\tt OX} messages soon afte {\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}. +receives {\tt OX\_SYNC\_BALL}. \item 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. +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. +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 +{\tt OX\_SYNC\_BALL}. -\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} - -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 +\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, 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 +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 +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.