Annotation of OpenXM/doc/ascm2001p/session-management.tex, Revision 1.2
1.2 ! takayama 1: % $OpenXM: OpenXM/doc/ascm2001p/session-management.tex,v 1.1 2001/06/19 07:32:59 noro Exp $
1.1 noro 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
1.2 ! takayama 44: and the control channel.
! 45: Then it creates a server process which can communicate
1.1 noro 46: with the client via the data channel. Finally the launcher
47: acts as a control server and controls the server process.
48: As to the details of the control server see Section \ref{control}.
49: %As the data channel is used to exchange binary data,
50: %the byte order conversion is necessary when a
51: %client and a server have different byte orders. It is determined by
52: %exchanging the preferable byte order of each peer. If the preference
53: %does not coincide with each other,
54: %then the network byte order is used.
55: %This implies that all servers and clients should be able to
56: %handle the network byte
57: %order. Nevertheless it is necessary to negotiate the byte order to
58: %skip the byte order conversion because its cost is often dominant over
59: %fast networks.
1.2 ! takayama 60: OpenXM-RFC 101\cite{ox-rfc-101} gives a more secure and
1.1 noro 61: efficient way to start servers.
62: It uses ``ssh'' to launch a control server and
63: the control server can launch one or more than one
64: engines.
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.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>