[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.2 and 1.13

version 1.2, 2000/01/02 07:32:12 version 1.13, 2000/01/17 08:50:57
Line 1 
Line 1 
 % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.1 1999/12/23 10:25:09 takayama Exp $  % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.12 2000/01/17 07:15:52 noro Exp $
   
 \section{Session Management}  (Noryo)  
   
 MEMO: key words:  
 Security (ssh PAM), initial negotiation of byte order,  
 mathcap, interruption, debugging window, etc.  
   
   
   \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 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 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}
   %
   %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.
   
   \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
   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}
   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 {\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 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.
   
   \begin{enumerate}
   \item Any OX message must be a synchronized object in the sense of Java.
   
   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 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 an engine.
   \end{enumerate}
   
   {\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
   {\it Client side}
   \begin{enumerate}
   \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
   {\it Engine side}
   \begin{enumerate}
   \item
   After receiving {\tt SIGUSR1} from the control server,
   the engine enters the resetting 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}
   
   \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 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}.
   
   \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.
Legend:
Removed from v.1.2  
changed lines
  Added in v.1.13
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>