Return to session-management.tex CVS log

Up to [local] / OpenXM / doc / ascm2001p

Annotation of OpenXM/doc/ascm2001p/session-management.tex, Revision 1.1

1.1     ! noro        1: % $OpenXM$
        !             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 show our control integration in
        !            10: OpenXM, which gives a dynamical and unified
        !            11: method to start servers, to establish connections and to reset
        !            12: computations.
        !            13: %method to start servers and to establish connections.
        !            14: %We assume that various clients and servers
        !            15: %establish connections dynamically and communicate to each
        !            16: %other. Therefore it is necessary to give a dynamical and unified
        !            17: %method to start servers and to establish connections.
        !            18: %In addition to that, interruption of execution and
        !            19: %debugging facilities
        !            20: %are necessary for interactive distributed computation.
        !            21:
        !            22: %\subsection{Interface of servers}
        !            23: %
        !            24: %A server has additional I/O streams for exchanging data between
        !            25: %a client and itself other than ones for diagnostic
        !            26: %messages. As the streams are for binary data,
        !            27: %the byte order conversion is necessary when a
        !            28: %client and a server have different byte orders. It is determined by
        !            29: %exchanging the preferable byte order of each peer. If the preference
        !            30: %does not coincide with each other,
        !            31: %then the network byte order is used.
        !            32: %This implies that all servers and clients should be able to
        !            33: %handle the network byte
        !            34: %order. Nevertheless it is necessary to negotiate the byte order to
        !            35: %skip the byte order conversion because its cost is often dominant over
        !            36: %fast networks.
        !            37:
        !            38: \subsection{Invocation of servers}
        !            39: \label{launcher}
        !            40:
        !            41: Under OpenXM-RFC 100, servers are invoked as follows.
        !            42: An application called {\it launcher} is invoked from a client.
        !            43: The launcher sets up two communication channels: the data channel
        !            44: and the control. Then it creates a server process which can communicate
        !            45: with the client via the data channel. Finally the launcher
        !            46: acts as a control server and controls the server process.
        !            47: As to the details of the control server see Section \ref{control}.
        !            48: %As the data channel is used to exchange binary data,
        !            49: %the byte order conversion is necessary when a
        !            50: %client and a server have different byte orders. It is determined by
        !            51: %exchanging the preferable byte order of each peer. If the preference
        !            52: %does not coincide with each other,
        !            53: %then the network byte order is used.
        !            54: %This implies that all servers and clients should be able to
        !            55: %handle the network byte
        !            56: %order. Nevertheless it is necessary to negotiate the byte order to
        !            57: %skip the byte order conversion because its cost is often dominant over
        !            58: %fast networks.
        !            59: OpenXM-RFC 101 \cite{ox-rfc-101} gives more secure and
        !            60: efficient way to start servers.
        !            61: It uses ``ssh'' to launch a control server and
        !            62: the control server can launch one or more than one
        !            63: engines.
        !            64: See \cite{ox-rfc-101} for details.
        !            65:
        !            66: \subsection{Control server}
        !            67: \label{control}
        !            68: %In OpenXM we adopted the following simple and robust method to
        !            69: %control servers.
        !            70: %
        !            71: %An OpenXM server has logically two I/O channels: one for exchanging
        !            72: %data for computations and the other for controlling computations. The
        !            73: %control channel is used to send commands to control execution on the
        !            74: %server. The launcher introduced in Section \ref{launcher}
        !            75: %is used as a control process. We call such a process a {\it
        !            76: %control server}. In contrast, we call a server for computation an {\it
        !            77: %engine}. As the control server and the engine runs on the
        !            78: %same machine, it is easy to send a signal from the control server.
        !            79: %A control server is also an
        !            80: %OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
        !            81: %to send signals to a server or to terminate a server.
        !            82: %
        !            83: %\subsection{Resetting an engine}
        !            84:
        !            85: {\tt SM\_control\_reset\_connection} sent to the control server
        !            86: initiates a safe resetting of an engine.
        !            87: After receiving the command, the control server sends {\tt SIGUSR1}
        !            88: to the engine and the resetting procedure starts.
        !            89: Figure \ref{reset} illustrates the flow of data under the OpenXM
        !            90: reset protocol.
        !            91: \begin{figure}[htbp]
        !            92: \begin{center}
        !            93: \epsfxsize=8cm
        !            94: \epsffile{reset.eps}
        !            95: \caption{OpenXM reset procedure}
        !            96: \label{reset}
        !            97: \end{center}
        !            98: \end{figure}
        !            99: {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
        !           100: I/O streams. After reading it, it is assured that each stream is empty
        !           101: and that the subsequent request from a client correctly
        !           102: corresponds to the response from the engine.
        !           103: %We note that we don't have to associate {\tt OX\_SYNC\_BALL} with
        !           104: %any special action to be executed by the engine because it is
        !           105: %assured that the engine is in the resetting state when it has received
        !           106: %{\tt OX\_SYNC\_BALL}.
        !           107:
        !           108: %\subsection{Debugging facilities}
        !           109: %Debugging is sometimes very hard for distributed computations.
        !           110: %We provide two methods to help debugging on X window system:
        !           111: %1. the diagnostic messages from the engine are displayed in a {\tt xterm}
        !           112: %window;
        !           113: %2. the engine can pop up a window to input debug commands.
        !           114: %For example {\tt ox\_asir}, which is
        !           115: %the OpenXM server of Risa/Asir, can pop up a window to input
        !           116: %debug commands and the debugging similar to that on usual terminals is possible.
        !           117: %One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
        !           118: %and it provides a similar functionality to entering the debugging
        !           119: %mode from a keyboard interruption.