Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / issac2000

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

1.4     ! noro        1: % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.3 2000/01/04 09:14:14 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:
                     20: A server has the following I/O streams at its startup. The numbers
                     21: indicate stream descriptors.
                     22:
                     23: \begin{description}
                     24: \item{\bf 1} standard output
                     25: \item{\bf 2} standard error
                     26: \item{\bf 3} input from a client
                     27: \item{\bf 4} output to a client
                     28: \end{description}
                     29:
                     30: A server reads data from the stream {\bf 3} and writes results to the
                     31: stream {\bf 4}. The streams {\bf 1} and {\bf 2} are provided for
                     32: diagnostic messages from the server.  As {\bf 3} and {\bf 4} are
                     33: streams for binary data, the byte order conversion is necessary when a
                     34: client and a server have different byte orders. There are several
                     35: methods to treat it and we adopted the following scheme.
                     36:
                     37: \begin{itemize}
                     38: \item A server writes 1 byte representing the preferable byte order.
                     39: \item After reading the byte, a client writes 1 byte representing the
                     40: preferable byte order.
1.4     ! noro       41: \item On each side, if the preference coincides with each other then
1.3       noro       42: the byte order is used. Otherwise the network byte order is used.
                     43: \end{itemize}
                     44:
                     45: This implies that all servers and clients can handle the network byte
                     46: order. Nevertheless it is necessary to negotiate the byte order to
                     47: skip the byte order conversion because its cost is often dominant over
                     48: fast networks.
                     49:
                     50: \subsection{Invocation of servers}
                     51: \label{launcher}
                     52:
                     53: In general it is complicated to establish a connection over TCP/IP.
                     54: On the other hand a server itself does not have any function to
                     55: make a connection. In order to fill this gap an application called
                     56: {\bf launcher} is provided. A connection is established by using
                     57: the launcher as follows.
                     58:
                     59: \begin{enumerate}
                     60: \item A launcher is invoked from a client or by hand.
                     61: When the launcher is invoked, a port number for TCP/IP connection
                     62: and the name of a server should be informed.
1.4     ! noro       63: \item The launcher and the client establish a connection with the
1.3       noro       64: specified port number.
                     65: \item The launcher create a process and execute the server after
                     66: setting the streams {\bf 3} and {\bf 4} appropriately.
                     67: An application to display messages written to the streams {\bf 1} and
                     68: {\bf 2} may be invoked if necessary.
                     69: \end{enumerate}
                     70:
                     71: Though the above is all the task as a launcher, the launcher process
                     72: acts as a control server and controls the server process created by
                     73: itself. As for a control server see Section \ref{control}.
                     74:
                     75: \subsection{Control server}
                     76: \label{control}
                     77: When we use a mathematical software, an execution time or necessary
                     78: storage is often unknown in advance. Therefore it is desirable
                     79: to be able to abort an execution and to start another execution.
                     80: On a usual session on UNIX it is done by an interruption from a keyboard.
1.4     ! noro       81: Internally it is realized by an exception processing initiated by
1.3       noro       82: a {\bf signal}, but it is not easy to send a signal to a server.
                     83: Especially if a server and a client run on different machines,
                     84: the client cannot send a signal to the server directly.
                     85: Though Some operating systems provide facilities to attach
                     86: signals such as {\tt SIGIO} and {\tt SIGURG} to a stream data, they are
                     87: system dependent and lack robustness.
                     88: On OpenXM we adopted the following simple and robust method.
                     89:
                     90: An OpenXM server has logically two I/O channels: one for exchanging
1.4     ! noro       91: data for computations and the other for controlling computations. The
1.3       noro       92: control channel is used to send commands to control execution on the
                     93: server. There are several ways of implementing the control channel.
                     94: Among them it is common to use the launcher introduced in Section
                     95: \ref{launcher} as a control process. We call such a process a {\bf
                     96: control server}. In contrast, we call a server for computation an {\bf
                     97: engine}. In this case the control server and the engine runs on the
1.4     ! noro       98: same machine and it is easy to manipulate the engine, especially to
1.3       noro       99: send a signal from the control server. A control server is also an
                    100: OpenXM stackmachine and the following {\tt SM} commands are provided.
                    101:
                    102: \begin{description}
                    103: \item {\tt SM\_control\_reset\_connection}
                    104: It requests a control server to send the {\tt SIGUSR1} signal.
                    105:
                    106: \item {\tt SM\_control\_kill}
                    107: It requests a control server to terminate an engine.
                    108:
                    109: \item {\tt SM\_control\_intr}
                    110: It requests a control server to send the {\tt SIGINT} signal.
                    111: \end{description}
                    112:
                    113: \subsection{Resetting a connection}
                    114:
                    115: By using the control channel a client can send a signal to an engine
                    116: at any time. However, I/O operations are usually buffered and several
                    117: additional operations on buffers after sending a signal is necessary
                    118: to reset connections safely. Here a safe resetting means the
                    119: following:
                    120:
                    121: \begin{enumerate}
                    122: \item A sending of an {\tt OX} message must be completed.
                    123:
                    124: As an {\tt OX} message is sent as a combination of several {\tt CMO}
                    125: data, a global exit without sending all the data confuses the
                    126: subsequent communication.
                    127:
                    128: \item After restarting a server, a request from a client
                    129: must correctly corresponds to the response from the server.
                    130:
                    131: An incorrect correspondence occurs if some data remain on the stream
                    132: after restarting a server.
                    133: \end{enumerate}
                    134:
                    135: {\tt SM\_control\_reset\_connection} is an {\tt SM} command to
                    136: initiate a safe resetting of a connection. We show the action of
                    137: a server and a client from the initiation to the completion of
                    138: a resetting.
                    139:
                    140: \noindent
                    141: \fbox{client}
                    142:
                    143: \begin{enumerate}
                    144: \item The client sends {\tt SM\_control\_reset\_connection} to the
                    145: control server.
                    146: \item The client enters the resetting state. it skips all {\tt
1.4     ! noro      147: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
1.3       noro      148: \item After receiving {\tt OX\_SYNC\_BALL} the client sends
                    149: {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
                    150: \end{enumerate}
                    151:
                    152: \noindent
                    153: \fbox{engine}
                    154:
                    155: \begin{enumerate}
                    156: \item After receiving {\tt SIGUSR1} from the control server,
                    157: the engine enters the resetting state.
                    158: \item If an {\tt OX} message is being sent or received, then
                    159: the engine completes it. This does not block because
                    160: the client reads and skips {\tt OX} messages soon after sending
                    161: {\tt SM\_control\_reset\_connection}.
                    162: \item The engine sends {\tt OX\_SYNC\_BALL} to the client.
                    163: \item The engine skips all {\tt OX} messages from the engine until it
1.4     ! noro      164: receives {\tt OX\_SYNC\_BALL}.
1.3       noro      165: \item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the
                    166: usual state.
                    167: \end{enumerate}
                    168:
                    169: {\tt OX\_SYNC\_BALL} means an end mark of the data remaining in the
                    170: I/O streams. After reading it it is assured that the stream is empty
                    171: and that a request from a client correctly corresponds to the response
                    172: from the server.  For a safe resetting, it is important that the
                    173: following actions are executed always in that order.
                    174:
                    175: \begin{enumerate}
                    176: \item A signal is sent to an engine by a request from a client.
                    177: \item The engine sends {\tt OX\_SYNC\_BALL} to the client.
                    178: \item The client sends {\tt OX\_SYNC\_BALL} to the engine after
                    179: receiving {\tt OX\_SYNC\_BALL}.
                    180: \end{enumerate}
                    181:
                    182: This assures that the peer is in the resetting state when one receives
                    183: {\tt OX\_SYNC\_BALL}. By this fact we don't have to associate it with
                    184: any special action to be executed by the server. Especially it can be
                    185: ignored if processes are in the usual state. If the above order is not
                    186: preserved, then both {\tt SM\_control\_reset\_connection} and {\tt
                    187: OX\_SYNC\_BALL} must initiate an engine into entering the resetting
                    188: state, and it makes the resetting scheme complicated and it may
                    189: introduce unexpected bugs. For example, if a client sends {\tt
                    190: OX\_SYNC\_BALL} without waiting {\tt OX\_SYNC\_BALL} from the engine,
1.4     ! noro      191: then it is possible that the engine receives it before the arrival of
1.3       noro      192: the signal. We note that we really encountered serious bugs caused
1.4     ! noro      193: by such an inappropriate protocol before reaching the final specification.
1.3       noro      194:
                    195: \subsection{Debugging}
                    196: An OpenXM server may allow definition and execution of functions
                    197: written in the user language proper to the server.  To help debugging
                    198: such functions on the server, various supports are possible. If
                    199: servers are executed on X window system, then the control server can
                    200: attach an {\tt xterm} to the standard outputs of the engine, which
                    201: makes it possible to display messages from the engine. Furthermore, if
1.4     ! noro      202: the engine provides an interface to input commands which directly
1.3       noro      203: controls the engine, then debugging of user define programs will be
                    204: possible. For example {\tt Risa/Asir} provides a function {\tt
                    205: debug()} to debug user defined functions. {\tt ox\_asir}, which is
                    206: the OpenXM server of {\tt Risa/Asir}, pops up a window to input
                    207: debug commands when {\tt debug()} is executed on the server.
                    208: As the responses to the commands are displayed on the {\tt xterm},
                    209: the debugging similar to that on usual terminals is possible.
                    210: Moreover one can send {\tt SIGINT} by using {\tt SM\_control\_intr}
1.4     ! noro      211: and it provides a similar functionality to entering the debugging
1.3       noro      212: mode from a keyboard interruption.