[BACK]Return to genkou19991125.tex CVS log [TXT][DIR] Up to [local] / OpenXM / doc

Diff for /OpenXM/doc/Attic/genkou19991125.tex between version 1.31 and 1.89

version 1.31, 1999/12/21 09:06:47 version 1.89, 1999/12/25 13:58:52
Line 1 
Line 1 
 \documentclass{jarticle}  \documentclass{jarticle}
   
 \title{タイトル未定}  %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.88 1999/12/25 13:05:20 tam Exp $
 \author{  
 前川 将秀,  \usepackage{jssac}
 野呂 正行,  \title{
 小原 功任, \\  1. 意味もない修飾過剰な語句は排除しましょう. \\
 奥谷 幸夫,  2. せっかく fill しているのをいじらないでくれ. \\
 高山 信毅,  3. 田村が遊んでばかりでおればかり仕事をしているのはどう考えても不公平だ.
 田村 恭士  なんで仕事をしないのか, いい加減仕事をしろ, 田村. \\
   3.5 そういうご飯とかつまらない話じゃなくて, commit の情報をみれば田村が
   如何に仕事をしていないのかよくわかるよ. \\
 }  }
 \date{1999年11月25日}  
 %\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}  \begin{document}
 \maketitle  \maketitle
   
   
 \section{OpenXMとは}  \section{OpenXMとは}
   
 OpenXM は数学プロセス間でメッセージを交換するための規約である。数学プロ  OpenXM は数学プロセス間でメッセージを交換するための規約である.
 セス間でメッセージをやりとりさせることにより、ある数学プロセスから他の数  数学プロセス間でメッセージをやりとりすることにより,
 学プロセスを呼び出して計算を行なったり、他のマシンで計算を行なわせたりす  ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり,
 ることが目的である。なお、 OpenXM とは Open message eXchange protocol  他のマシンで計算を行なわせたりすることが目的である.
 for Mathematics の略である。  なお, OpenXM とは Open message eXchange protocol for Mathematics の略である.
 OpenXM の開発の発端は野呂正行と高山信毅により、 asir と kan/sm1 を  OpenXM の開発の発端は野呂と高山により,
 相互に呼び出す機能を実装したことである。  asir と kan/sm1 を相互に呼び出す機能を実装したことである.
 %\footnote{この段落必要?}  
   
 発端となった asir と kan/sm1 での実装時には、  初期の実装では, 相手側のローカル言語の文法に従った文字列を送っていた.
 お互いに相手側のコマンド文字列を送っていた。  この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして,
 この方法は現在の OpenXM 規約でも形を変えて可能ではあるが、  相手側のローカル言語の文法に合わせた文字列を作成しなければならない.
 使いやすい反面、効率的であるとはいい難い。  このローカル言語の文法に従った文字列を送る方法は,
 さらに、この方法では相手側のソフトが asir なのか kan/sm1 なのかを  効率的であるとはいい難いが, 使いやすいとも言える.
 判別して、相手側に合わせてコマンド文字列を作成する必要がある。  
   
 これ以外の方法として、  現在の OpenXM 規約では共通表現形式によるメッセージを用いている.
 OpenXM 規約では共通表現形式によるメッセージも用意している。  上記の文字列を送る方法の利点を生かすため,
 OpenXM 規約独自のデータ形式である CMO 形式(Common Mathematical Object format)  OpenXM 規約では共通表現形式の中の文字列として,
 以外にも、 MP や OpenMath の XML, binary 表現形式といった他の形式をも  ローカル言語の文法に従った文字列を用いたメッセージの交換も可能となっている.
 扱えるようにしてある。  
 なお、現在の OpenXM 規約では、  
 前述のコマンド文字列も CMO 形式などの何らかのデータ形式の中の  
 文字列として表現して送る必要がある。  
   
 \section{OpenXM の計算モデル}  OpenXM 規約では通信の方法に幾らかの自由度があるが,
   現在のところは TCP/IP を用いた通信しか実装されていない.
   \footnote{asir では MPI を用いた実装もある.}
   そこで, この論文では具体的な実装は TCP/IP を用いていると仮定する.
   
 {\Huge この節では計算モデルの話をしなければいけませんよ、田村君}  
   
 OpenXM 規約でのメッセージの交換はサーバとクライアントの間で行なわれる。  \section{OpenXM のメッセージの構造}
 クライアントからサーバへメッセージを送り、  
 サーバはスタックマシンであると仮定されており、サーバがクライアントから受  
 け取ったメッセージはすべてスタックに積まれる。OpenXM のメッセージの中に  
 はサーバに行なわせたい動作に対応するデータがあり、このメッセージを受け取っ  
 たサーバはそれに対応する動作を行なうことが期待されている。ただし、サーバ  
 は命令されない限り何も動作を行なおうとはしない。  
   
   通信の方法によってメッセージの構造は変わる.
   前節で仮定したとおり, この論文では TCP/IP の場合についてのみ説明を行なう.
   
 \section{OpenXM のメッセージの構造}  OpenXM 規約で規定されているメッセージはバイトストリームとなっており,
   次のような構造になっている.
   
 {\Huge この節では構造の話をしなければいけませんよ、田村君}  \begin{tabular}{|c|c|}
   \hline
   ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\
   \hline
   \end{tabular}
   
 OpenXM のメッセージはバイトストリームであり、次のような構造を持つ。  ヘッダの長さは 8 バイトであると定められている.
 \begin{verbatim}  ボディの長さはメッセージごとに異なっているが,
 ヘッダ  ボディ  長さは $0$ でもよい.
 \end{verbatim}  
 ヘッダの長さは8バイトであると定められている。ボディの長さはメッセージご  ヘッダは次の二つの情報を持っている.
 とに異なる($0$でもよい)。  
 ヘッダは次の二つの情報を持つ。  
 \begin{enumerate}  \begin{enumerate}
 \item 前半の4バイト。タグと呼ばれ、メッセージの種類を表わす識別子である。  \item   前半の 4 バイト. メッセージの種類を表わす識別子であり,
 \item 後半の4バイト。メッセージにつけられた通し番号である。          タグと呼ばれる.
   \item   後半の 4 バイト. メッセージにつけられた通し番号である.
 \end{enumerate}  \end{enumerate}
   それぞれの 4 バイトは 32 ビット整数とみなされて扱われる.
   
 それぞれの4バイトは32ビット整数とみなされて処理される。  この場合に用いられる 32 ビット整数の表現方法について説明しなければならない.
 この場合に用いられる整数の表現方法については後述するが、基本的に  32 ビットの正整数
 表現方法はいくつかの選択肢から選ぶことが可能であり、  $d_0 + d_1 \cdot 2^8 + d_2 \cdot (2^8)^2 + d_3 \cdot (2^8)^3$
 また選択は通信路の確立時に一度だけなされることに注意しておこう。  ($0 \le d_i < 2^8$ )をバイト列で表す場合,
   \begin{tabular}{|c|c|c|c|} \hline
   $d_3$ & $d_2$ & $d_1$ & $d_0$ \\ \hline
   \end{tabular}
   と表す方法と,
   \begin{tabular}{|c|c|c|c|} \hline
   $d_0$ & $d_1$ & $d_2$ & $d_3$ \\ \hline
   \end{tabular}
   と表す方法がある.
   この表現方法の違いは OpenXM 規約では通信路の確立時に一度だけ
   %選択肢から
   選ぶことが可能となっている.
   なお, 負の数を表す必要があるときには, 2 の補数表現を使うことになっている.
   %具体例をだそう.
   
 {\Huge 以下、書き直してね。}  % OpenXM 規約ではバイトストリームで 32 bit の整数 20 を
   % {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある.
   % この表現方法の違いはクライアントとサーバの最初の接続時に
   % 双方の合意で決定することになっている.
   % なお, 合意がない場合には前者の表現方法
   % (以後, この表現方法をネットワークバイトオーダーと呼ぶ)を
   % 使うことになっている.
   % また, 負の数を表現する必要があるときには,
   % 2 の補数表現を使うことになっている.
   
 ボディの中のデータがどのように格納されているかは  現在のOpenXM 規約では, タグ(整数値)として以下のものが定義されている.
 各データ形式がそれぞれ独立に決められるようになっている。  
 もし、 OpenXM 規約でメッセージのやりとりを行ないたいが、  
 まだ規約で定義されていないデータ形式を使いたい場合は、  
 タグをまだ使われてなさそうな値  
 (システム固有の表現のために推奨されている値がある)  
 に設定し、 ボディの部分にデータを埋め込めばよい。  
 なお、すべてのメッセージに ボディが必要というわけではなく、  
 ボディのないメッセージも OpenXM 規約には存在することに  
 注意しなければならない。  
   
 サーバに対する動作に対応したデータは SM 形式として定義されている。  \begin{verbatim}
 SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む  #define OX_COMMAND              513
 以外の動作をしないことになっている。  #define OX_DATA                 514
 つまり、 SM 形式のデータがデータを受け取る以外の動作を  #define OX_SYNC_BALL            515
 サーバに行なわせる唯一のデータ形式である。  #define OX_DATA_WITH_LENGTH     521
 このデータを受け取る以外の動作の中には、  #define OX_DATA_OPENMATH_XML    523
 データになんらかの加工を施す動作も入っている。  #define OX_DATA_OPENMATH_BINARY 524
 このデータになんらかの加工を施す動作の中には  #define OX_DATA_MP              525
 数学的な演算を行なう動作も含まれている。  \end{verbatim}
 以後、データになんらかの加工を施す動作のことを計算と呼ぶことにする。  
   
 \section{OpenXM の計算の進行方法}  ボディの構造はメッセージの種類によって異なる.
   タグが OX\_COMMAND となっているメッセージはスタックマシンへの命令であり,
   それ以外のメッセージは何らかのオブジェクトを表している.
   この論文では OX\_DATA と OX\_COMMAND で識別される
   メッセージについてのみ, 説明する.
   
 OpenXM における計算とはメッセージの交換のことである。既に計算モデルの節  既存のメッセージでは対応できない場合は, 新しい識別子を定義することで新し
 で説明したが(説明されているはずである)、OpenXM はサーバ・クライアントモ  い種類のメッセージを作成することができる. この方法は各数学ソフトウェアの
 デルを採用していて、サーバはスタックマシンの構造を持つ。サーバが行うのは  固有の表現を含むメッセージを作成したい場合などに有効である. 新しい識別子
 基本的に次の事柄に限られる。クライアントからメッセージを送られるとサーバ  の定義方法については, \cite{OpenXM-1999} を参照すること.
 は、まずメッセージの識別子を調べ、OX\_COMMAND でなければスタックに積む。  
 OX\_COMMAND であればメッセージのボディからスタックマシンのオペコードを取  
 りだし、あらかじめ規約で定められたアクションを起こす。  
   
 上の説明でわかるように、サーバはクライアントからの指示なしに、自らメッセー  
 ジを送ることはない(例外? ox\_asir の mathcap)。  
   
 {\Huge 以下、書き直してね、田村君}  \section{OpenXM の計算モデル}
   
   OpenXM 規約での計算とはメッセージを交換することである. また, OpenXM 規
   約ではクライアント・サーバモデルを採用しているので, メッセージの交換はサー
   バとクライアントの間で行なわれる. クライアントからサーバへメッセージを送
   り, クライアントがサーバからメッセージを受け取ることによって計算の結果が
   得られる. このメッセージのやりとりはクライアントの主導で行われる. つまり,
   クライアントは自由にメッセージをサーバに送付してもよいが, サーバからは自
   発的にメッセージが送付されることはない. この原理はサーバはスタックマシン
   であることで実現される. スタックマシンの構造については \ref{sec:oxsm} 節
   で述べる.
   
 % クライアントがサーバへなんらかの計算を行なわせる場合、  サーバがクライアントから受け取ったオブジェクト(つまり OX\_COMMAND でない
 % クライアントからサーバへ計算させたいデータをメッセージとして送り、  メッセージのボディ)はすべてスタックに積まれる. スタックマシンへの命令
 % そしてその結果をサーバからメッセージで受け取ることによって計算は行なわれる。  (OX\_COMMAND で識別されるメッセージのボディ)を受け取ったサーバは命令に対
 % ただし、サーバは結果の送信すらも命令されなければ行なうことはなく、  応する動作を行なう. このとき, 命令によってはスタックからオブジェクトを取
 % クライアントは結果を受け取らずにサーバに次々と  り出すことがあり, また(各数学システムでの)計算結果をスタックに積むことが
 % 計算を行なわせることも可能である。  ある. もし, 与えられたデータが正しくないなどの理由でエラーが生じた場合に
   はサーバはエラーオブジェクトをスタックに積む. 計算結果をクライアントが得
   る場合にはスタックマシンの命令 SM\_popCMO または SM\_popString をサーバ
   に送らなければならない. これらの命令を受け取ってはじめて, サーバからクラ
   イアントへメッセージが送られる.
   
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。  まとめると, クライアントがサーバへメッセージを送り,
 ただし、このままでは受け取ったメッセージに含まれるデータを  計算の結果を得るという手順は以下のようになる.
 スタックに積み上げていくだけで、サーバは計算を行なおうとはしない。  
 次いでサーバに行なわせたい動作に対応したデータを送ると、  
 初めてサーバは計算などの、なんらかの動作を行なう。  
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。  
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても  
 サーバはエラーオブジェクトをスタックに積むだけで、  
 明示されない限りエラーを返さないことに注意しなければならない。  
   
 結果が生じる動作をサーバが行なった場合、  
 サーバは動作の結果をスタックに積んでいる。  
 サーバに行なわせた動作の結果をクライアントが知りたい場合、  
 スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを  
 サーバ側へ送ればよい。  
   
 クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、  
 次のようになる。  
   
 \begin{enumerate}  \begin{enumerate}
 \item   まず、クライアントがサーバへ計算させたいデータを送る。  \item   まず, クライアントがサーバへオブジェクトを送る.
         サーバは送られてきたデータをスタックに積む。          サーバは送られてきたオブジェクトをスタックに積む.
 \item   クライアントがサーバに「計算を行なう動作に対応したデータ」を  \item   クライアントがサーバに計算の命令を送ると,
         送ると、サーバは必要なだけスタックからデータを取り出し、          サーバはあらかじめ定めれらた動作を行う.
         実行した計算の結果をスタックに積む。          一部の命令はスタックの状態を変更する.
 \item   最後に「データを取り出し送信を行なう命令に対応したデータ」を          例えば SM\_executeFunction, \\
         サーバへ送ると、サーバはスタックから計算結果の入っている          SM\_executeStringByLocalParser などの命令は,
         データを取り出し、クライアントへ送出する。          スタック上のオブジェクトから計算を行う.
           SM\_popCMO もしくは SM\_popString は,
           スタックの最上位のオブジェクトを取りだし, クライアントに送り返す.
 \end{enumerate}  \end{enumerate}
   
   
 \section{CMO のデータ構造}  \section{OpenXM スタックマシン}\label{sec:oxsm}
   
 OpenXM 間でやりとりされるメッセージを実際に作成する場合、  OpenXM 規約ではサーバはスタックマシンであると定義している. 以下, OpenXM
 CMO 形式で定義されている多倍長整数を理解しておくと、  スタックマシンと呼ぶ. この節ではOpenXM スタックマシンの構造について説明
 CMO 形式の他のデータ構造だけでなく、 OX 形式、 SM 形式のデータを  しよう.
 理解する助けになると思えるので、 CMO 形式の多倍長整数の  
 データ構造について説明する。  
   
 CMO 形式で定義されているデータは多倍長整数以外にも  まず, OpenXM 規約は通信時にやりとりされる共通のデータ形式については規定
 文字列やリスト構造などがある。どのようなデータであるかは  するが, OpenXM スタックマシンがスタックに積む, オブジェクトの構造までは
 データの先頭にあるタグを見れば判別できるようになっている。  規定しない. つまり, オブジェクトの構造は各数学システムごとに異なっている
 これはメッセージのデータの判別の仕方とおなじである。  ということである. このことは通信路からデータを受け取った際に, 各数学シス
 なお、タグは各データ毎に 32 bit の整数で表されており、  テムが固有のデータ構造に変換してからスタックに積むことを意味する. この変
 多倍長整数は 20 となっている。  換は1対1対応である必要はない.
 ここで 32 bit の整数の表現方法について説明する必要がある。  
 OpenXM ではバイト列で 32 bit の整数 20 を  
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。  
 この表現方法の違いはクライアントとサーバの最初の接続時に  
 双方の合意で決定することになっている。  
 なお、合意がない場合には  
 前者の表現方法(以後、この表現方法を network byte order と呼ぶ)を  
 使うことになっている。  
 また、負の数を表現する必要があるときには、  
 2 の補数表現を使うことになっている。  
   
 表現したい多倍長整数の絶対値を 2 進数で表した場合の桁数を $n$ と  次に OpenXM スタックマシンの命令コードについて説明する. OpenXM スタック
 したとき、次にくるデータは $[(n+31)/32]$ を 32 bit の整数となる。  マシンにおけるすべての命令は4バイトの長さを持つ. OpenXM 規約の他の規定と
 これは多倍長整数の絶対値を $2^{32}$ 進数で表した場合の桁数ととってもよい。  同様に, 4バイトのデータは32ビット整数と見なされるので, この論文でもその
 ただし、表現したい数が負の場合は $[(n+31)/32]$ を 32 bit の整数で表した値を  表記にしたがう. OpenXM スタックマシンに対する命令はスタックに積まれるこ
  2 の補数表現で負にして、正の場合と区別する。  とはない. 現在のところ, OpenXM 規約では以下の命令が定義されている.
   
 表現したい多倍長整数の絶対値が $2^{32}$ 進数で $(b_0 b_1 ... b_k)_{2^{32}}$  \begin{verbatim}
 と表せるとき、次にくるデータは $b_0$, $b_1$, $\cdots$, $b_k$ を  #define SM_popSerializedLocalObject               258
 それぞれ 32 bit の整数で表現した値となる。  #define SM_popCMO                                 262
 %以下は書き直しの必要があるかも...  #define SM_popString                              263
 なお、 GNU MP LIBRARY を用いると、  
 C 言語から多倍長整数や任意精度浮動小数を扱うことができる。  
 $b_0$, $b_1$, $\cdots$, $b_k$ をそれぞれ 32 bit 整数で表現した値は  
 この GNU MP LIBRARY で用いられている多倍長整数で使われている形式を  
 参考にして合わせてある。  
   
 ここで具体例をだそう。  #define SM_mathcap                                264
 $4294967298 = 1 \times 2^{32} + 2$ を network byte order の多倍長整数で  #define SM_pops                                   265
 表現すると、  #define SM_setName                                266
 \begin{center}  #define SM_evalName                               267
         {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}  #define SM_executeStringByLocalParser             268
 \end{center}  #define SM_executeFunction                        269
 となる。また、同じ表現方法で $-1$ を表現すると、  #define SM_beginBlock                             270
 \begin{center}  #define SM_endBlock                               271
         {\tt 00 00 00 14 ff ff ff ff 00 00 00 01}  #define SM_shutdown                               272
 \end{center}  #define SM_setMathCap                             273
 となる。  #define SM_executeStringByLocalParserInBatchMode  274
   #define SM_getsp                                  275
   #define SM_dupErrors                              276
   
   #define SM_DUMMY_sendcmo                          280
   #define SM_sync_ball                              281
   
 \section{MathCap について}  #define SM_control_kill                          1024
   #define SM_control_to_debug_mode                 1025
   #define SM_control_exit_debug_mode               1026
   #define SM_control_ping                          1027
   #define SM_control_start_watch_thread            1028
   #define SM_control_stop_watch_thread             1029
   #define SM_control_reset_connection              1030
   \end{verbatim}
   
 サーバおよびクライアント双方ともに OpenXM で規定されている  スタックマシンに対する命令の中には実行によって結果が返ってくるものがある.
 メッセージの中のデータ形式をすべて受け取れるわけではない。  結果が返ってくる命令を実行した場合, サーバはその結果をスタックに積む.
 しかも、 OpenXM 規約で規定されているデータ形式だけが  たとえば, 命令 SM\_executeStringByLocalParser は
 受渡しに使われるというわけではない。  スタックに積まれているオブジェクトを
 そこで、 OpenXM では相手側が受け取ることができるデータ形式を  サーバ側のローカル言語の文法に従った文字列とみなして計算を行なうが,
 収得する方法を用意している。  行なった計算の結果はスタックに積まれる.
   
 CMO 形式で定義されている MathCap データは  なお, 命令の実行中にエラーが起こり, 結果が得られなかった場合には,
 %理解可能なメッセージの  エラーオブジェクトがスタックに積まれる.
 受け取ることができるデータ形式を表すデータであり、  
 要求されればサーバはサーバ自身の MathCap データをスタックに積む。  
 また、クライアントから MathCap データをサーバへ送ることもでき、  
 MathCap データをサーバとクライアントの間で交換することによって、  
 お互いに相手側が受け取ることができないデータ形式で  
 メッセージを送ってしまうのを防ぐことができる。  
 なお、 MathCap データの中では CMO 形式で定義されている  
 32 bit 整数、文字列、リスト構造が使われており、  
 MathCap データに含まれている内容を理解できるためには  
 必然的にこれらも理解できる必要がある。  
   
 OpenXM 対応版の asir サーバである ox\_asir が返す MathCap を以下に示す。  
   
 %なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に  \section{CMO のデータ構造}\label{sec:cmo}
 %持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、  
 %文字列 ``string'' を {\tt "string"} 、 32 bit 整数を  
 %それに対応する 10 進数の整数で示す。  
   
 %↓手で作ったので間違えている可能性あり。  OpenXM 規約では, 数学的オブジェクトを表現する方法として CMO 形式(Common
 %%古いバージョン。差し替えの必要あり。  Mathematical Object format)を定義している. この CMO 形式にしたがったデー
 \begin{verbatim}  タは, 識別子が OX\_DATA であるようなメッセージのボディになることを想定し
 [ [199901160,"ox_asir"],  ている.
   [276,275,258,262,263,266,267,268,274  
     ,269,272,265,264,273,300,270,271],  
   [ [514,[1,2,3,4,5,2130706433,2130706434  
           ,17,19,20,21,22,24,25,26,31,27,33,60]],  
     [2144202544,[0,1]]  
   ]  
 ]  
 \end{verbatim}  
   
 <<<<<<< genkou19991125.tex  CMO 形式におけるデータ構造は次のような構造をもつ.
 この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。  
 最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。  
 %この最初の要素がまたリスト構造となっており、  
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  \begin{tabular}{|c|c|} \hline
 サーバに対する動作に対応した理解可能なデータの種類を表している。  ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\ \hline
 サーバの動作に対するデータはすべて 32 bit の整数で表しており、  \end{tabular}
 このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。  
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  ヘッダは4バイトである. ボディの長さはそれぞれのデータによって異なるが,
 理解可能なデータの形式を表している。  0でもよい.
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と  
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、  
 それぞれが一つのデータ形式についての情報となっている。  
 どのデータ形式についての情報かは最初の要素にある整数値をみれば  
 分かるようになっている。  
 この整数値は CMO 形式では 514 となっている。  
 最初のデータ形式を区別する整数値以後の要素は  
 各データ形式によってどのように使われるか定まっている。  
 CMO 形式では理解可能なデータの tag がリストの中に収まっている。  
 前節で CMO 形式では多倍長整数を表す tag が 20 であることを述べたが、  
 このリストに 20 が含まれているので、  
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  
   
 %%このリストの要素はまたリストとなっており、  メッセージと同様にヘッダは4バイト単位に管理される. すなわち, CMO ではヘッ
 %この最後の部分もまたリストとなっており、  ダは一つだけの情報を含む. この4バイトのヘッダのことをタグともいう. さて,
 %あるデータ形式で理解可能なものを表現したリストを要素としている。  CMO では, タグによってボディの論理的構造が決定する. すなわち, タグはそれ
 %{\tt [514,[1, 2, $\cdots$]]} の最初の 514 はこのリストが CMO 形式  ぞれのデータ構造と1対1に対応する識別子である. それぞれの論理的構造は
 %での理解可能なデータを表していることを示しており、  \cite{OpenXM-1999} に詳述されている. 現在の OpenXM 規約では以下の CMO が
 %その後のリストでは CMO 層で定義されているデータのうち、  定義されている.
 %理解可能なデータの tag が並んでいる。  
   
 なお、データが受け取れることと、  \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
   
 \section{セキュリティ対策}  #define CMO_INT32COEFF                 30
   #define CMO_DISTRIBUTED_POLYNOMIAL     31
   #define CMO_POLYNOMIAL_IN_ONE_VARIABLE 33
   #define CMO_RATIONAL                   34
   
 OpenXM では幾らかのセキュリティ対策を考えている。  #define CMO_64BIT_MACHINE_DOUBLE           40
 OpenXM に対応したソフトウェアをクラックしても  #define CMO_ARRAY_OF_64BIT_MACHINE_DOUBLE  41
 大した利点はないと思えるが、それは設計上の話であって、  #define CMO_128BIT_MACHINE_DOUBLE          42
 予期せぬ手段で攻撃を受けた場合にどのような事態を  #define CMO_ARRAY_OF_128BIT_MACHINE_DOUBLE 43
 招くかは想像し難い。  
   
 そこで、 OpenXM では侵入者に攻撃の機会を  #define CMO_BIGFLOAT          50
 できるだけ与えないようにしている。  #define CMO_IEEE_DOUBLE_FLOAT 51
 具体的には、接続が必要になった時のみ接続を待つようにし、  
 常に接続に関与するといったことは避けている。  
   
 しかし、これだけでは侵入者が接続を行なう一瞬のすきを  #define CMO_INDETERMINATE 60
 狙ってくる可能性もある。  #define CMO_TREE          61
 そこで接続を行なう時に、  #define CMO_LAMBDA        62
 接続を待つ port 番号をランダムに決めている。  \end{verbatim}
 こうすることで、特定の port 番号を狙って接続を行なう  
 瞬間を待つ手口を幾らか防ぐことができる。  
   
 さらにもう一段安全性を高めるために、  この中で CMO\_ERROR2, CMO\_NULL, CMO\_INT32, CMO\_DATUM, CMO\_STRING,
 接続時に 1 回だけ使用可能なパスワードを作成し、  CMO\_MATHCAP, CMO\_LIST で識別されるオブジェクトは最も基本的なオブジェ
 そのパスワードを使って認証を行なう。  クトであって, すべての OpenXM 対応システムに実装されていなければならない.
 このパスワードは一旦使用されれば無効にするので、  
 もし仮になんらかの手段でパスワードが洩れたとしても安全である。  
   
 なお、上記の port 番号とパスワードは安全な手段で送られて  これらについての解説を行う前に記法について, 少し説明しておく.
 いると仮定している。  この論文では, 大文字で CMO\_INT32 と書いた場合には, 上記で定義した識別子
 また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  を表わす. また CMO\_INT32 で識別されるオブジェクトのクラス(あるいはデー
 ことに注意しなければならない。  タ構造)を cmo\_int32 と小文字で表わすことにする.
 なぜなら、現在の実装ではサーバ、およびクライアントの動作している  
 コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。  
   
 なお、接続が確立した後のメッセージの送受信に関しては、  さて 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 expression で表記できても,
   CMO であるとは限らないことに注意してほしい.
   
 \section{他のプロジェクト}  さて, この記法のもとで cmo\_int32 を次のデータ構造を持つと定義する.
   \begin{quote}
   cmo\_int32 := (CMO\_INT32,  {\sl int32})
   \end{quote}
   同様に, cmo\_null, cmo\_string, cmo\_list, cmo\_mathcap のシンタッ
   クスは次のように定義される.
   \begin{quote}
   cmo\_null := (CMO\_NULL) \\
   cmo\_string := (CMO\_STRING, {\sl int32} $n$, {\sl string} $s$) \\
   cmo\_list := (CMO\_LIST, {\sl int32} $m$, {\sl cmo} $c_1$, $\ldots$,
   {\sl cmo} $c_m$) \\
   cmo\_mathcap := (CMO\_MATHCAP, {\sl cmo\_list})
   \end{quote}
   ただし, {\sl string}は適当な長さのバイト列を表す. $s$ のバイト長は $n$
   と一致することが要求される.
   
 他のプロジェクトについても触れておこう。  % 先ほどの, (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}
   % となる.
   
 OpenMath プロジェクトは数学的なオブジェクトを  % CMO 形式の多倍長整数は, Gnu MPライブラリ等を参考にしており,
 コンピュータ上で表現する方法を決定している。  % 符号付き絶対値表現を用いている.
 各ソフトウェア間でオブジェクトを交換する際の  % タグ以降の形式は次のようになる.
 オブジェクトの変換手順についても述べられている。  
 表現方法は一つだけでなく、 XML 表現や binary 表現などが  
 用意されている。  
 詳細は  
   
 http://www.openmath.org/omsoc/index.html A.M.Cohen  % \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}
   % となる.
   
 NetSolve  
   
 http://www.cs.utk.edu/netsolve/  \section{mathcap について}
   
   OpenXM 規約では, 通信時に用いられるメッセージの種類を各ソフトウェアが制
   限する方法を用意している. これは各ソフトウェアの実装によってはすべてのメッ
   セージをサポートするのが困難な場合があるからである. また, 各ソフトウェア
   でメッセージの種類を拡張したい場合にも有効である. この制限(あるいは拡張)
   は mathcap と呼ばれるデータ構造によって行われる. この節では mathcap のデー
   タ構造と, 具体的なメッセージの制限の手続きについて説明する.
   
 MP  では, 手続きについて説明しよう.
   
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html  第一にサーバの機能を制限するには次のようにする. クライアントが mathcap
   オブジェクトをサーバへ送ると, サーバは受け取ったmathcap をスタックに積む.
   次にクライアントが命令 SM\_setMathCap を送ると, サーバはスタックの最上位
   に積まれている mathcap オブジェクトを取り出し, mathcap で設定されていな
   いメッセージをクライアントへ送らないように制限を行う.
   
   第二にクライアントを制限するには次のようにする. クライアントがサーバに命令 \\
   SM\_mathcap を送ると, サーバは mathcap オブジェクトをスタックに積む.
   さらに命令 SM\_popCMO を送ると, サーバはスタックの最上位のオブジェクト
   (すなわち mathcap オブジェクト)をボディとするメッセージをクライアントに
   送付する. クライアントはそのオブジェクトを解析して, 制限をかける.
   
 MCP  次に mathcap のデータ構造について説明する.
   mathcap は CMO の一種であるので, すでに説明したように \\
   \begin{tabular}{|c|c|} \hline
   ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\ \hline
   \end{tabular} \\
   の構造を持ちヘッダの値は 5 である(\ref{sec:cmo} 節を参照のこと).
   ボディは cmo\_list オブジェクトでなければならない.
   
 http://horse.mcs.kent.edu/~pwang/  さて, mathcap オブジェクトのボディの cmo\_list オブジェクトは以下の条件を
   満たすことを要求される.
   
   まず, その cmo\_list オブジェクトは少なくともリスト長が 3 以上でなければ
   ならない.
   
 \section{現在提供されているソフトウェア}  \begin{quote}
   (CMO\_LIST, {\sl int32}, {\sl cmo} $A$, {\sl cmo} $B$, {\sl cmo} $C$, $\ldots$)
   \end{quote}
   
 現在 OpenXM 規格に対応しているクライアントには  第一要素 $A$ はまた cmo\_list であり, リスト長は 4 以上,
 asir, sm1, Mathematica がある。  $a_1$ は 32 ビット整数でバージョンナンバーを,
 これらのクライアントから  $a_2$, $a_3$, $a_4$ は文字列であり,
 OpenXM 規格に対応したサーバを呼び出すことができる。  それぞれシステムの名前, , HOSTTYPE を表すことになっている.
 現在 OpenXM 規約に対応しているサーバソフトウェアには、  \begin{quote}
  asir, sm1, gnuplot, Mathematica などがあり、  (CMO\_LIST, {\sl int32},
 それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。  {\sl cmo\_int32} $a_1$, {\sl cmo\_string} $a_2$, {\sl cmo\_string}
 また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の  $a_3$, {\sl cmo\_string} $a_4$, $\ldots$)
 データを変換するソフトウェアが JAVA によって実装されており、  \end{quote}
 OMproxy という名前で提供されている。  
 =======  
 この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。  
 最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。  
 %この最初の要素がまたリスト構造となっており、  
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  第二要素 $B$ の部分は次のようなリスト構造をしている.
 サーバに対する動作に対応した理解可能なデータの種類を表している。  この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて cmo\_int32 である.
 サーバの動作に対するデータはすべて 32 bit の整数で表しており、  \ref{sec:oxsm} 節で説明したが,
 このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。  スタックマシンへの命令はすべて {\sl int32} で表されていたことに注意しよ
   う. 各 $b_i$ は利用可能な命令をボディとした cmo\_int32 となっている.
   \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}
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  第三要素 $C$ は以下のようなリスト構造をしている.
 理解可能なデータの形式を表している。  \begin{quote}
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と    (CMO\_LIST, {\sl int32} $m$, \\
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、    \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}$) \\
 この整数値は CMO 形式では 514 となっている。    \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}$))
 CMO 形式では理解可能なデータのタグがリストの中に収まっている。  \end{quote}
 前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、  どの $c_{i1}$ にも cmo\_int32 が入っており,
 このリストに 20 が含まれているので、  OX\_COMMAND 以外の, 受け取れるメッセージの識別子が入っている.
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  $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 になっている.
   各要素は cmo\_int32 であり,
   受け取ることが可能な 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}
   
 なお、データが受け取れることと、  具体的な mathcap の例をあげよう.
 データの論理構造が理解できることとはまったく別物であるので  名前が ``ox\_test'', バージョンナンバーが 199911250 のサーバで,
 注意する必要がある。  PC-UNIX 上で動いていれば,
   $A$ の部分は
   \begin{quote}
   (CMO\_LIST, 4, (CMO\_INT32, $199911250$), (CMO\_STRING, 7, "ox\_test"), \\
   \ \     (CMO\_STRING, 9, "199911250"), (CMO\_STRING, 4, "i386"))
   \end{quote}
   となる.
   
   さらに, このサーバのスタックマシンが
   命令 SM\_popCMO, SM\_popString, SM\_mathcap,
   SM\_executeStringByLocalParser を利用可能であれば, $B$ の部分は
   \begin{quote}
   (CMO\_LIST, $5$,
           (CMO\_INT32, SM\_popCMO), \\
   \ \     (CMO\_INT32, SM\_popString), (CMO\_INT32, SM\_mathcap), \\
   \ \     (CMO\_INT32, SM\_executeStringByLocalParser))
   \end{quote}
   となり,
   CMO 形式の 32 ビット整数, 文字列, mathcap , リスト構造のみが
   受け取れるときには, $C$ の部分は
   \begin{quote}
     (CMO\_LIST, $1$, \\
     \ \ (CMO\_LIST, $2$, (CMO\_INT32, OX\_DATA), \\
     \ \ \ \ (CMO\_LIST, $4$, (CMO\_INT32, CMO\_INT32), \\
     \ \ \ \ \ \ (CMO\_INT32, CMO\_STRING), (CMO\_INT32, CMO\_MATHCAP), \\
     \ \ \ \ \ \ (CMO\_INT32, CMO\_LIST))))
   \end{quote}
   となる.
   
   
 \section{セキュリティ対策}  \section{セキュリティ対策}
   
 OpenXM では幾らかのセキュリティ対策を考えている。  OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している. ネットワーク
 OpenXM に対応したソフトウェアをクラックしても  によって接続される現代の多くのソフトウェアと同様, OpenXM 規約もまた通信
 大した利点はないと思えるが、それは設計上の話であって、  時のセキュリティについて注意している. 以下, このことについて説明しよう.
 予期せぬ手段で攻撃を受けた場合にどのような事態を  
 招くかは想像し難い。  
   
 そこで、 OpenXM では侵入者に攻撃の機会を  OpenXM では侵入者に攻撃の機会をできるだけ与えないようにするため,
 できるだけ与えないようにしている。  サーバは接続が必要になった時のみ起動している.
 具体的には、接続が必要になった時のみ接続を待つようにし、  
 常に接続に関与するといったことは避けている。  
   
 しかし、これだけでは侵入者が接続を行なう一瞬のすきを  しかし, これだけでは接続を行なう一瞬のすきを狙われる可能性もある.
 狙ってくる可能性もある。  そこで接続を行なう時に, 接続を行なうポート番号を毎回変えている.
 そこで接続を行なう時に、  こうすることで, 特定のポート番号を狙って接続を行なう手口を幾らか
 接続を待つ port 番号をランダムに決めている。  防ぐことができる.
 こうすることで、特定の port 番号を狙って接続を行なう  
 瞬間を待つ手口を幾らか防ぐことができる。  
   
 さらにもう一段安全性を高めるために、  さらにもう一段安全性を高めるために, 接続時に一時パスワードを
 接続時に 1 回だけ使用可能なパスワードを作成し、  クライアントが作成し, そのパスワードを使って認証を行なう.
 そのパスワードを使って認証を行なう。  このパスワードは一旦使用されれば無効にするので,
 このパスワードは一旦使用されれば無効にするので、  もし仮になんらかの手段でパスワードが洩れたとしても安全である.
 もし仮になんらかの手段でパスワードが洩れたとしても安全である。  
   
 なお、上記の port 番号とパスワードは安全な手段で送られて  %なお, 上記のポート番号とパスワードは安全な手段で送られていると仮定してい
 いると仮定している。  %る. また, 同一のコンピュータ上に悪意のあるユーザはいないと仮定しているこ
 また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  %とに注意しなければならない. なぜなら, 現在の実装ではサーバ, およびクライ
 ことに注意しなければならない。  %アントの動作しているコンピュータ上ではこの port 番号とパスワードがわかっ
 なぜなら、現在の実装ではサーバ、およびクライアントの動作している  %てしまうためである.
 コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。  
   
 なお、接続が確立した後のメッセージの送受信に関しては、  なお, 接続が確立した後のメッセージの送受信に関しては, 特に暗号化などの処
 特に暗号化などの処置が行なわれているわけではない。  置を行っているわけではない. もし必要があれば, 通信路の暗号化を行なう機能
 もし必要があれば、通信路の暗号化を行なう機能がある  があるソフトウェア ssh を使うことにしている.
 ソフトウェアを使うことを考えている。  
   
   
 \section{他のプロジェクト}  \section{他のプロジェクト}
   
 他のプロジェクトについて幾つか紹介する。  他のプロジェクトについても触れておこう.
   
 OpenMath プロジェクトは数学的なオブジェクトを  \begin{itemize}
 コンピュータ上で表現する方法を決定している。  \item OpenMath
 各ソフトウェア間でオブジェクトを交換する際の  
 オブジェクトの変換手順についても述べられている。  
 表現方法は一つだけでなく、 XML 表現や binary 表現などが  
 用意されている。  
   
 %以下、調べる必要あり。  http://www.openmath.org/omsoc/  %A.M.Cohen
 %NetSolve  
   
 %MP  数学的なオブジェクトをコンピュータ上で表現する方法を規定している.
   %各ソフトウェア間でオブジェクトを交換する際のオブジェクトの変換手順に
   %ついても定められている.
   表現方法は幾つかの段階で定められていて,
   XML 表現やバイナリ表現などが用意されている.
   
 %MCP  
   
   \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/
   
   HTTP プロトコルを用いて、リモートの計算機で計算を行なう.
   
   \end{itemize}
   
   
 \section{現在提供されているソフトウェア}  \section{現在提供されているソフトウェア}
   
 現在 OpenXM 規格に対応しているクライアントソフトウェアには  現在 OpenXM 規約に対応しているクライアントにはasir, sm1, Mathematica がある.
 asir, sm1, Mathematica がある。  これらのクライアントから OpenXM 規約に対応したサーバを呼び出すこと
 これらのクライアントソフトウェアから  ができる. 現在 OpenXM 規約に対応しているサーバソフトウェアには, asir,
 OpenXM 規格に対応したサーバを呼び出すことができる。  sm1, gnuplot, Mathematica, PHC pack などがあり,
 現在 OpenXM 規約に対応しているサーバソフトウェアには、  それぞれ ox\_asir, ox\_sm1, ox\_sm1\_gnuplot, ox\_math, ox\_sm1\_phc
  asir, sm1, gnuplot, Mathematica などがあり、  という名前で提供されている. また, OpenMath
 それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。  規約の XML 表現で表現されたオブジェクトと CMO 形式のオブジェクトを変換す
 また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の  るソフトウェアが JAVA によって実装されており, OMproxy という名前で提供さ
 データを変換するソフトウェアが JAVA によって実装されており、  れている.
 OMproxy という名前で提供されている。  
 >>>>>>> 1.30  \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}  \end{document}

Legend:
Removed from v.1.31  
changed lines
  Added in v.1.89

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>