Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / issac2000

Annotation of OpenXM/doc/issac2000/session-management.tex, Revision 1.8

1.8     ! noro        1: % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.7 2000/01/15 03:46:27 noro Exp $
1.2       takayama    2:
1.3       noro        3: \section{Session Management}
1.4       noro        4: \label{secsession}
1.3       noro        5: %MEMO: key words:
                      6: %Security (ssh PAM), initial negotiation of byte order,
                      7: %mathcap, interruption, debugging window, etc.
                      8:
1.8     ! noro        9: In this section we explain our control integration in
        !            10: OpenXM.  We assume that various clients and servers
1.3       noro       11: establish connections dynamically and communicate to each
1.8     ! noro       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 an exections and debugging
        !            15: supports are necessary for intaractive distributed computation.
        !            16:
        !            17: %\subsection{Interface of servers}
        !            18: %
        !            19: %A server has additional I/O streams for exchanging data between
        !            20: %a client and itself other than ones for diagnostic
        !            21: %messages. As the streams are for binary data,
        !            22: %the byte order conversion is necessary when a
        !            23: %client and a server have different byte orders. It is determined by
        !            24: %exchanging the preferable byte order of each peer. If the preference
        !            25: %does not coincide with each other,
        !            26: %then the network byte order is used.
        !            27: %This implies that all servers and clients should be able to
        !            28: %handle the network byte
        !            29: %order. Nevertheless it is necessary to negotiate the byte order to
        !            30: %skip the byte order conversion because its cost is often dominant over
        !            31: %fast networks.
1.3       noro       32:
                     33: \subsection{Invocation of servers}
                     34: \label{launcher}
                     35:
1.8     ! noro       36: An application called {\it launcher} is provided to start servers
        !            37: and to establish connections as follows.
1.3       noro       38:
                     39: \begin{enumerate}
1.8     ! noro       40: \item A launcher is invoked from a client.
        !            41: When the launcher is invoked, the client
        !            42: informs the launcher of a port number for TCP/IP connection
        !            43: and the name of a server.
1.4       noro       44: \item The launcher and the client establish a connection with the
1.3       noro       45: specified port number.
1.8     ! noro       46: \item The launcher creates a process and executes the server after
        !            47: setting the data channel appropriately.
1.3       noro       48: \end{enumerate}
                     49:
1.7       noro       50: After finishing the above task as a launcher, the launcher process
1.3       noro       51: acts as a control server and controls the server process created by
                     52: itself. As for a control server see Section \ref{control}.
                     53:
1.8     ! noro       54: As the data channel is used to exchange binary data,
        !            55: the byte order conversion is necessary when a
        !            56: client and a server have different byte orders. It is determined by
        !            57: exchanging the preferable byte order of each peer. If the preference
        !            58: does not coincide with each other,
        !            59: then the network byte order is used.
        !            60: This implies that all servers and clients should be able to
        !            61: handle the network byte
        !            62: order. Nevertheless it is necessary to negotiate the byte order to
        !            63: skip the byte order conversion because its cost is often dominant over
        !            64: fast networks.
        !            65:
        !            66:
1.3       noro       67: \subsection{Control server}
                     68: \label{control}
1.8     ! noro       69: In OpenXM we adopted the following simple and robust method to
        !            70: control servers.
1.3       noro       71:
                     72: An OpenXM server has logically two I/O channels: one for exchanging
1.4       noro       73: data for computations and the other for controlling computations. The
1.3       noro       74: control channel is used to send commands to control execution on the
1.6       takayama   75: server. The launcher introduced in Section \ref{launcher}
1.8     ! noro       76: is used as a control process. We call such a process a {\it
        !            77: control server}. In contrast, we call a server for computation an {\it
        !            78: engine}. As the control server and the engine runs on the
        !            79: same machine, it is easy to manipulate the engine, especially to
1.3       noro       80: send a signal from the control server. A control server is also an
1.8     ! noro       81: OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
1.6       takayama   82: to send signals to a server or to terminate a server.
1.3       noro       83:
1.8     ! noro       84: \subsection{Resetting a server}
1.3       noro       85:
1.8     ! noro       86: A client can send a signal to an engine by using the control channel
        !            87: at any time. However, I/O operations are usually buffered,
        !            88: which may cause troubles without care for remaining data in
        !            89: the buffers.  To reset a server safely the following are required.
1.3       noro       90:
                     91: \begin{enumerate}
                     92: \item A sending of an {\tt OX} message must be completed.
                     93:
                     94: As an {\tt OX} message is sent as a combination of several {\tt CMO}
                     95: data, a global exit without sending all the data confuses the
                     96: subsequent communication.
                     97:
                     98: \item After restarting a server, a request from a client
                     99: must correctly corresponds to the response from the server.
                    100:
                    101: An incorrect correspondence occurs if some data remain on the stream
                    102: after restarting a server.
                    103: \end{enumerate}
                    104:
                    105: {\tt SM\_control\_reset\_connection} is an {\tt SM} command to
1.8     ! noro      106: initiate a safe resetting of a server. We show the action of
1.3       noro      107: a server and a client from the initiation to the completion of
                    108: a resetting.
                    109:
1.6       takayama  110: \centerline{\fbox{client}}
1.3       noro      111:
                    112: \begin{enumerate}
                    113: \item The client sends {\tt SM\_control\_reset\_connection} to the
1.7       noro      114: control server. The control server sends {\tt SIGUSR1} to the engine.
1.8     ! noro      115: \item The client enters the resetting state. It skips all {\tt
1.4       noro      116: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
1.3       noro      117: \item After receiving {\tt OX\_SYNC\_BALL} the client sends
                    118: {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
                    119: \end{enumerate}
                    120:
1.6       takayama  121: \centerline{\fbox{engine}}
1.3       noro      122:
                    123: \begin{enumerate}
                    124: \item After receiving {\tt SIGUSR1} from the control server,
                    125: the engine enters the resetting state.
1.8     ! noro      126: \item The engine sends {\tt OX\_SYNC\_BALL} to the client.
        !           127: We note that the operation does not block because
1.3       noro      128: the client reads and skips {\tt OX} messages soon after sending
                    129: {\tt SM\_control\_reset\_connection}.
                    130: \item The engine skips all {\tt OX} messages from the engine until it
1.4       noro      131: receives {\tt OX\_SYNC\_BALL}.
1.3       noro      132: \item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the
                    133: usual state.
                    134: \end{enumerate}
                    135:
1.8     ! noro      136: {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
        !           137: I/O streams. After reading it, it is assured that each stream is empty
1.7       noro      138: and that the subsequent request from a client correctly
                    139: corresponds to the response from the server.
                    140: We note that we don't have to associate {\tt OX\_SYNC\_BALL} with
1.6       takayama  141: any special action to be executed by the server because it is
1.8     ! noro      142: assured that the peer is in the resetting state when one has received
1.6       takayama  143: {\tt OX\_SYNC\_BALL}.
1.3       noro      144:
1.5       noro      145: \subsection{Debugging supports}
1.8     ! noro      146: Debugging is not easy for distributed computations.
        !           147: If servers are executed on X window system, then the control server can
1.6       takayama  148: attach an {\tt xterm} to the standard outputs of the engine to display
                    149: diagnostic messages from the engine.
                    150: Furthermore, if the engine provides an interface to input commands,
                    151: then debugging of user defined programs will be
1.8     ! noro      152: possible on the engine. For example {\tt ox\_asir}, which is
1.6       takayama  153: the OpenXM server of {\tt Risa/Asir}, can pop up a window to input
                    154: debug commands and the debugging similar to that on usual terminals is possible.
1.7       noro      155: One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
1.4       noro      156: and it provides a similar functionality to entering the debugging
1.3       noro      157: mode from a keyboard interruption.