=================================================================== RCS file: /home/cvs/OpenXM/doc/issac2000/session-management.tex,v retrieving revision 1.5 retrieving revision 1.6 diff -u -p -r1.5 -r1.6 --- OpenXM/doc/issac2000/session-management.tex 2000/01/11 05:35:48 1.5 +++ OpenXM/doc/issac2000/session-management.tex 2000/01/15 00:20:46 1.6 @@ -1,4 +1,4 @@ -% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.4 2000/01/07 06:27:55 noro Exp $ +% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.5 2000/01/11 05:35:48 noro Exp $ \section{Session Management} \label{secsession} @@ -17,31 +17,14 @@ 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. Various -methods are possible 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 coincides with each other then -the byte order is used. Otherwise the network byte order is used. -\end{itemize} - +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 coincides 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 @@ -64,9 +47,7 @@ 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 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 @@ -78,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 exception 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. 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. 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 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 @@ -138,8 +100,7 @@ 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 @@ -150,8 +111,7 @@ OX} messages from the engine until it receives {\tt OX {\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, @@ -170,44 +130,22 @@ usual state. {\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. +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 receives 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 specification. - \subsection{Debugging supports} -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 +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 interface 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} +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\_intr} and it provides a similar functionality to entering the debugging mode from a keyboard interruption.