Annotation of OpenXM/doc/issac2000/session-management.tex, Revision 1.11
1.11 ! noro 1: % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.10 2000/01/17 01:24: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.
1.10 noro 14: In addition to that, interruption of executions and
15: debugging facilities
16: are necessary for interactive distributed computation.
1.8 noro 17:
18: %\subsection{Interface of servers}
19: %
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 coincide with each other,
27: %then the network byte order is used.
28: %This implies that all servers and clients should be able to
29: %handle the network byte
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.
1.3 noro 33:
34: \subsection{Invocation of servers}
35: \label{launcher}
36:
1.8 noro 37: An application called {\it launcher} is provided to start servers
38: and to establish connections as follows.
1.3 noro 39:
40: \begin{enumerate}
1.8 noro 41: \item A launcher is invoked from a client.
42: When the launcher is invoked, the client
43: informs the launcher of a port number for TCP/IP connection
44: and the name of a server.
1.4 noro 45: \item The launcher and the client establish a connection with the
1.10 noro 46: specified port number. One time password may be used to prevent
47: launcher spoofing.
1.8 noro 48: \item The launcher creates a process and executes the server after
49: setting the data channel appropriately.
1.3 noro 50: \end{enumerate}
51:
1.7 noro 52: After finishing the above task as a launcher, the launcher process
1.3 noro 53: acts as a control server and controls the server process created by
1.10 noro 54: itself. As to the control server see Section \ref{control}.
1.3 noro 55:
1.8 noro 56: As the data channel is used to exchange binary data,
57: the byte order conversion is necessary when a
58: client and a server have different byte orders. It is determined by
59: exchanging the preferable byte order of each peer. If the preference
60: does not coincide with each other,
61: then the network byte order is used.
62: This implies that all servers and clients should be able to
63: handle the network byte
64: order. Nevertheless it is necessary to negotiate the byte order to
65: skip the byte order conversion because its cost is often dominant over
66: fast networks.
67:
68:
1.3 noro 69: \subsection{Control server}
70: \label{control}
1.8 noro 71: In OpenXM we adopted the following simple and robust method to
72: control servers.
1.3 noro 73:
74: An OpenXM server has logically two I/O channels: one for exchanging
1.4 noro 75: data for computations and the other for controlling computations. The
1.3 noro 76: control channel is used to send commands to control execution on the
1.6 takayama 77: server. The launcher introduced in Section \ref{launcher}
1.8 noro 78: is used as a control process. We call such a process a {\it
79: control server}. In contrast, we call a server for computation an {\it
80: engine}. As the control server and the engine runs on the
81: same machine, it is easy to manipulate the engine, especially to
1.3 noro 82: send a signal from the control server. A control server is also an
1.8 noro 83: OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
1.6 takayama 84: to send signals to a server or to terminate a server.
1.3 noro 85:
1.11 ! noro 86: \subsection{Resetting an engine}
1.3 noro 87:
1.8 noro 88: A client can send a signal to an engine by using the control channel
89: at any time. However, I/O operations are usually buffered,
1.10 noro 90: which may cause troubles.
1.11 ! noro 91: To reset an engine safely the following are required.
1.3 noro 92:
93: \begin{enumerate}
1.10 noro 94: \item Any OX message must be a synchronized object in the sense of Java.
1.3 noro 95:
96: As an {\tt OX} message is sent as a combination of several {\tt CMO}
1.10 noro 97: data, a global exit without sending all may generate broken data.
1.3 noro 98:
1.11 ! noro 99: \item After restarting an engine, a request from a client
! 100: must correctly corresponds to the response from the engine.
1.3 noro 101:
102: An incorrect correspondence occurs if some data remain on the stream
1.11 ! noro 103: after restarting an engine.
1.3 noro 104: \end{enumerate}
105:
106: {\tt SM\_control\_reset\_connection} is an {\tt SM} command to
1.11 ! noro 107: initiate a safe resetting of an engine.
! 108: The control server sends {\tt SIGUSR1} to the engine if it receives
! 109: {\tt SM\_control\_reset\_connection} from the client.
! 110: Under the OpenXM reset protocol an engine and a client act as follows.
! 111:
! 112: \vskip 2mm
! 113: \noindent
! 114: {\it Client side}
1.3 noro 115: \begin{enumerate}
1.11 ! noro 116: \item After sending {\tt SM\_control\_reset\_connection} to the
! 117: control server, the client enters the resetting state. It skips all {\tt
1.4 noro 118: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
1.3 noro 119: \item After receiving {\tt OX\_SYNC\_BALL} the client sends
120: {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state.
121: \end{enumerate}
122:
1.11 ! noro 123: \noindent
! 124: {\it Engine side}
1.3 noro 125: \begin{enumerate}
1.11 ! noro 126: \item
! 127: After receiving {\tt SIGUSR1} from the control server,
1.3 noro 128: the engine enters the resetting state.
1.11 ! noro 129: The engine sends {\tt OX\_SYNC\_BALL} to the client.
! 130: The operation does not block because
! 131: the client is now in the resetting state.
1.3 noro 132: \item The engine skips all {\tt OX} messages from the engine until it
1.11 ! noro 133: receives {\tt OX\_SYNC\_BALL}. After receiving {\tt OX\_SYNC\_BALL}
! 134: the engine returns to the usual state.
1.3 noro 135: \end{enumerate}
136:
1.11 ! noro 137: \begin{figure}[htbp]
! 138: \epsfxsize=8.5cm
! 139: \epsffile{reset.eps}
! 140: \caption{OpenXM reset procedure}
! 141: \label{reset}
! 142: \end{figure}
! 143:
! 144: Figure \ref{reset} illustrates the flow of data.
1.8 noro 145: {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
146: I/O streams. After reading it, it is assured that each stream is empty
1.7 noro 147: and that the subsequent request from a client correctly
1.11 ! noro 148: corresponds to the response from the engine.
1.7 noro 149: We note that we don't have to associate {\tt OX\_SYNC\_BALL} with
1.11 ! noro 150: any special action to be executed by the engine because it is
! 151: assured that the engine is in the resetting state when it has received
1.6 takayama 152: {\tt OX\_SYNC\_BALL}.
1.3 noro 153:
1.10 noro 154: \subsection{Debugging facilities}
1.11 ! noro 155: Debugging is sometimes very hard for distributed computations.
! 156: We provide two methods to help debugging on X window system:
! 157: 1. the diagnostic messages from the engine are displayed in a {\tt xterm}
! 158: window;
! 159: 2. the engine can pop up a window to input debug commands.
1.10 noro 160: For example {\tt ox\_asir}, which is
1.6 takayama 161: the OpenXM server of {\tt Risa/Asir}, can pop up a window to input
162: debug commands and the debugging similar to that on usual terminals is possible.
1.7 noro 163: One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
1.4 noro 164: and it provides a similar functionality to entering the debugging
1.3 noro 165: mode from a keyboard interruption.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>