=================================================================== RCS file: /home/cvs/OpenXM/doc/Attic/genkou19991125.tex,v retrieving revision 1.5 retrieving revision 1.79 diff -u -p -r1.5 -r1.79 --- OpenXM/doc/Attic/genkou19991125.tex 1999/12/18 13:59:50 1.5 +++ OpenXM/doc/Attic/genkou19991125.tex 1999/12/24 21:56:37 1.79 @@ -1,147 +1,614 @@ \documentclass{jarticle} -\title{\bf Open XM($B%?%$%H%kL$Dj(B)} -\author{ - Maekawa \\ - Noro \\ - : \\ - : \\ +%% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.78 1999/12/24 21:01:21 tam Exp $ + +\usepackage{jssac} +\title{ +1. 意味もない修飾過剰な語句は排除しましょう。\\ +2. せっかく fill しているのをいじらないでくれ。\\ +3. 田村が遊んでばかりでおればかり仕事をしているのはどう考えても不公平だ。 +なんで仕事をしないのか、いい加減仕事をしろ、田村。 +%↑すみません、家で御飯食べてました。 } -\date{ 1999$BG/(B, 11$B7n(B25$BF|(B} -%\pagestyle{empty} +\author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科} + \mail{okutani@math.sci.kobe-u.ac.jp} + \and 小 原 　 功 任\affil{金沢大学理学部} + \mail{ohara@kappa.s.kanazawa-u.ac.jp} + \and 高 山 　 信 毅\affil{神戸大学理学部} + \mail{takayama@math.sci.kobe-u.ac.jp} + \and 田 村 　 恭 士\affil{神戸大学大学院自然科学研究科} + \mail{tamura@math.sci.kobe-u.ac.jp} + \and 野 呂 　 正 行\affil{富士通研究所} + \mail{noro@para.flab.fujitsu.co.jp} + \and 前 川 　 将 秀\affil{神戸大学理学部} + \mail{maekawa@math.sci.kobe-u.ac.jp} +} +\art{} \begin{document} \maketitle -\section{OpenXM $B$N7W;;%b%G%k(B} +\section{OpenXMとは} -OpenXM $B$O?t3X%=%U%H4V$G%a%C%;!<%8$r8r49$9$k$?$a$N5,Ls$G$"$k!#(B -OpenXM $B$H$O(B Open message eXchange protocol for Mathematics $B$NN,$G$"$k!#(B -$B?t3X%=%U%H4V$G%a%C%;!<%8$r$d$j$H$j$5$;$k$3$H$K$h$j!"(B -$B$"$k?t3X%=%U%H$+$iB>$N?t3X%=%U%H$r8F$S=P$7$F7W;;$r9T$J$C$?$j!"(B -$BB>$N%^%7%s$G7W;;$r9T$J$o$;$?$j$G$-$k$h$&$K$9$k!#(B -$BH/C<$OLnO$@59T$H9b;3?.5#$K$h$j!"(B asir $B$H(B kan/sm1 $B$r(B -$BAj8_$K8F$S=P$95!G=$r$N?t3X%=%U%H$r;H$($k$h$&$K$9$k$3$H$G$"$k!#(B +OpenXM は数学プロセス間でメッセージを交換するための規約である。 +数学プロセス間でメッセージをやりとりすることにより、 +ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり、 +他のマシンで計算を行なわせたりすることが目的である。 +なお、 OpenXM とは Open message eXchange protocol for Mathematics の略である。 +OpenXM の開発の発端は野呂と高山により、 +asir と kan/sm1 を相互に呼び出す機能を実装したことである。 -$BH/C<$H$J$C$?(B asir $B$H(B kan/sm1 $B$G$N$N7A<0$r$b(B -$B07$($k$h$&$K$7$F$"$k!#(B +現在の OpenXM 規約では共通表現形式によるメッセージを用いている。 +上記の文字列を送る方法の利点を生かすため、 +OpenXM 規約では共通表現形式の中の文字列として、 +ローカル言語の文法に従った文字列を用いたメッセージの交換も可能となっている。 +OpenXM 規約では通信の方法に幾らかの自由度があるが、 +現在のところは TCP/IP を用いた通信しか実装されていない。 +そこで、この論文では具体的な実装は TCP/IP を用いていると仮定する。 -\section{OpenXM $B$N%a%C%;!<%8$N9=B$(B} +\section{OpenXM のメッセージの構造} -OpenXM $B$G5,Dj$7$F$$$k%a%C%;!<%8$OO@M}E*$K(B -OX $BAX!"(B SM $BAX!"(B CMO $BAX$KJ,$1$k$3$H$,$G$-$k!#(B -$B$3$NCf$G!"%a%C%;!<%8$H$7$FAw$k$3$H$,2DG=$J$N$O(B -OX $BAX$GDj5A$5$l$?$b$N$@$1$G$"$j!"(B -SM $BAX!"(B CMO $BAX$GDj5A$5$l$F$$$k%G!<%?$O(B -OX $BAX$GDj5A$5$l$F$$$k%G!<%?$N0lIt$KKd$a9~$^$l$F(B -$BAw$i$l$k!#(B -SM $BAX!"(B CMO $BAX$GDj5A$5$l$F$$$k%G!<%?0J30$K$b(B -$BA0=R$N(B MP $B$d(B OpenMath $B$N(B XML, binary $BI=8=$b(B -OX $BAX$KKd$a9~$^$l$FAw$i$l$k$o$1$G$"$k$,!"(B -$B$I$N$h$&$J%G!<%?$,Kd$a9~$^$l$F$$$k$+$O!"(B -OX $BAX$N@hF,$N(B tag $B$r8+$l$PH=JL$G$-$k$h$&$K$J$C$F$$$k!#(B +通信の方法によってメッセージの構造は変わる。 +前節で仮定したとおり、この論文では TCP/IP の場合についてのみ説明を行なう。 +OpenXM 規約で規定されているメッセージはバイトストリームとなっており、 +次のような構造になっている。 -\section{OpenXM $B$N7W;;$N?J9TJ}K!(B} +\begin{tabular}{|c|c|} +\hline +ヘッダ & \hspace{10mm} ボディ \hspace{10mm} \\ +\hline +\end{tabular} -OpenXM $B5,Ls$G$N%a%C%;!<%8$N8r49$O%5!<%P$H%/%i%$%"%s%H$N4V$G(B -$B9T$J$o$l$k!#%/%i%$%"%s%H$+$i%5!<%P$X7W;;$5$;$?$$%G!<%?$r(B -$B%a%C%;!<%8$H$7$FAw$j!"Dj$5$l$F$*$j!"l9g$K$O!"$=$l$KBP1~$9$kF0:n$r9T$J$&!#(B -$B$3$N$H$-!"I,MW$,$"$l$P%5!<%P$O%9%?%C%/$+$i%G!<%?$rl9g!"(B -$B%5!<%P$OF0:n$N7k2L$r%9%?%C%/$K@Q$s$G$$$k!#(B -$B%5!<%P$K9T$J$o$;$?F0:n$N7k2L$r%/%i%$%"%s%H$,CN$j$?$$>l9g!"(B -$B%9%?%C%/$+$i%G!<%?$rl9g!"(B -CMO $BAX$GDj5A$5$l$F$$$kB?G\D9@0?t$rM}2r$7$F$*$/$H!"(B -CMO $BAX$NB>$N%G!<%?9=B$$@$1$G$J$/!"(B OX $BAX!"(B SM $BAX$N%G!<%?$r(B -$BM}2r$9$k=u$1$K$J$k$H;W$($k$N$G!"(B CMO $BAX$NB?G\D9@0?t$N(B -$B%G!<%?9=B$$K$D$$$F@bL@$9$k!#(B +OpenXM 規約ではサーバはスタックマシンであると定義している。以下、OpenXM +スタックマシンと呼ぶ。この節ではOpenXM スタックマシンの構造について説明 +しよう。 -CMO $BAX$GDj5A$5$l$F$$$k%G!<%?$OB?G\D9@0?t0J30$K$b(B -$BJ8;zNs$d%j%9%H$J$I$,$"$k!#$I$N$h$&$J%G!<%?$G$"$k$+$O(B -$B%G!<%?$N@hF,$K$"$k(B tag $B$r8+$l$PH=JL$G$-$k$h$&$K$J$C$F$$$k!#(B -$B$3$l$O(B OX $BAX$G$N%G!<%?$NH=JL$N;EJ}$H$*$J$8$G$"$k!#(B -$B$J$*!"(B tag $B$O3F%G!<%?Kh$K(B 32 bit $B$N@0?t$GI=$5$l$F$*$j!"(B -$BB?G\D9@0?t$O(B 20 $B$H$J$C$F$$$k!#(B -$B$3$3$G(B 32 bit $B$N@0?t$NI=8=J}K!$K$D$$$F@bL@$9$kI,MW$,$"$k!#(B -%$B:r:#$N%3%s%T%e!<%?;v>p$+$i!"(B -%32 bit $B@0?t$b(B 8 bit $BC10L$G07$&$[$&$,ET9g$,$h$$!#(B -OpenXM $B$G$O(B 8 bit $BC10L$G(B $( \mbox{\tt 00 00 00 14})_{2^8}$ $B$HI=$9J}K!$H(B -$( \mbox{\tt 14 00 00 00})_{2^8}$ $B$HI=$9J}K!$,$"$k!#(B -$B$3$NI=8=J}K!$N0c$$$O%/%i%$%"%s%H$H%5!<%P$N:G=i$N@\B3;~$K(B -$BAPJ}$N9g0U$G7hDj$9$k$3$H$K$J$C$F$$$k!#$J$*!"9g0U$,$J$$>l9g$K$O(B -$BA0l9g$N7e?t$r(B $n$ $B$H(B -$B$7$?$H$-!"l9g$N7e?t$H$H$C$F$b$h$$!#(B -$B$?$@$7!"I=8=$7$?$$?t$,Ii$N>l9g$O$3$N(B 32 bit $B$N@0?tCM$O(B 2 $B$NJd?tI=8=$GIi$K$J$k!#(B +次に OpenXM スタックマシンの命令コードについて説明する。OpenXM スタック +マシンにおけるすべての命令は4バイトの長さを持つ。OpenXM 規約の他の規定と +同様に、4バイトのデータは32ビット整数と見なされるので、この論文でもその +表記にしたがう。OpenXM スタックマシンに対する命令はスタックに積まれるこ +とはない。現在のところ、OpenXM 規約では以下の命令が定義されている。 -%$BI=8=$7$?$$B?G\D9@0?t$,Ii$G$"$C$F$b$3$l0J9_$N@bL@$O@5$N>l9g$H(B -%$BJQ$o$i$J$$$N$G!"0J8eB?G\D9@0?t$O@5$H$_$J$9!#(B +\begin{verbatim} +#define SM_popSerializedLocalObject 258 +#define SM_popCMO 262 +#define SM_popString 263 -$BI=8=$7$?$$B?G\D9@0?t$N@dBPCM$,(B $2^32$ $B?J?t$G(B $(b_0 b_1 ...)_{2^32}$ -$B$HI=$;$k$H$-!"$N%W%m%8%'%/%H(B} -\section{$B8=:_Ds6!$5$l$F$$$k%=%U%H%&%'%"(B} +\section{CMO のデータ構造}\label{sec:cmo} + +OpenXM 規約では、数学的オブジェクトを表現する方法として CMO 形式(Common +Mathematical Object format)を定義している。この CMO 形式にしたがったデー +タは、識別子が OX\_DATA であるようなメッセージのボディになることを想定し +ている。 + +CMO 形式におけるデータ構造は次のような構造をもつ。 + +\begin{tabular}{|c|c|} \hline +ヘッダ & \hspace{10mm} ボディ \hspace{10mm} \\ \hline +\end{tabular} + +ヘッダは4バイトである。ボディの長さはそれぞれのデータによって異なるが、 +0でもよい。 + +メッセージと同様にヘッダは4バイト単位に管理される。すなわち、CMO ではヘッ +ダは一つだけの情報を含む。この4バイトのヘッダのことをタグともいう。さて、 +CMO では、タグによってボディの論理的構造が決定する。すなわち、タグはそれ +ぞれのデータ構造と1対1に対応する識別子である。それぞれの論理的構造は +\cite{OpenXM-1999} に詳述されている。現在の OpenXM 規約では以下の CMO が +定義されている。 + +\begin{verbatim} +#define CMO_ERROR2 0x7f000002 +#define CMO_NULL 1 +#define CMO_INT32 2 +#define CMO_DATUM 3 +#define CMO_STRING 4 +#define CMO_MATHCAP 5 + +#define CMO_START_SIGNATURE 0x7fabcd03 +#define CMO_ARRAY 16 +#define CMO_LIST 17 +#define CMO_ATOM 18 +#define CMO_MONOMIAL32 19 +#define CMO_ZZ 20 +#define CMO_QQ 21 +#define CMO_ZERO 22 +#define CMO_DMS_GENERIC 24 +#define CMO_DMS_OF_N_VARIABLES 25 +#define CMO_RING_BY_NAME 26 +#define CMO_RECURSIVE_POLYNOMIAL 27 +#define CMO_LIST_R 28 + +#define CMO_INT32COEFF 30 +#define CMO_DISTRIBUTED_POLYNOMIAL 31 +#define CMO_POLYNOMIAL_IN_ONE_VARIABLE 33 +#define CMO_RATIONAL 34 + +#define CMO_64BIT_MACHINE_DOUBLE 40 +#define CMO_ARRAY_OF_64BIT_MACHINE_DOUBLE 41 +#define CMO_128BIT_MACHINE_DOUBLE 42 +#define CMO_ARRAY_OF_128BIT_MACHINE_DOUBLE 43 + +#define CMO_BIGFLOAT 50 +#define CMO_IEEE_DOUBLE_FLOAT 51 + +#define CMO_INDETERMINATE 60 +#define CMO_TREE 61 +#define CMO_LAMBDA 62 +\end{verbatim} + +この中で CMO\_ERROR2, CMO\_NULL, CMO\_INT32, CMO\_DATUM, CMO\_STRING, +CMO\_MATHCAP, CMO\_LIST で識別されるオブジェクトは最も基本的なオブジェ +クトであって、すべての OpenXM 対応システムに実装されていなければならない。 + +これらについての解説を行う前に記法について、少し説明しておく。 +この論文では、大文字で CMO\_INT32 と書いた場合には、上記で定義した識別子 +を表わす。また CMO\_INT32 で識別されるオブジェクトのクラス(あるいはデー +タ構造)を cmo\_int32 と小文字で表わすことにする。 + +さて cmo を表現するための一つの記法を導入する。この記法は CMO expression +と呼ばれている。その正確な形式的定義は \cite{OpenXM-1999} を参照すること。 + +まず CMO expssion は Lisp 風表現の一種で、 cmo を括弧で囲んだリストとし +て表現する。それぞれの要素はカンマで区切る。 +例えば、 +\begin{quote} +(17, {\sl int32}, (CMO\_NULL), (2, {\sl int32} $n$)) +\end{quote} +は CMO expression である。ここで、小文字の斜体で表された``{\sl int32}'' +は 4バイトの任意のデータを表す記号であり、``{\sl int32} $n$'' は同じく 4 +バイトのデータであるが以下の説明で $n$ と表すことを示す。また数字 17, 2 +などは 4バイトのデータで整数値としてみたときの値を意味する。CMO\_NULL は +識別子(すなわち数字 1 と等価)である。この記法から上記のデータは 20 バイ +トの大きさのデータであることが分かる。 +なお、このデータは CMO ではないことに注意してほしい。 +%なお、 CMO expression で表現できていても、 +%それが CMO であることとは無関係である。 + +さて、この記法のもとで cmo\_int32 を次のデータ構造を持つと定義する。 +\begin{quote} +cmo\_int32 := (CMO\_INT32, {\sl int32} $a$) +\end{quote} + +%{\Huge 同様に cmo\_string, cmo\_list などを定義} + +これは CMO の 32 ビット整数 $a$ を表す。 +他のオブジェクトも定義するために、 +以後 ``{\sl string} $s$'' を文字列 $s$ 、 +``{\sl cmo} $ob$'' を CMO の $ob$ とする。 +これを用いて、 cmo\_string, cmo\_list を定義する。 + +\begin{quote} +cmo\_string := (CMO\_STRING, {\sl int32} $len$, {\sl string} $str$) \\ +cmo\_list := (CMO\_LIST, {\sl int32} $n$, {\sl cmo} $ob_1$, + {\sl cmo} $ob_2$, $\cdots$,{\sl cmo} $ob_n$) +\end{quote} + +これはそれぞれ長さ $len$ の文字列 $str$ と、 +$ob_1$, $ob_2$, $\cdots$, $ob_n$ からなる長さ $n$ のリストを表す。 + + +% ここで 32 bit の整数の表現方法について触れておく。 +% OpenXM 規約ではバイトストリームで 32 bit の整数 20 を +% {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。 +% この表現方法の違いはクライアントとサーバの最初の接続時に +% 双方の合意で決定することになっている。 +% なお、合意がない場合には前者の表現方法 +% (以後、この表現方法をネットワークバイトオーダーと呼ぶ)を +% 使うことになっている。 +% また、負の数を表現する必要があるときには、 +% 2 の補数表現を使うことになっている。 + +% 先ほどの、 (CMO\_INT32, 123456789) をネットワークバイトオーダーで +% バイト列に直すと、 +% \begin{center} +% {\tt 00 00 00 02 07 5b cd 15} +% \end{center} +% となり、 +% (CMO\_STRING, 6, ``OpenXM'') は +% \begin{center} +% {\tt 00 00 00 04 00 00 00 06 4f 70 65 6e 58 4d} +% \end{center} +% となる。 + +% CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、 +% 符号付き絶対値表現を用いている。 +% タグ以降の形式は次のようになる。 + +% \begin{tabular}{|c|c|c|c|c|} \hline +% $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline +% \end{tabular} + +% ここで、 1 つの枠は 4 バイトを表し、 +% $f$ は符号付き 32 ビット整数を、 +% $b_0$, $b_1$, $\cdots$, $b_{n-1}$ は符号なし 32 ビット整数を表している。 +% さらに、 $|f| = n$ が成り立たなければならない。 +% このオブジェクトは +% \[ \mbox{sgn}(f) \times \{ b_0 (2^{32})^0 + b_1 (2^{32})^1 + \cdots +% + b_{n-1} (2^{32})^{n-1} \} \] +% という整数であると定義されている。 +% ただし、 +% \[ \mbox{sgn}(f) = \left\{ \begin{array}{ll} +% 1 & f>0 \\ +% 0 & f=0 \\ +% -1 & f<0 \\ \end{array} \right. \] +% である。 + +% ここで具体例をだそう。 +% $4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の +% ネットワークバイトオーダー、多倍長整数で表現すると、 +% \begin{center} +% {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01} +% \end{center} +% となる。また、同じ表現方法で $-1$ を表現すると、 +% \begin{center} +% {\tt 00 00 00 14 ff ff ff ff 00 00 00 01} +% \end{center} +% となる。 + + +\section{mathcap について} + +OpenXM 規約では、通信時に用いられるメッセージの種類を各ソフトウェアが制 +限する方法を用意している。これは各ソフトウェアの実装によってはすべてのメッ +セージをサポートするのが困難な場合があるからである。また、各ソフトウェア +でメッセージの種類を拡張したい場合にも有効である。この制限(あるいは拡張) +は mathcap と呼ばれるデータ構造によって行われる。この節では mathcap のデー +タ構造と、具体的なメッセージの制限の手続きについて説明する。 + +では、手続きについて説明しよう。 + +第一にサーバの機能を制限するには次のようにする。クライアントが mathcap +オブジェクトをサーバへ送ると、サーバは受け取ったmathcap をスタックに積む。 +次にクライアントが命令 SM\_setMathCap を送ると、サーバはスタックの最上位 +に積まれている mathcap オブジェクトを取り出し、mathcap で設定されていな +いメッセージをクライアントへ送らないように制限を行う。 + +第二にクライアントを制限するには次のようにする。クライアントがサーバに命 +令 SM\_mathcap を送ると、サーバは mathcap オブジェクトをスタックに積む。 +さらに命令 SM\_popCMO を送ると、サーバはスタックの最上位のオブジェクト +(すなわち mathcap オブジェクト)をボディとするメッセージをクライアントに +送付する。クライアントはそのオブジェクトを解析して、制限をかける。 + +次に mathcap のデータ構造について説明する。 +mathcap は CMO の一種であるので、すでに説明したように \\ +\begin{tabular}{|c|c|} \hline +ヘッダ & \hspace{10mm} ボディ \hspace{10mm} \\ \hline +\end{tabular} \\ +の構造を持ちヘッダの値は 5 である(\ref{sec:cmo} 節を参照のこと)。 +ボディは cmo\_list オブジェクトでなければならない。 + +%\begin{quote} +% cmo\_mathcap := (CMO\_MATHCAP,{\sl cmo} obj) +%\end{quote} + +さて、mathcap オブジェクトのボディの cmo\_list オブジェクトは以下の条件を +満たすことを要求される。 + +まず、その cmo\_list オブジェクトは少なくともリスト長が 3 以上でなければ +ならない。 + +\begin{quote} + (CMO\_LIST, {\sl int32} $3$, + {\sl cmo} $A$, {\sl cmo} $B$, {\sl cmo} $C$) +\end{quote} +%\[ \begin{tabular}{|c|c|c|} \hline +% $A$ & $B$ & $C$ \\ \hline +% \end{tabular} \] + +第一要素 $A$ はまた cmo\_list であり、リスト長は 4 以上、 +$a_1$ は 32 ビット整数でバージョンナンバーを、 +$a_2$, $a_3$, $a_4$ は文字列で +それぞれシステムの名前、、 CPU の種類を表すことになっている。 +\begin{quote} + (CMO\_LIST, {\sl int32} $4$, + {\sl cmo\_int32} $a_1$, {\sl cmo\_string} $a_2$, + {\sl cmo\_string} $a_3$, {\sl cmo\_string} $a_4$) +\end{quote} + +2 番目の要素 $B$ の部分は次のようなリスト構造をしている。 +この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて 32 ビットの整数である。 +\ref{sec:oxsm} 節でみたように、 +スタックマシンへの命令はすべて 32 ビットの整数で表しており、 +各 $b_i$ は利用可能な命令に対応する 32 ビットの整数となっている。 +\begin{quote} + (CMO\_LIST, {\sl int32} $n$, + {\sl cmo\_int32} $b_1$, {\sl cmo\_int32} $b_2$, + $\cdots$, {\sl cmo\_int32} $b_n$) +\end{quote} + +3 番目の要素 $C$ は以下のようなリスト構造をしている。 +\begin{quote} + (CMO\_LIST, {\sl int32} $m$, \\ + \hspace{10mm} (CMO\_LIST, {\sl int32} $l_1$, {\sl cmo\_int32} $c_{11}$, + {\sl cmo} $c_{12}$, $\cdots$, {\sl cmo} $c_{1l_1}$) \\ + \hspace{10mm} (CMO\_LIST, {\sl int32} $l_2$, {\sl cmo\_int32} $c_{21}$, + {\sl cmo} $c_{22}$, $\cdots$, {\sl cmo} $c_{1l_2}$) \\ + \hspace{10mm} $\vdots$ \\ + \hspace{10mm} (CMO\_LIST, {\sl int32} $l_m$, {\sl cmo\_int32} $c_{m1}$, + {\sl cmo} $c_{m2}$, $\cdots$, {\sl cmo} $c_{1l_m}$)) +\end{quote} +%%$n$ は OX\_COMMAND 以外の受け取れるメッセージのタグの種類の数に等しい。 +%%要素数は 1 でももちろん構わない。 +どの $c_{i1}$ にも 32 ビットの整数が入っており、 +OX\_COMMAND 以外の、受け取れるメッセージのタグが入っている。 +$c_{i2}$ 以降については最初の $c_{i1}$ の値によってそれぞれ異なる。 +ここでは、最初の要素が OX\_DATA の場合についてのみ説明する。 +この $c_{i1}$ が OX\_DATA の場合、 +$c_{i1}$, $c_{i2}$, $\cdots$, $c_{il_i}$ を要素とする cmo\_list は +CMO 形式についての情報を表しており、 $l_i=2$ と決められている。 +$c_{i1}$ にはもちろんのこと OX\_DATA が入っており、 +$c_{i2}$ は以下の図のような cmo\_list になっている。 +各要素は 32 ビットの整数であり、 +受け取ることが可能な CMO 形式のタグが入る。 +\begin{quote} + (CMO\_LIST, {\sl int32} $k$, + {\sl cmo\_int32} $c_{i21}$, {\sl cmo\_int32} $c_{i22}$, + $\cdots$, {\sl cmo\_int32} $c_{i2k}$) +\end{quote} +%\[ \overbrace{ +% \begin{tabular}{|c|c|c|c|c|} \hline +% $c_{i21}$ & $c_{i22}$ & $\cdots$ & $c_{i2l}$ \\ \hline +% \end{tabular} +% }^{c_{i2}} \] + +%なお、 mathcap データの中では CMO 形式で定義されている +%32 bit 整数、文字列、リスト構造が使われており、 +%mathcap データに含まれている内容を理解できるためには +%必然的にこれらも理解できる必要がある +%(ってことは CMO 形式のところでこれらを +%説明しなければならないってことです)。 + +具体的な mathcap の例をあげよう。 +名前が ``ox\_test''、バージョンナンバーが 199911250 のサーバで、 +PC-UNIX 上で動いていれば、 +$A$ の部分は +\begin{quote} +(CMO\_LIST, 4, {\sl cmo\_int32} $199911250$, {\sl cmo\_string} "ox\_test", + {\sl cmo\_string} "Version=199911250", + {\sl cmo\_string} "HOSTTYPE=i386") +\end{quote} +となる。 +さらに、このサーバのスタックマシンが +命令コード 2, 3, 5, 7, 11 番を利用可能 +(実際にはこのような命令コードは存在しない)であれば、 $B$ の部分は +\begin{quote} + (CMO\_LIST, {\sl int32} $5$, + {\sl cmo\_int32} $2$, {\sl cmo\_int32} $3$, + {\sl cmo\_int32} $5$, {\sl cmo\_int32} $7$, + {\sl cmo\_int32} $11$) +\end{quote} +となり、 +CMO 形式の 32 ビット整数、文字列、 mathcap 、リスト構造のみが +受け取れるときには、 $C$ の部分は +\begin{quote} + (CMO\_LIST, {\sl int32} $1$, \\ + \ \ (CMO\_LIST, {\sl int32} $4$, + {\sl cmo\_int32} $2$, {\sl cmo\_int32} $4$, + {\sl cmo\_int32} $5$, {\sl cmo\_int32} $17$)) +\end{quote} +となる。 +%CMO\_ZZ がないので、このサーバは多倍長整数が送られてこないことを +%期待している。 + +なお、データが受け取れることと、データの論理構造が理解できることとはまっ +たく別物であるので注意する必要がある。 + +{\Huge ってなんででしょうか? データの論理構造を知らないと受け取れないと +思うんですが$\ldots$} + + +\section{セキュリティ対策} + +OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している。ネットワーク +によって接続される現代の多くのソフトウェアと同様、OpenXM 規約もまた通信 +時のセキュリティについて注意している。以下、このことについて説明しよう。 + +{\large\bf 意味不明なことを書いているが、} + +侵入者に攻撃の機会をできるだけ与えないようするた +めに、接続が必要になった時のみ接続を待つようにし、 +常に接続に関与するといったことは避けている(やっぱり意味不明である)。 + +また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、 +接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい +るのかはやっぱり不明であるが)。 +さらにもう一段安全性を高めるために、 +接続時に 1 回だけ使用可能なパスワードを作成し、 +そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ +ているのかが不明だけど)。 +このパスワードは一旦使用されれば無効にするので、 +もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。 + +なお、接続が確立した後のメッセージの送受信に関しては、 +特に暗号化などの処置を行っているわけではない。 +もし必要があれば、通信路の暗号化を行なう機能がある +ソフトウェア ssh を使うことを考えている。 + +\section{他のプロジェクト} + +他のプロジェクトについても触れておこう。 + +\begin{itemize} +\item OpenMath\\ +OpenMath プロジェクトは数学的なオブジェクトをコンピュータ上で表現する方 +法を規定している。各ソフトウェア間でオブジェクトを交換する際のオブジェク +トの変換手順につても定められている。表現方法は幾つかの段階で定められて +いて、XML 表現やバイナリ表現などが用意されている。詳細は + +http://www.openmath.org/omsoc/ A.M.Cohen + +\item NetSolve + +http://www.cs.utk.edu/netsolve/ + +\item MP + +http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html + +\item MCP + +http://horse.mcs.kent.edu/~pwang/ +\end{itemize} + + +\section{現在提供されているソフトウェア} + +現在 OpenXM 規約に対応しているクライアントにはasir, sm1, Mathematica が +ある。これらのクライアントから OpenXM 規約に対応したサーバを呼び出すこと +ができる。現在 OpenXM 規約に対応しているサーバソフトウェアには、asir, +sm1, gnuplot, Mathematica などがあり、それぞれ ox\_asir, ox\_sm1, +ox\_sm1\_gnuplot, ox\_math という名前で提供されている。また、 OpenMath +規約の XML 表現で表現されたオブジェクトと CMO 形式のオブジェクトを変換す +るソフトウェアが JAVA によって実装されており、OMproxy という名前で提供さ +れている。 + +\begin{thebibliography}{99} +\bibitem{Ohara-Takayama-Noro-1999} +小原功任, 高山信毅, 野呂正行: +{Open asir 入門}, 1999, 数式処理, Vol 7, No 2, 2--17. (ISBN4-87243-086-7, SEG 出版, Tokyo). +\bibitem{OpenXM-1999} +野呂正行, 高山信毅: +{Open XM の設計と実装 --- Open message eXchange protocol for Mathematics}, +1999/11/22 +\end{thebibliography} \end{document}