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