[BACK]Return to session-management.tex CVS log [TXT][DIR] Up to [local] / OpenXM / doc / issac2000

Diff for /OpenXM/doc/issac2000/session-management.tex between version 1.4 and 1.13

version 1.4, 2000/01/07 06:27:55 version 1.13, 2000/01/17 08:50:57
Line 1 
Line 1 
 % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.3 2000/01/04 09:14:14 noro Exp $  % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.12 2000/01/17 07:15:52 noro Exp $
   
 \section{Session Management}  \section{Session Management}
 \label{secsession}  \label{secsession}
Line 6 
Line 6 
 %Security (ssh PAM), initial negotiation of byte order,  %Security (ssh PAM), initial negotiation of byte order,
 %mathcap, interruption, debugging window, etc.  %mathcap, interruption, debugging window, etc.
   
 In this section we show the realization of control integration in  In this section we explain our control integration in
 OpenXM.  In OpenXM it is assumed that various clients and servers  OpenXM.  We assume that various clients and servers
 establish connections dynamically and communicate to each  establish connections dynamically and communicate to each
 other. Therefore it is necessary to unify the communication interface  other. Therefore it is necessary to give a dynamical and unified
 and the method of communication establishment.  Besides, interruption  method to start servers and to establish connections.
 of an execution and debugging are common operations when we use  In addition to that, interruption of execution and
 programming systems. OpenXM provides a method to realize them for  debugging facilities
 distributed computation.  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 coincides 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}  \subsection{Invocation of servers}
 \label{launcher}  \label{launcher}
   
 In general it is complicated to establish a connection over TCP/IP.  An application called {\it launcher} is provided to start servers
 On the other hand a server itself does not have any function to  and to establish connections as follows.
 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}  \begin{enumerate}
 \item A launcher is invoked from a client or by hand.  \item A launcher is invoked from a client.
 When the launcher is invoked, a port number for TCP/IP connection  When the launcher is invoked, the client
 and the name of a server should be informed.  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  \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
 \item The launcher create a process and execute the server after  launcher spoofing.
 setting the streams {\bf 3} and {\bf 4} appropriately.  \item The launcher creates a process and executes the server after
 An application to display messages written to the streams {\bf 1} and  setting the data channel appropriately.
 {\bf 2} may be invoked if necessary.  
 \end{enumerate}  \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  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}  \subsection{Control server}
 \label{control}  \label{control}
 When we use a mathematical software, an execution time or necessary  In OpenXM we adopted the following simple and robust method to
 storage is often unknown in advance. Therefore it is desirable  control servers.
 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  An OpenXM server has logically two I/O channels: one for exchanging
 data for computations and the other for controlling computations. The  data for computations and the other for controlling computations. The
 control channel is used to send commands to control execution on the  control channel is used to send commands to control execution on the
 server. There are several ways of implementing the control channel.  server. The launcher introduced in Section \ref{launcher}
 Among them it is common to use the launcher introduced in Section  is used as a control process. We call such a process a {\it
 \ref{launcher} as a control process. We call such a process a {\bf  control server}. In contrast, we call a server for computation an {\it
 control server}. In contrast, we call a server for computation an {\bf  engine}. As the control server and the engine runs on the
 engine}. In this case the control server and the engine runs on the  same machine, it is easy to send a signal from the control server.
 same machine and it is easy to manipulate the engine, especially to  A control server is also an
 send a signal from the control server. A control server is also an  OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
 OpenXM stackmachine and the following {\tt SM} commands are provided.  to send signals to a server or to terminate a server.
   
 \begin{description}  \subsection{Resetting an engine}
 \item {\tt SM\_control\_reset\_connection}  
 It requests a control server to send the {\tt SIGUSR1} signal.  
   
 \item {\tt SM\_control\_kill}  A client can send a signal to an engine by using the control channel
 It requests a control server to terminate an engine.  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}  \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}  As an OX message is sent as a combination of several {\tt CMO}
 data, a global exit without sending all the data confuses the  data, a global exit without sending all may generate broken data.
 subsequent communication.  
   
 \item After restarting a server, a request from a client  \item After restarting an engine, a request from a client
 must correctly corresponds to the response from the server.  must correctly corresponds to the response from the engine.
   
 An incorrect correspondence occurs if some data remain on the stream  An incorrect correspondence occurs if some data remain on the stream
 after restarting a server.  after restarting an engine.
 \end{enumerate}  \end{enumerate}
   
 {\tt SM\_control\_reset\_connection} is an {\tt SM} command to  {\tt SM\_control\_reset\_connection} is a stack machine command to
 initiate a safe resetting of a connection. We show the action of  initiate a safe resetting of an engine.
 a server and a client from the initiation to the completion of  The control server sends {\tt SIGUSR1} to the engine if it receives
 a resetting.  {\tt SM\_control\_reset\_connection} from the client.
   Under the OpenXM reset protocol, an engine and a client act as follows.
   
   \vskip 2mm
 \noindent  \noindent
 \fbox{client}  {\it Client side}
   
 \begin{enumerate}  \begin{enumerate}
 \item The client sends {\tt SM\_control\_reset\_connection} to the  \item After sending {\tt SM\_control\_reset\_connection} to the
 control server.  control server, the client enters the resetting state. It discards all {\tt
 \item The client enters the resetting state. it skips all {\tt  
 OX} messages from the engine until it receives {\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  \item After receiving {\tt OX\_SYNC\_BALL} the client sends
 {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.  {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
 \end{enumerate}  \end{enumerate}
   
 \noindent  \noindent
 \fbox{engine}  {\it Engine side}
   
 \begin{enumerate}  \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.  the engine enters the resetting state.
 \item If an {\tt OX} message is being sent or received, then  The engine sends {\tt OX\_SYNC\_BALL} to the client.
 the engine completes it. This does not block because  The operation does not block because
 the client reads and skips {\tt OX} messages soon after sending  the client is now in the resetting state.
 {\tt SM\_control\_reset\_connection}.  \item The engine discards all OX messages from the engine until it
 \item The engine sends {\tt OX\_SYNC\_BALL} to the client.  receives {\tt OX\_SYNC\_BALL}. After receiving {\tt OX\_SYNC\_BALL}
 \item The engine skips all {\tt OX} messages from the engine until it  the engine returns to the usual state.
 receives {\tt OX\_SYNC\_BALL}.  
 \item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the  
 usual state.  
 \end{enumerate}  \end{enumerate}
   
 {\tt OX\_SYNC\_BALL} means an end mark of the data remaining in the  \begin{figure}[htbp]
 I/O streams. After reading it it is assured that the stream is empty  \epsfxsize=8.5cm
 and that a request from a client correctly corresponds to the response  \epsffile{reset.eps}
 from the server.  For a safe resetting, it is important that the  \caption{OpenXM reset procedure}
 following actions are executed always in that order.  \label{reset}
   \end{figure}
   
 \begin{enumerate}  Figure \ref{reset} illustrates the flow of data.
 \item A signal is sent to an engine by a request from a client.  {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
 \item The engine sends {\tt OX\_SYNC\_BALL} to the client.  I/O streams. After reading it, it is assured that each stream is empty
 \item The client sends {\tt OX\_SYNC\_BALL} to the engine after  and that the subsequent request from a client correctly
 receiving {\tt OX\_SYNC\_BALL}.  corresponds to the response from the engine.
 \end{enumerate}  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  \subsection{Debugging facilities}
 {\tt OX\_SYNC\_BALL}. By this fact we don't have to associate it with  Debugging is sometimes very hard for distributed computations.
 any special action to be executed by the server. Especially it can be  We provide two methods to help debugging on X window system:
 ignored if processes are in the usual state. If the above order is not  1. the diagnostic messages from the engine are displayed in a {\tt xterm}
 preserved, then both {\tt SM\_control\_reset\_connection} and {\tt  window;
 OX\_SYNC\_BALL} must initiate an engine into entering the resetting  2. the engine can pop up a window to input debug commands.
 state, and it makes the resetting scheme complicated and it may  For example {\tt ox\_asir}, which is
 introduce unexpected bugs. For example, if a client sends {\tt  the OpenXM server of Risa/Asir, can pop up a window to input
 OX\_SYNC\_BALL} without waiting {\tt OX\_SYNC\_BALL} from the engine,  debug commands and the debugging similar to that on usual terminals is possible.
 then it is possible that the engine receives it before the arrival of  One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
 the signal. We note that we really encountered serious bugs caused  
 by such an inappropriate protocol before reaching the final specification.  
   
 \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 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}  
 and it provides a similar functionality to entering the debugging  and it provides a similar functionality to entering the debugging
 mode from a keyboard interruption.  mode from a keyboard interruption.
Legend:
Removed from v.1.4  
changed lines
  Added in v.1.13
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>