Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / issac2000

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

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