Annotation of OpenXM/doc/calc2000/session-management.tex, Revision 1.1
1.1 ! noro 1: % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.13 2000/01/17 08:50:57 noro Exp $
! 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 explain our control integration in
! 10: OpenXM. We assume that various clients and servers
! 11: establish connections dynamically and communicate to each
! 12: other. Therefore it is necessary to give a dynamical and unified
! 13: method to start servers and to establish connections.
! 14: In addition to that, interruption of execution and
! 15: debugging facilities
! 16: are necessary for interactive distributed computation.
! 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.
! 33:
! 34: \subsection{Invocation of servers}
! 35: \label{launcher}
! 36:
! 37: An application called {\it launcher} is provided to start servers
! 38: and to establish connections as follows.
! 39:
! 40: \begin{enumerate}
! 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.
! 45: \item The launcher and the client establish a connection with the
! 46: specified port number. One time password may be used to prevent
! 47: launcher spoofing.
! 48: \item The launcher creates a process and executes the server after
! 49: setting the data channel appropriately.
! 50: \end{enumerate}
! 51:
! 52: After finishing the above task as a launcher, the launcher process
! 53: acts as a control server and controls the server process created by
! 54: itself. As to the details of the control server see Section \ref{control}.
! 55:
! 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:
! 69: \subsection{Control server}
! 70: \label{control}
! 71: In OpenXM we adopted the following simple and robust method to
! 72: control servers.
! 73:
! 74: An OpenXM server has logically two I/O channels: one for exchanging
! 75: data for computations and the other for controlling computations. The
! 76: control channel is used to send commands to control execution on the
! 77: server. The launcher introduced in Section \ref{launcher}
! 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 send a signal from the control server.
! 82: A control server is also an
! 83: OpenXM stack machine and it accepts {\tt SM\_control\_*} commands
! 84: to send signals to a server or to terminate a server.
! 85:
! 86: \subsection{Resetting an engine}
! 87:
! 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,
! 90: which may cause troubles.
! 91: To reset an engine safely the following are required.
! 92:
! 93: \begin{enumerate}
! 94: \item Any OX message must be a synchronized object in the sense of Java.
! 95:
! 96: As an OX message is sent as a combination of several {\tt CMO}
! 97: data, a global exit without sending all may generate broken data.
! 98:
! 99: \item After restarting an engine, a request from a client
! 100: must correctly corresponds to the response from the engine.
! 101:
! 102: An incorrect correspondence occurs if some data remain on the stream
! 103: after restarting an engine.
! 104: \end{enumerate}
! 105:
! 106: {\tt SM\_control\_reset\_connection} is a stack machine command to
! 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}
! 115: \begin{enumerate}
! 116: \item After sending {\tt SM\_control\_reset\_connection} to the
! 117: control server, the client enters the resetting state. It discards all {\tt
! 118: OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}.
! 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:
! 123: \noindent
! 124: {\it Engine side}
! 125: \begin{enumerate}
! 126: \item
! 127: After receiving {\tt SIGUSR1} from the control server,
! 128: the engine enters the resetting state.
! 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.
! 132: \item The engine discards all OX messages from the engine until it
! 133: receives {\tt OX\_SYNC\_BALL}. After receiving {\tt OX\_SYNC\_BALL}
! 134: the engine returns to the usual state.
! 135: \end{enumerate}
! 136:
! 137: \begin{figure}[htbp]
! 138: \epsfxsize=8.5cm
! 139: \begin{center}
! 140: \epsffile{reset.eps}
! 141: \end{center}
! 142: \caption{OpenXM reset procedure}
! 143: \label{reset}
! 144: \end{figure}
! 145:
! 146: Figure \ref{reset} illustrates the flow of data.
! 147: {\tt OX\_SYNC\_BALL} is used to mark the end of data remaining in the
! 148: I/O streams. After reading it, it is assured that each stream is empty
! 149: and that the subsequent request from a client correctly
! 150: corresponds to the response from the engine.
! 151: We note that we don't have to associate {\tt OX\_SYNC\_BALL} with
! 152: any special action to be executed by the engine because it is
! 153: assured that the engine is in the resetting state when it has received
! 154: {\tt OX\_SYNC\_BALL}.
! 155:
! 156: \subsection{Debugging facilities}
! 157: Debugging is sometimes very hard for distributed computations.
! 158: We provide two methods to help debugging on X window system:
! 159: 1. the diagnostic messages from the engine are displayed in a {\tt xterm}
! 160: window;
! 161: 2. the engine can pop up a window to input debug commands.
! 162: For example {\tt ox\_asir}, which is
! 163: the OpenXM server of Risa/Asir, can pop up a window to input
! 164: debug commands and the debugging similar to that on usual terminals is possible.
! 165: One can also send {\tt SIGINT} by using {\tt SM\_control\_to\_debug\_mode}
! 166: and it provides a similar functionality to entering the debugging
! 167: mode from a keyboard interruption.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to session-management.tex CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [local] / OpenXM / doc / calc2000