| version 1.3, 2000/01/04 09:14:14 |
version 1.5, 2000/01/11 05:35:48 |
|
|
| % $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.2 2000/01/02 07:32:12 takayama Exp $ |
% $OpenXM: OpenXM/doc/issac2000/session-management.tex,v 1.4 2000/01/07 06:27:55 noro Exp $ |
| |
|
| \section{Session Management} |
\section{Session Management} |
| |
\label{secsession} |
| %MEMO: key words: |
%MEMO: key words: |
| %Security (ssh PAM), initial negotiation of byte order, |
%Security (ssh PAM), initial negotiation of byte order, |
| %mathcap, interruption, debugging window, etc. |
%mathcap, interruption, debugging window, etc. |
| Line 31 A server reads data from the stream {\bf 3} and writes |
|
| Line 31 A server reads data from the stream {\bf 3} and writes |
|
| stream {\bf 4}. The streams {\bf 1} and {\bf 2} are provided for |
stream {\bf 4}. The streams {\bf 1} and {\bf 2} are provided for |
| diagnostic messages from the server. As {\bf 3} and {\bf 4} are |
diagnostic messages from the server. As {\bf 3} and {\bf 4} are |
| streams for binary data, the byte order conversion is necessary when a |
streams for binary data, the byte order conversion is necessary when a |
| client and a server have different byte orders. There are several |
client and a server have different byte orders. Various |
| methods to treat it and we adopted the following scheme. |
methods are possible to treat it and we adopted the following scheme. |
| |
|
| \begin{itemize} |
\begin{itemize} |
| \item A server writes 1 byte representing the preferable byte order. |
\item A server writes 1 byte representing the preferable byte order. |
| \item After reading the byte, a client writes 1 byte representing the |
\item After reading the byte, a client writes 1 byte representing the |
| preferable byte order. |
preferable byte order. |
| \item On each side, if the preference coicides with each other then |
\item On each side, if the preference coincides with each other then |
| the byte order is used. Otherwise the network byte order is used. |
the byte order is used. Otherwise the network byte order is used. |
| \end{itemize} |
\end{itemize} |
| |
|
| This implies that all servers and clients can handle the network byte |
This implies that all servers and clients should be able to |
| |
handle the network byte |
| order. Nevertheless it is necessary to negotiate the byte order to |
order. Nevertheless it is necessary to negotiate the byte order to |
| skip the byte order conversion because its cost is often dominant over |
skip the byte order conversion because its cost is often dominant over |
| fast networks. |
fast networks. |
| Line 60 the launcher as follows. |
|
| Line 61 the launcher as follows. |
|
| \item A launcher is invoked from a client or by hand. |
\item A launcher is invoked from a client or by hand. |
| When the launcher is invoked, a port number for TCP/IP connection |
When the launcher is invoked, a port number for TCP/IP connection |
| and the name of a server should be informed. |
and the name of a server should be informed. |
| \item The launcher and the client establish a conection with the |
\item The launcher and the client establish a connection with the |
| specified port number. |
specified port number. |
| \item The launcher create a process and execute the server after |
\item The launcher create a process and execute the server after |
| setting the streams {\bf 3} and {\bf 4} appropriately. |
setting the streams {\bf 3} and {\bf 4} appropriately. |
| Line 78 When we use a mathematical software, an execution time |
|
| Line 79 When we use a mathematical software, an execution time |
|
| storage is often unknown in advance. Therefore it is desirable |
storage is often unknown in advance. Therefore it is desirable |
| to be able to abort an execution and to start another execution. |
to be able to abort an execution and to start another execution. |
| On a usual session on UNIX it is done by an interruption from a keyboard. |
On a usual session on UNIX it is done by an interruption from a keyboard. |
| Internally it is realized by an exeption processing initiated by |
Internally it is realized by an exception processing initiated by |
| a {\bf signal}, but it is not easy to send a signal to a server. |
a {\bf signal}, but it is not easy to send a signal to a server. |
| Especially if a server and a client run on different machines, |
Especially if a server and a client run on different machines, |
| the client cannot send a signal to the server directly. |
the client cannot send a signal to the server directly. |
| Line 88 system dependent and lack robustness. |
|
| Line 89 system dependent and lack robustness. |
|
| On OpenXM we adopted the following simple and robust method. |
On OpenXM we adopted the following simple and robust method. |
| |
|
| An OpenXM server has logically two I/O channels: one for exchanging |
An OpenXM server has logically two I/O channels: one for exchanging |
| data for computations and the other for controling computations. The |
data for computations and the other for controlling computations. The |
| control channel is used to send commands to control execution on the |
control channel is used to send commands to control execution on the |
| server. There are several ways of implementing the control channel. |
server. There are several ways of implementing the control channel. |
| Among them it is common to use the launcher introduced in Section |
Among them it is common to use the launcher introduced in Section |
| \ref{launcher} as a control process. We call such a process a {\bf |
\ref{launcher} as a control process. We call such a process a {\bf |
| control server}. In contrast, we call a server for computation an {\bf |
control server}. In contrast, we call a server for computation an {\bf |
| engine}. In this case the control server and the engine runs on the |
engine}. In this case the control server and the engine runs on the |
| same machine and it is easy to maniputalate the engine, especially to |
same machine and it is easy to manipulate the engine, especially to |
| send a signal from the control server. A control server is also an |
send a signal from the control server. A control server is also an |
| OpenXM stackmachine and the following {\tt SM} commands are provided. |
OpenXM stackmachine and the following {\tt SM} commands are provided. |
| |
|
|
|
| \item The client sends {\tt SM\_control\_reset\_connection} to the |
\item The client sends {\tt SM\_control\_reset\_connection} to the |
| control server. |
control server. |
| \item The client enters the resetting state. it skips all {\tt |
\item The client enters the resetting state. it skips all {\tt |
| OX} messages from the engine until it recieves {\tt OX\_SYNC\_BALL}. |
OX} messages from the engine until it receives {\tt OX\_SYNC\_BALL}. |
| \item After receiving {\tt OX\_SYNC\_BALL} the client sends |
\item After receiving {\tt OX\_SYNC\_BALL} the client sends |
| {\tt OX\_SYNC\_BALL} to the engine and returns to the usual state. |
{\tt OX\_SYNC\_BALL} to the engine and returns to the usual state. |
| \end{enumerate} |
\end{enumerate} |
| Line 161 the client reads and skips {\tt OX} messages soon afte |
|
| Line 162 the client reads and skips {\tt OX} messages soon afte |
|
| {\tt SM\_control\_reset\_connection}. |
{\tt SM\_control\_reset\_connection}. |
| \item The engine sends {\tt OX\_SYNC\_BALL} to the client. |
\item The engine sends {\tt OX\_SYNC\_BALL} to the client. |
| \item The engine skips all {\tt OX} messages from the engine until it |
\item The engine skips all {\tt OX} messages from the engine until it |
| recieves {\tt OX\_SYNC\_BALL}. |
receives {\tt OX\_SYNC\_BALL}. |
| \item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the |
\item After receiving {\tt OX\_SYNC\_BALL} the engine returns to the |
| usual state. |
usual state. |
| \end{enumerate} |
\end{enumerate} |
| Line 188 OX\_SYNC\_BALL} must initiate an engine into entering |
|
| Line 189 OX\_SYNC\_BALL} must initiate an engine into entering |
|
| state, and it makes the resetting scheme complicated and it may |
state, and it makes the resetting scheme complicated and it may |
| introduce unexpected bugs. For example, if a client sends {\tt |
introduce unexpected bugs. For example, if a client sends {\tt |
| OX\_SYNC\_BALL} without waiting {\tt OX\_SYNC\_BALL} from the engine, |
OX\_SYNC\_BALL} without waiting {\tt OX\_SYNC\_BALL} from the engine, |
| then it is possible that the engine recieves it before the arrival of |
then it is possible that the engine receives it before the arrival of |
| the signal. We note that we really encountered serious bugs caused |
the signal. We note that we really encountered serious bugs caused |
| by such an inappropriate protocol before reaching the final specicication. |
by such an inappropriate protocol before reaching the final specification. |
| |
|
| \subsection{Debugging} |
\subsection{Debugging supports} |
| An OpenXM server may allow definition and execution of functions |
An OpenXM server may allow definition and execution of functions |
| written in the user language proper to the server. To help debugging |
written in the user language proper to the server. To help debugging |
| such functions on the server, various supports are possible. If |
such functions on the server, various supports are possible. If |
| servers are executed on X window system, then the control server can |
servers are executed on X window system, then the control server can |
| attach an {\tt xterm} to the standard outputs of the engine, which |
attach an {\tt xterm} to the standard outputs of the engine, which |
| makes it possible to display messages from the engine. Furthermore, if |
makes it possible to display messages from the engine. Furthermore, if |
| the engine provides an inteface to input commands which directly |
the engine provides an interface to input commands which directly |
| controls the engine, then debugging of user define programs will be |
controls the engine, then debugging of user define programs will be |
| possible. For example {\tt Risa/Asir} provides a function {\tt |
possible. For example {\tt Risa/Asir} provides a function {\tt |
| debug()} to debug user defined functions. {\tt ox\_asir}, which is |
debug()} to debug user defined functions. {\tt ox\_asir}, which is |
| Line 208 debug commands when {\tt debug()} is executed on the s |
|
| Line 209 debug commands when {\tt debug()} is executed on the s |
|
| As the responses to the commands are displayed on the {\tt xterm}, |
As the responses to the commands are displayed on the {\tt xterm}, |
| the debugging similar to that on usual terminals is possible. |
the debugging similar to that on usual terminals is possible. |
| Moreover one can send {\tt SIGINT} by using {\tt SM\_control\_intr} |
Moreover one can send {\tt SIGINT} by using {\tt SM\_control\_intr} |
| and it provides a similar functinality to entering the debugging |
and it provides a similar functionality to entering the debugging |
| mode from a keyboard interruption. |
mode from a keyboard interruption. |