Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / issac2000

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

1.6     ! takayama    1: % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.5 2000/01/11 05:35:48 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:
                      9: In this section we show the realization of control integration in
                     10: OpenXM.  In OpenXM it is assumed that various clients and servers
                     11: establish connections dynamically and communicate to each
                     12: other. Therefore it is necessary to unify the communication interface
                     13: and the method of communication establishment.  Besides, interruption
                     14: of an execution and debugging are common operations when we use
                     15: programming systems. OpenXM provides a method to realize them for
                     16: distributed computation.
                     17:
                     18: \subsection{Interface of servers}
                     19:
1.6     ! takayama   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 coincides with each other,
        !            27: then the network byte order is used.
1.5       noro       28: This implies that all servers and clients should be able to
                     29: handle the network byte
1.3       noro       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:
                     34: \subsection{Invocation of servers}
                     35: \label{launcher}
                     36:
                     37: In general it is complicated to establish a connection over TCP/IP.
                     38: On the other hand a server itself does not have any function to
                     39: make a connection. In order to fill this gap an application called
                     40: {\bf launcher} is provided. A connection is established by using
                     41: the launcher as follows.
                     42:
                     43: \begin{enumerate}
                     44: \item A launcher is invoked from a client or by hand.
                     45: When the launcher is invoked, a port number for TCP/IP connection
                     46: and the name of a server should be informed.
1.4       noro       47: \item The launcher and the client establish a connection with the
1.3       noro       48: specified port number.
                     49: \item The launcher create a process and execute the server after
1.6     ! takayama   50: setting the binary I/O channels appropriately.
1.3       noro       51: \end{enumerate}
                     52:
                     53: Though the above is all the task as a launcher, the launcher process
                     54: acts as a control server and controls the server process created by
                     55: itself. As for a control server see Section \ref{control}.
                     56:
                     57: \subsection{Control server}
                     58: \label{control}
                     59: When we use a mathematical software, an execution time or necessary
                     60: storage is often unknown in advance. Therefore it is desirable
                     61: to be able to abort an execution and to start another execution.
                     62: On OpenXM we adopted the following simple and robust method.
                     63:
                     64: An OpenXM server has logically two I/O channels: one for exchanging
1.4       noro       65: data for computations and the other for controlling computations. The
1.3       noro       66: control channel is used to send commands to control execution on the
1.6     ! takayama   67: server. The launcher introduced in Section \ref{launcher}
        !            68: is used as a control process. We call such a process a {\bf
1.3       noro       69: control server}. In contrast, we call a server for computation an {\bf
                     70: engine}. In this case the control server and the engine runs on the
1.4       noro       71: same machine and it is easy to manipulate the engine, especially to
1.3       noro       72: send a signal from the control server. A control server is also an
1.6     ! takayama   73: OpenXM stackmachine and it accepts {\tt SM\_control\_*} commands
        !            74: to send signals to a server or to terminate a server.
1.3       noro       75:
                     76: \subsection{Resetting a connection}
                     77:
                     78: By using the control channel a client can send a signal to an engine
                     79: at any time. However, I/O operations are usually buffered and several
                     80: additional operations on buffers after sending a signal is necessary
                     81: to reset connections safely. Here a safe resetting means the
                     82: following:
                     83:
                     84: \begin{enumerate}
                     85: \item A sending of an {\tt OX} message must be completed.
                     86:
                     87: As an {\tt OX} message is sent as a combination of several {\tt CMO}
                     88: data, a global exit without sending all the data confuses the
                     89: subsequent communication.
                     90:
                     91: \item After restarting a server, a request from a client
                     92: must correctly corresponds to the response from the server.
                     93:
                     94: An incorrect correspondence occurs if some data remain on the stream
                     95: after restarting a server.
                     96: \end{enumerate}
                     97:
                     98: {\tt SM\_control\_reset\_connection} is an {\tt SM} command to
                     99: initiate a safe resetting of a connection. We show the action of
                    100: a server and a client from the initiation to the completion of
                    101: a resetting.
                    102:
1.6     ! takayama  103: \centerline{\fbox{client}}
1.3       noro      104:
                    105: \begin{enumerate}
                    106: \item The client sends {\tt SM\_control\_reset\_connection} to the
                    107: control server.
                    108: \item The client enters the resetting state. it skips all {\tt
1.4       noro      109: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
1.3       noro      110: \item After receiving {\tt OX\_SYNC\_BALL} the client sends
                    111: {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
                    112: \end{enumerate}
                    113:
1.6     ! takayama  114: \centerline{\fbox{engine}}
1.3       noro      115:
                    116: \begin{enumerate}
                    117: \item After receiving {\tt SIGUSR1} from the control server,
                    118: the engine enters the resetting state.
                    119: \item If an {\tt OX} message is being sent or received, then
                    120: the engine completes it. This does not block because
                    121: the client reads and skips {\tt OX} messages soon after sending
                    122: {\tt SM\_control\_reset\_connection}.
                    123: \item The engine sends {\tt OX\_SYNC\_BALL} to the client.
                    124: \item The engine skips all {\tt OX} messages from the engine until it
1.4       noro      125: receives {\tt OX\_SYNC\_BALL}.
1.3       noro      126: \item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the
                    127: usual state.
                    128: \end{enumerate}
                    129:
                    130: {\tt OX\_SYNC\_BALL} means an end mark of the data remaining in the
                    131: I/O streams. After reading it it is assured that the stream is empty
                    132: and that a request from a client correctly corresponds to the response
1.6     ! takayama  133: from the server. We note that we don't have to associate
        !           134: {\tt OX\_SYNC\_BALL} with
        !           135: any special action to be executed by the server because it is
        !           136: assured that the peer is in the resetting state when one receives
        !           137: {\tt OX\_SYNC\_BALL}.
1.3       noro      138:
1.5       noro      139: \subsection{Debugging supports}
1.6     ! takayama  140: To help debugging on the server, various supports are possible. If
1.3       noro      141: servers are executed on X window system, then the control server can
1.6     ! takayama  142: attach an {\tt xterm} to the standard outputs of the engine to display
        !           143: diagnostic messages from the engine.
        !           144: Furthermore, if the engine provides an interface to input commands,
        !           145: then debugging of user defined programs will be
        !           146: possible. For example {\tt ox\_asir}, which is
        !           147: the OpenXM server of {\tt Risa/Asir}, can pop up a window to input
        !           148: debug commands and the debugging similar to that on usual terminals is possible.
        !           149: One can also send {\tt SIGINT} by using {\tt SM\_control\_intr}
1.4       noro      150: and it provides a similar functionality to entering the debugging
1.3       noro      151: mode from a keyboard interruption.