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. |