Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / ascm2001

Annotation of OpenXM/doc/ascm2001/session-management.tex, Revision 1.2

1.2     ! takayama    1: % $OpenXM: OpenXM/doc/ascm2001/session-management.tex,v 1.1 2001/03/07 02:42:11 noro Exp $
1.1       noro        2:
                      3: \section{Session Management}
                      4: \label{secsession}
                      5: %MEMO: key words:
                      6: %Security (ssh PAM), initial negotiation of byte order,
                      7: %mathcap, interruption, debugging window, etc.
                      8:
                      9: In this section we explain our control integration in
                     10: OpenXM.  We assume that various clients and servers
                     11: establish connections dynamically and communicate to each
                     12: other. Therefore it is necessary to give a dynamical and unified
                     13: method to start servers and to establish connections.
                     14: In addition to that, interruption of execution and
                     15: debugging facilities
                     16: are necessary for interactive distributed computation.
                     17:
                     18: %\subsection{Interface of servers}
                     19: %
                     20: %A server has additional I/O streams for exchanging data between
                     21: %a client and itself other than ones for diagnostic
                     22: %messages. As the streams are for binary data,
                     23: %the byte order conversion is necessary when a
                     24: %client and a server have different byte orders. It is determined by
                     25: %exchanging the preferable byte order of each peer. If the preference
                     26: %does not coincide with each other,
                     27: %then the network byte order is used.
                     28: %This implies that all servers and clients should be able to
                     29: %handle the network byte
                     30: %order. Nevertheless it is necessary to negotiate the byte order to
                     31: %skip the byte order conversion because its cost is often dominant over
                     32: %fast networks.
                     33:
1.2     ! takayama   34: \subsection{Invocation of servers by OpenXM-RFC 100}
1.1       noro       35: \label{launcher}
                     36:
                     37: An application called {\it launcher} is provided to start servers
                     38: and to establish connections as follows.
                     39:
                     40: \begin{enumerate}
                     41: \item A launcher is invoked from a client.
                     42: When the launcher is invoked, the client
                     43: informs the launcher of a port number for TCP/IP connection
                     44: and the name of a server.
                     45: \item The launcher and the client establish a connection with the
                     46: specified port number. One time password may be used to prevent
                     47: launcher spoofing.
                     48: \item The launcher creates a process and executes the server after
                     49: setting the data channel appropriately.
                     50: \end{enumerate}
                     51:
                     52: After finishing the above task as a launcher, the launcher process
                     53: acts as a control server and controls the server process created by
                     54: itself. As to the details of the control server see Section \ref{control}.
                     55:
                     56: As the data channel is used to exchange binary data,
                     57: the byte order conversion is necessary when a
                     58: client and a server have different byte orders. It is determined by
                     59: exchanging the preferable byte order of each peer. If the preference
                     60: does not coincide with each other,
                     61: then the network byte order is used.
                     62: This implies that all servers and clients should be able to
                     63: handle the network byte
                     64: order. Nevertheless it is necessary to negotiate the byte order to
                     65: skip the byte order conversion because its cost is often dominant over
                     66: fast networks.
                     67:
1.2     ! takayama   68: \subsection{Invocation of servers by OpenXM-RFC 101}
        !            69: OpenXM-RFC 101 \cite{ox-rfc-101} gives more secure and
        !            70: efficient way to start servers.
        !            71: It uses ``ssh'' to launch a control server and
        !            72: the control server can launch one or more than one
        !            73: engines.
        !            74: See \cite{oc-rfc-101} for details.
1.1       noro       75:
                     76: \subsection{Control server}
                     77: \label{control}
                     78: In OpenXM we adopted the following simple and robust method to
                     79: control servers.
                     80:
                     81: An OpenXM server has logically two I/O channels: one for exchanging
                     82: data for computations and the other for controlling computations. The
                     83: control channel is used to send commands to control execution on the
                     84: server. The launcher introduced in Section \ref{launcher}
                     85: is used as a control process. We call such a process a {\it
                     86: control server}. In contrast, we call a server for computation an {\it
                     87: engine}. As the control server and the engine runs on the
                     88: same machine, it is easy to send a signal from the control server.
                     89: A control server is also an
                     90: OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
                     91: to send signals to a server or to terminate a server.
                     92:
                     93: \subsection{Resetting an engine}
                     94:
                     95: A client can send a signal to an engine by using the control channel
                     96: at any time. However, I/O operations are usually buffered,
                     97: which may cause troubles.
                     98: To reset an engine safely the following are required.
                     99:
                    100: \begin{enumerate}
                    101: \item Any OX message must be a synchronized object in the sense of Java.
                    102:
                    103: As an OX message is sent as a combination of several {\tt CMO}
                    104: data, a global exit without sending all may generate broken data.
                    105:
                    106: \item After restarting an engine, a request from a client
                    107: must correctly corresponds to the response from the engine.
                    108:
                    109: An incorrect correspondence occurs if some data remain on the stream
                    110: after restarting an engine.
                    111: \end{enumerate}
                    112:
                    113: {\tt SM\_control\_reset\_connection} is a stack machine command to
                    114: initiate a safe resetting of an engine.
                    115: The control server sends {\tt SIGUSR1} to the engine if it receives
                    116: {\tt SM\_control\_reset\_connection} from the client.
                    117: Under the OpenXM reset protocol, an engine and a client act as follows.
                    118:
                    119: \vskip 2mm
                    120: \noindent
                    121: {\it Client side}
                    122: \begin{enumerate}
                    123: \item After sending {\tt SM\_control\_reset\_connection} to the
                    124: control server, the client enters the resetting state. It discards all {\tt
                    125: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
                    126: \item After receiving {\tt OX\_SYNC\_BALL} the client sends
                    127: {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
                    128: \end{enumerate}
                    129:
                    130: \noindent
                    131: {\it Engine side}
                    132: \begin{enumerate}
                    133: \item
                    134: After receiving {\tt SIGUSR1} from the control server,
                    135: the engine enters the resetting state.
                    136: The engine sends {\tt OX\_SYNC\_BALL} to the client.
                    137: The operation does not block because
                    138: the client is now in the resetting state.
                    139: \item The engine discards all OX messages from the engine until it
                    140: receives {\tt OX\_SYNC\_BALL}. After receiving {\tt OX\_SYNC\_BALL}
                    141: the engine returns to the usual state.
                    142: \end{enumerate}
                    143:
                    144: \begin{figure}[htbp]
                    145: \epsfxsize=8.5cm
                    146: \epsffile{reset.eps}
                    147: \caption{OpenXM reset procedure}
                    148: \label{reset}
                    149: \end{figure}
                    150:
                    151: Figure \ref{reset} illustrates the flow of data.
                    152: {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
                    153: I/O streams. After reading it, it is assured that each stream is empty
                    154: and that the subsequent request from a client correctly
                    155: corresponds to the response from the engine.
                    156: We note that we don't have to associate {\tt OX\_SYNC\_BALL} with
                    157: any special action to be executed by the engine because it is
                    158: assured that the engine is in the resetting state when it has received
                    159: {\tt OX\_SYNC\_BALL}.
                    160:
                    161: \subsection{Debugging facilities}
                    162: Debugging is sometimes very hard for distributed computations.
                    163: We provide two methods to help debugging on X window system:
                    164: 1. the diagnostic messages from the engine are displayed in a {\tt xterm}
                    165: window;
                    166: 2. the engine can pop up a window to input debug commands.
                    167: For example {\tt ox\_asir}, which is
                    168: the OpenXM server of Risa/Asir, can pop up a window to input
                    169: debug commands and the debugging similar to that on usual terminals is possible.
                    170: One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
                    171: and it provides a similar functionality to entering the debugging
                    172: mode from a keyboard interruption.