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

Diff for /OpenXM/doc/Attic/genkou19991125.tex between version 1.59 and 1.119

version 1.59, 1999/12/23 16:03:24 version 1.119, 2000/01/05 14:12:05
Line 1 
Line 1 
 \documentclass{jarticle}  \documentclass{jarticle}
   
 %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.58 1999/12/23 14:57:46 tam Exp $  %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.118 2000/01/04 11:43:37 tam Exp $
   
 \usepackage{jssac}  \usepackage{jssac}
 \title{タイのトル}  
 \title{  
 意味もない修飾過剰な語句は排除しましょう。  
 TCP/IP ソケットとか、TCP/IP 実装とか何のこっちゃと思いました。  
 }  
   
 \author{前 川 将 秀\affil{神戸大学理学部}  \title{OpenXM プロジェクトの現状について}
                 \mail{maekawa@math.sci.kobe-u.ac.jp}  \author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科}
   \and  野 呂 正 行\affil{富士通研究所}  
                 \mail{noro@para.flab.fujitsu.co.jp}  
   \and  小 原 功 任\affil{金沢大学理学部}  
                 \mail{ohara@kappa.s.kanazawa-u.ac.jp}  
   \and  奥 谷 行 央\affil{神戸大学大学院自然科学研究科}  
                 \mail{okutani@math.sci.kobe-u.ac.jp}                  \mail{okutani@math.sci.kobe-u.ac.jp}
   \and  高 山 信 毅\affil{神戸大学理学部}    \and  小 原 　 功 任\affil{金沢大学理学部}
                   \mail{ohara@kappa.s.kanazawa-u.ac.jp}
     \and  高 山 　 信 毅\affil{神戸大学理学部}
                 \mail{takayama@math.sci.kobe-u.ac.jp}                  \mail{takayama@math.sci.kobe-u.ac.jp}
   \and  田 村  恭 士\affil{神戸大学大学院自然科学研究科}    \and  田 村 　 恭 士\affil{神戸大学大学院自然科学研究科}
                 \mail{tamura@math.sci.kobe-u.ac.jp}                  \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{}  \art{}
   
Line 29  TCP/IP ソケットとか、TCP/IP 実装とか何のこっちゃと思い
Line 25  TCP/IP ソケットとか、TCP/IP 実装とか何のこっちゃと思い
   
 \section{OpenXMとは}  \section{OpenXMとは}
   
 OpenXM は数学プロセス間でメッセージを交換するための規約である。  OpenXM は数学プロセス間でメッセージを交換するための規約である.  数学プロ
 数学プロセス間でメッセージをやりとりすることにより、  セス間でメッセージをやりとりすることにより, ある数学プロセスから他の数学
 ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり、  プロセスを呼び出して計算を行なったり, 他のマシンで計算を行なわせたりする
 他のマシンで計算を行なわせたりすることが目的である。  ことが目的である.  なお, OpenXM とは Open message eXchange protocol for
 なお、 OpenXM とは Open message eXchange protocol for Mathematics の略である。  Mathematics の略である.  OpenXM の開発の発端は野呂と高山により, asir と
 OpenXM の開発の発端は野呂と高山により、  kan/sm1 を相互に呼び出す機能を実装したことである.
 asir と kan/sm1 を相互に呼び出す機能を実装したことである。  
   
 {\bf\large 以下の説明がなぜ必要なのかは全然分からないけれど、}  初期の実装では, 相手側のローカル言語の文法に従った文字列を送っていた.
 初期の実装では、相手側のローカル言語の文法に従った文字列を送っていた。こ  この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどし
 の方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして、  て, 相手側のローカル言語の文法に合わせた文字列を作成しなければならない.
 相手側のローカル言語の文法に合わせた文字列を作成しなければならない。この  このローカル言語の文法に従った文字列を送る方法は, 効率的であるとはいい難
 ローカル言語の文法に従った文字列を送る方法は、効率的であるとはいい難いが、  いが, 使いやすいとも言える.
 使いやすいとも言える。  
   
 現在の OpenXM 規約では共通表現形式によるメッセージを用いている。上記の文  現在の OpenXM 規約では共通表現形式によるメッセージを用いている.  上記の
 字列を送る方法の利点を生かすため、OpenXM 規約では共通表現形式の中の文字  文字列を送る方法の利点を生かすため, OpenXM 規約では共通表現形式の中の文
 列として、ローカル言語の文法に従った文字列を用いたメッセージの交換も可能  字列として, ローカル言語の文法に従った文字列を用いたメッセージの交換も可
 となっている。{\large\bf しかし、こんな細かいことをここで説明しなければ  能となっている.
 ならない理由がやっぱり分からないなぁ。構成的におかしいと思うけどなぁ。意  
 味不明。}  
   
 OpenXM 規約では通信の方法に幾らかの自由度があるが、現在のところは TCP/IP  OpenXM 規約では通信の方法に自由度があるが, 現在のところは TCP/IP を用い
 を用いた通信しか実装されていない。そこで、この論文では具体的な実装は  た通信しか実装されていない.
 TCP/IP を用いていると仮定する。  \footnote{ただし asir には MPI を用いた実装もある.}
   そこで, この論文では TCP/IP を用いた実装に準拠してOpenXM の説明をする.
   
 \section{OpenXM のメッセージの構造}  
   
 OpenXM で規定されている TCP/IP 実装によるメッセージはバイトストリームと  \section{OpenXM のメッセージの構造}\label{sec:messages}
 なっており、次のような構造になっている。  
   
   通信の方法によってメッセージの構造は変わる.  この論文では TCP/IP の場合
   についてのみ説明を行なう.
   
   OpenXM 規約で規定されているメッセージはバイトストリームとなっており, 次
   のような構造になっている.
   \begin{center}
 \begin{tabular}{|c|c|}  \begin{tabular}{|c|c|}
 \hline  \hline
 ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\  ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\
 \hline  \hline
 \end{tabular}  \end{tabular}
   \end{center}
   ヘッダの長さは 8 バイトであると定められている.  ボディの長さはメッセージ
   ごとに異なっているが, 長さは $0$ でもよい.
   
 ヘッダの長さは 8 バイトであると定められている。  ヘッダは次の二つの情報を持っている.
 ボディの長さはメッセージごとに異なっているが、  
 長さは $0$ でもよい。  
   
 ヘッダは次の二つの情報を持っている。  
 \begin{enumerate}  \begin{enumerate}
 \item   前半の 4 バイト。メッセージの種類を表わす識別子であり、  \item
         タグと呼ばれる。  前半の 4 バイト.  メッセージの種類を表す識別子であり, タグと呼ばれる.
 \item   後半の 4 バイト。メッセージにつけられた通し番号である。  \item
   後半の 4 バイト.  メッセージにつけられた通し番号である.
 \end{enumerate}  \end{enumerate}
 それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。  それぞれの 4 バイトは 32 ビット整数とみなされて扱われる.
 この場合に用いられる整数の表現方法の説明については後述するが、  
 基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、  
 またその選択は通信路の確立時に一度だけなされることに注意しなければならない。  
 現在のOpenXM 規約では、タグ(整数値)として  
 以下のものが定義されている。  
   
   この場合に用いられる 32 ビット整数の表現方法について説明しておこう.  問
   題になるのは負数の表現とバイトオーダーの問題である.  まず, 負数を表す必
   要があるときには2の補数表現を使うことになっている.  次にバイトオーダーで
   あるが, OpenXM 規約は複数のバイトオーダーを許容する.  ただし一つの通信路
   ではひとつのバイトオーダーのみが許され, 通信路の確立時に一度だけ選ばれる.
   
   現在のOpenXM 規約では, タグ(整数値)として以下のものが定義されている.
   
 \begin{verbatim}  \begin{verbatim}
 #define OX_COMMAND              513  #define OX_COMMAND               513
 #define OX_DATA                 514  #define OX_DATA                  514
 #define OX_SYNC_BALL            515  #define OX_SYNC_BALL             515
 #define OX_DATA_WITH_LENGTH     521  #define OX_DATA_WITH_LENGTH      521
 #define OX_DATA_OPENMATH_XML    523  #define OX_DATA_OPENMATH_XML     523
 #define OX_DATA_OPENMATH_BINARY 524  #define OX_DATA_OPENMATH_BINARY  524
 #define OX_DATA_MP              525  #define OX_DATA_MP               525
 \end{verbatim}  \end{verbatim}
   
 ボディの構造はメッセージの種類によって異なる。  ボディの構造はメッセージの種類によって異なる.  OX\_COMMAND で識別される
 この論文では、OX\_DATA と OX\_COMMAND で識別されるメッセージについてのみ、  メッセージはスタックマシンへの命令であり, それ以外のメッセージは何らかの
 説明する。  オブジェクトを表している.  この論文では OX\_DATA と OX\_COMMAND で識別さ
   れるメッセージについてのみ, 説明する.
   
 既存のメッセージでは対応できない場合は、新しい識別子を定義することで新し  既存のメッセージでは対応できない場合は, 新しい識別子を定義することで新し
 い種類のメッセージを作成することができる。この方法は各数学ソフトウェアの  い種類のメッセージを作成することができる.  この方法は各数学ソフトウェア
 固有の表現を含むメッセージを作成したい場合などに有効である。新しい識別子  の固有の表現を含むメッセージを作成したい場合などに有効である.  新しい識
 の定義方法については、\cite{OpenXM-1999} を参照すること。  別子の定義方法については, \cite{OpenXM-1999} を参照すること.
   
   
 \section{OpenXM の計算モデル}  \section{OpenXM の計算モデル}
   
 %{\Huge この節では計算モデルの話をしなければいけません}  OpenXM 規約での計算とはメッセージを交換することである.  また, OpenXM 規
   約ではクライアント・サーバモデルを採用しているので, メッセージの交換はサー
   バとクライアントの間で行なわれる.
   \footnote{現在, 主に野呂が OpenXM の計算モデルの拡張を考えている.  効率
   的な分散計算のアルゴリズムの多くはサーバ同士の通信も要求するからである.}
   クライアントからサーバへメッセージを送り, クライアントがサーバからメッセー
   ジを受け取ることによって計算の結果が得られる.  このメッセージのやりとり
   はクライアントの主導で行われる.  つまり, クライアントは自由にメッセージ
   をサーバに送付してもよいが, サーバからは自発的にメッセージが送付されるこ
   とはない.  この原理はサーバはスタックマシンであることで実現される.  スタッ
   クマシンの構造については \ref{sec:oxsm} 節で述べる.
   
 OpenXM 規約での計算とはメッセージを交換することである。また、 OpenXM 規  サーバがクライアントから受け取ったオブジェクト(つまり OX\_COMMAND でない
 約ではクライアント・サーバモデルを採用しているので、メッセージの交換はサー  メッセージのボディ)はすべてスタックに積まれる.  スタックマシンへの命令
 バとクライアントの間で行なわれる。クライアントからサーバへメッセージを送  (OX\_COMMAND で識別されるメッセージのボディ)を受け取ったサーバは命令に対
 り、クライアントがサーバからメッセージを受け取ることによって計算の結果が  応する動作を行なう.  このとき, 命令によってはスタックからオブジェクトを
 得られる。  取り出すことがあり, また(各数学システムでの)計算結果をスタックに積むこと
   がある.  もし, 与えられたデータが正しくないなどの理由でエラーが生じた場
   合にはサーバはエラーオブジェクトをスタックに積む.  計算結果をクライアン
   トが得る場合にはスタックマシンの命令 SM\_popCMO または SM\_popString を
   サーバに送らなければならない.  これらの命令を受け取ってはじめて, サーバ
   からクライアントへメッセージが送られる.
   
 サーバはスタックマシンである。サーバがクライアントから受け取ったメッセー  まとめると, クライアントがサーバへメッセージを送り, 計算の結果を得るとい
 ジは、タグが OX\_COMMAND でなければすべてスタックに積まれる。タグが  う手順は以下のようになる.
 OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、このメッ  
 セージを受け取ったサーバはそれに対応する動作を行なうことが期待されている。  
 サーバはメッセージを受け取らない限り、自ら何か動作をおこなわない。  
   
 {\large\bf 意味不明な書き方だけど、}  
   
 これは毎回サーバへメッセージを送る  
 たびに、いつもサーバからのメッセージをクライアントが待つ必要がないことを  
 意味する。このため、クライアントはサーバの状態を気にせずにメッセージを送  
 り、一旦メッセージを送付し終えた後、サーバへ送ったメッセージの結果をサー  
 バから待つことなしに次の動作に移ることができる。  
   
 \section{OpenXM の計算の進行方法}  
   
 前の節と重複しているのでもう少しちゃんと考えて欲しいのだけれど、  
   
 サーバが行うのは基本的に次の事柄だけである。  
 クライアントからメッセージを受け取ると、  
 サーバはまずメッセージの識別子を調べ、  
 タグが OX\_COMMAND のメッセージでなければスタックに積む。  
 タグが OX\_COMMAND のメッセージであればメッセージのボディから  
 スタックマシンの命令コードを取りだし、  
 あらかじめ規約で定められた動作を行なう。  
   
 上の説明でわかるように、  
 サーバはクライアントからの指示なしに、  
 自らメッセージを送らないことに注意する必要がある。  
 %(例外? ox\_asir の mathcap)。  
   
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれている。  
 次いでサーバにスタックマシンへの命令を送ると、  
 初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。  
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。  
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても  
 サーバはエラーオブジェクトをスタックに積むだけで、  
 明示されない限りエラーをクライアントへ返さないことに注意しなければならない。  
   
 結果が生じる動作をサーバが行なった場合、  
 サーバは動作の結果をスタックに積む。  
 サーバに行なわせた動作の結果をクライアントが知りたい場合、  
 スタックからデータを取り出し送信を行なう命令をサーバ側へ送ればよい。  
   
 %{\Huge 以下、書き直し}  
   
 クライアントがサーバへメッセージを送り、  
 計算の結果を得るという手順を追っていくと次のようになる。  
   
 \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 形式(Common Mathematical Object format)を定義している。  スタックマシンと呼ぶ.  この節ではOpenXM スタックマシンの構造について説明
 この CMO 形式を使ってメッセージを送るには、  しよう.
 タグを OX\_DATA にすればよい。  
 CMO 形式におけるメッセージのボディ部分について以下で説明するが、  
 %OpenXM 規約で定義されているメッセージを実際に作成する場合、  
 CMO 形式で定義されている多倍長整数を理解しておくと、  
 CMO 形式の他のデータ構造だけでなく、  
 OpenXM 規約で定義されている様々なデータ構造を理解する助けになると思えるので、  
 ここでは CMO 形式の多倍長整数のデータ構造についてのみ説明する。  
   
 CMO 形式で定義されているデータは多倍長整数以外にも  まず, OpenXM 規約は通信時にやりとりされる共通のデータ形式については規定
 文字列やリスト構造などがある。どのようなデータであるかは  するが, OpenXM スタックマシンがスタックに積む, オブジェクトの構造までは
 データの先頭にある(メッセージの識別子とは別にある)タグを見れば  規定しない.  つまり, オブジェクトの構造は各数学システムごとに異なってい
 判別できるようになっている。  るということである.  このことは通信路からデータを受け取った際に, 各数学
 これはメッセージの種類の判別の仕方とおなじである。  システムが固有のデータ構造に変換してからスタックに積むことを意味する.
 なお、タグは各データ毎に 32 bit の整数で表されており、  この変換は1対1対応である必要はない.  もちろん, 恣意的に変換してよいわけ
 多倍長整数は 20 となっている。  ではなく, 数学システムごとに変換方法をあらかじめ定めておく必要がある.
 よく使われると思われる CMO 形式のタグをあげておく。  このような共通のデータ形式と各システムでの固有のデータ形式との変換の問題
   は OpenXM に限ったことではない.  OpenMath (\ref{sec:other} 節を参照のこ
   と) ではこの変換を行うソフトウェアを Phrasebook と呼んでいる.
   
   次に OpenXM スタックマシンの命令コードについて説明する.  OpenXM スタック
   マシンにおけるすべての命令は 4 バイトの長さを持つ.  OpenXM 規約の他の規
   定と同様に, 4 バイトのデータは32ビット整数と見なされるので, この論文でも
   その表記にしたがう.  OpenXM スタックマシンに対する命令はスタックに積まれ
   ることはない.  現在のところ, OpenXM 規約では以下の命令が定義されている.
   
 \begin{verbatim}  \begin{verbatim}
 #define CMO_INT32    2 /* 32 ビット整数 */  #define SM_popSerializedLocalObject               258
 #define CMO_STRING   4 /* 文字列        */  #define SM_popCMO                                 262
 #define CMO_MATHCAP  5 /* mathcap(後述) */  #define SM_popString                              263
 #define CMO_LIST    17 /* リスト構造    */  #define SM_mathcap                                264
 #define CMO_ZZ      20 /* 多倍長整数    */  #define SM_pops                                   265
   #define SM_setName                                266
   #define SM_evalName                               267
   #define SM_executeStringByLocalParser             268
   #define SM_executeFunction                        269
   #define SM_beginBlock                             270
   #define SM_endBlock                               271
   #define SM_shutdown                               272
   #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
   #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}  \end{verbatim}
   
 ここで TCP/IP 実装における 32 bit の整数の  スタックマシンに対する命令の中には実行によって結果が返ってくるものがある.
 表現方法について説明する必要がある。  結果が返ってくる命令を実行した場合, サーバはその結果をスタックに積む.
 OpenXM 規約の TCP/IP 実装ではバイトストリームで 32 bit の整数 20 を  たとえば, 命令 SM\_executeStringByLocalParser はスタックに積まれているオ
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。  ブジェクトをサーバ側のローカル言語の文法に従った文字列とみなして計算を行
 この表現方法の違いはクライアントとサーバの最初の接続時に  なうが, 行なった計算の結果はスタックに積まれる.
 双方の合意で決定することになっている。  
 なお、合意がない場合には前者の表現方法  
 (以後、この表現方法をネットワークバイトオーダーと呼ぶ)を  
 使うことになっている。  
 また、負の数を表現する必要があるときには、  
 2 の補数表現を使うことになっている。  
   
 CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、  なお, 命令の実行中にエラーが起こり, 結果が得られなかった場合には,
 符合付き絶対値表現を用いている。  エラーオブジェクトがスタックに積まれる.
 タグ以降の形式は次のようになる。  
   
 \begin{tabular}{|c|c|c|c|c|} \hline  \section{CMO のデータ構造}\label{sec:cmo}
 $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline  
 \end{tabular}  
   
 ここで、 1 つの枠は 4 バイトを表し、  OpenXM 規約では, 数学的オブジェクトを表現する方法として CMO 形式(Common
 $f$ は符合付き 32 ビット整数を、  Mathematical Object format)を定義している.  この CMO 形式にしたがったデー
 $b_0$, $b_1$, $\cdots$, $b_{n-1}$ は符合なし 32 ビット整数を表している。  タは, 識別子が OX\_DATA であるようなメッセージのボディになることを想定し
 さらに、 $|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.    \]  
 である。  
   
 ここで具体例をだそう。  CMO 形式におけるデータ構造は次のような構造をもつ.
 $4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の  
 ネットワークバイトオーダー、多倍長整数で表現すると、  
 \begin{center}  \begin{center}
         {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}  \begin{tabular}{|c|c|}
   \hline
   ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\
   \hline
   \end{tabular}
 \end{center}  \end{center}
 となる。また、同じ表現方法で $-1$ を表現すると、  ヘッダは4バイトである.  ボディの長さはそれぞれのデータによって異なるが,
 \begin{center}  0でもよい.
         {\tt 00 00 00 14 ff ff ff ff 00 00 00 01}  
 \end{center}  
 となる。  
   
   メッセージと同様にヘッダは4バイト単位に管理される.  すなわち, CMO では
   ヘッダは一つだけの情報を含む.  この4バイトのヘッダのことをタグともいう.
   さて, CMO では, タグによってボディの論理的構造が決定する.  すなわち, タ
   グはそれぞれのデータ構造と1対1に対応する識別子である.  それぞれの論理的
   構造は\cite{OpenXM-1999} に詳述されている.  現在の OpenXM 規約では以下の
   CMO が定義されている.
   
 \section{mathcap について}  \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_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}
   
 OpenXM 規約では、通信時に用いられるメッセージの種類を  この中で CMO\_ERROR2, CMO\_NULL, CMO\_INT32, CMO\_DATUM, CMO\_STRING,
 各ソフトウェアが制限する方法を用意している。  CMO\_MATHCAP, CMO\_LIST で識別されるオブジェクトは最も基本的なオブジェ
 これは各ソフトウェアの実装によってはすべてのメッセージを  クトであって, すべての OpenXM 対応システムに実装されていなければならない.
 サポートするのが困難な場合があるからである。  
 また、各ソフトウェアでメッセージの種類を拡張したい場合にも有効である。  
 この制限(あるいは拡張)は CMO 形式で定義されている mathcap と  
 呼ばれるデータ構造によって行われる。  
 この節では mathcap のデータ構造と、  
 具体的なメッセージの制限の手続きについて説明する。  
   
 まず、手続きについて説明しよう。  これらについての解説を行う前に記法について, 少し説明しておく.  この論文
 クライアント側の mathcap をサーバへ送ると、  では, 大文字で CMO\_INT32 と書いた場合には, 上記で定義した識別子を表す.
 すでに説明したように、サーバは受け取った mathcap をスタックに積み上げる。  また CMO\_INT32 で識別されるオブジェクトのクラス(あるいはデータ構造) を
 次にクライアントはスタックマシンへの命令をサーバへ送ることにより、  cmo\_int32 と小文字で表すことにする.
 サーバはスタックに積まれている mathcap を取り出し、  
 mathcap で設定されていないメッセージをクライアント側へ  
 送らないように設定する。  
 サーバ側の mathcap が欲しい場合には以下のようにする。  
 クライアントがスタックマシンへの命令コードにより要求すると、  
 サーバはサーバ自身の mathcap をスタックに積む。  
 さらにクライアントがサーバに命令を送れば、  
 サーバはスタックにある mathcap をクライアントへ送出する。  
 このようにしてクライアントはサーバ側の mathcap を受け取るわけである。  
   
 次に mathcap のデータ構造について説明する。  さて cmo を表現するための一つの記法を導入する.  この記法は CMO expression
   と呼ばれている.  その正確な形式的定義は \cite{OpenXM-1999} を参照すること.
   
 mathcap は以下のような 3 つの要素からなるリストを持っている。  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 は単なる表
   記法であることに特に注意してほしい.
   
 \[      \begin{tabular}{|c|c|c|} \hline  さて, この記法のもとで cmo\_int32 を次のデータ構造であると定義する.
         $A$ & $B$ & $C$ \\ \hline  \begin{quote}
         \end{tabular}   \]  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$
   と一致することが要求される.
   
 最初の要素 $A$ の部分は以下のようなリスト構造をしており、  \section{mathcap について}
 $a_1$ は 32 ビット整数でバージョンナンバーを、  
 $a_2$ は文字列でシステムの名前を表すことになっている。  
   
 \[      \begin{tabular}{|c|c|} \hline  OpenXM 規約では, 通信時に用いられるメッセージの種類を各ソフトウェアが制
         $a_1$ & $a_2$   \\ \hline  限する方法を用意している.  これは各ソフトウェアの実装によってはすべての
         \end{tabular}   \]  メッセージをサポートするのが困難な場合があるからである.  また, 各ソフト
   ウェアでメッセージの種類を拡張したい場合にも有効である.  この制限(あるい
   は拡張) は mathcap と呼ばれるデータ構造によって行われる.  この節では
   mathcap のデータ構造と, 具体的なメッセージの制限の手続きについて説明する.
   
 2 番目の要素 $B$ の部分は次のようなリスト構造をしている。  まず, 手続きについて説明しよう.
 この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて 32 ビットの整数である。  
 スタックマシンへの命令はすべて 32 ビットの整数で表しており、  
 各 $b_i$ は利用可能な命令に対応する 32 ビットの整数となっている。  
   
 \[      \begin{tabular}{|c|c|c|c|} \hline  第一にサーバの機能を制限するには次のようにする.  クライアントが mathcap
         $b_1$ & $b_2$ & $\cdots$ & $b_n$        \\ \hline  オブジェクトをサーバへ送ると, サーバは受け取ったmathcap をスタックに積む.
         \end{tabular}   \]  次にクライアントが命令 SM\_setMathCap を送ると, サーバはスタックの最上位
   に積まれている mathcap オブジェクトを取り出し, mathcap で設定されていな
   いメッセージをクライアントへ送らないように制限を行う.
   
 3 番目の要素 $C$ は以下のようなリスト構造をしている。  第二にクライアントを制限するには次のようにする.  まず, クライアントがサー
   バに命令 SM\_mathcap を送ると, サーバは mathcap オブジェクトをスタックに
   積む.  さらに命令 SM\_popCMO を送ると, サーバはスタックの最上位のオブジェ
   クト(すなわち mathcap オブジェクト)をボディとするメッセージをクライアン
   トに送付する.  クライアントはそのオブジェクトを解析して, 制限をかける.
   
 \[  \overbrace{  次に mathcap のデータ構造について説明する.
         \begin{tabular}{|c|c|c|c|} \hline  mathcap は cmo の一種であるので, すでに説明したように
         $c_1$ & $c_2$ & $\cdots$ & $c_n$        \\ \hline  \begin{quote}
         \end{tabular}  cmo\_mathcap := (CMO\_MATHCAP, {\sl cmo\_list})
    }^{C}        \]  \end{quote}
   の構造をもつ(\ref{sec:cmo} 節を参照のこと).
   ボディは cmo\_list オブジェクトでなければならない.
   
 %$n$ は OX\_COMMAND 以外の受け取れるメッセージのタグの種類の数に等しい。  さて, mathcap オブジェクトのボディの cmo\_list オブジェクトは以下の条件
 %要素数は 1 でももちろん構わない。  を満たすことを要求される.  まず, その cmo\_list オブジェクトは少なくとも
 各 $c_i$ もまた以下のようなリスト構造となっており、  リスト長が 3 以上でなければならない.
 どの $c_i$ も最初の要素が 32 ビットの整数となっている。  \begin{quote}
   (CMO\_LIST, {\sl int32}, {\sl cmo} $a$, {\sl cmo} $b$, {\sl cmo} $c$, $\ldots$)
   \end{quote}
   
 \[  \overbrace{  第一要素 $a$ はまた cmo\_list であり, リスト長は 4 以上, $a_1$ は
         \begin{tabular}{|c|c|c|c|c|} \hline  cmo\_int32 でバージョンを表す.  $a_2$, $a_3$, $a_4$ は cmo\_string であ
         $c_{i1}$ (32 ビットの整数) & $c_{i2}$ & $c_{i3}$ &  り, それぞれ数学システムの名前, バージョン, HOSTTYPE を表すことになって
                 $\cdots$ & $c_{im}$     \\ \hline  いる.
         \end{tabular}  \begin{quote}
    }^{c_i}      \]  (CMO\_LIST, {\sl int32},
   {\sl cmo\_int32} $a_1$, {\sl cmo\_string} $a_2$, {\sl cmo\_string}
   $a_3$, {\sl cmo\_string} $a_4$, $\ldots$)
   \end{quote}
   
 このリストの最初の整数値は受け取れるメッセージのタグが入っている。  第二要素 $b$ も cmo\_list であり, OpenXM スタックマシンを制御するために
 $c_{i2}$ 以降については最初の $c_{i1}$ の値によって異なっている。  用いられる.  各 $b_i$ は cmo\_int32 であり, ボディはスタックマシンの命令
 ここでは、最初の要素が OX\_DATA の場合についてのみ説明する。  コードである.  \ref{sec:oxsm} 節で説明したが, スタックマシンへの命令はす
 この OX\_DATA の場合、 $m=2$ である。  べて {\sl int32} で表されていたことに注意しよう.
 $c_{i1}$ にはもちろんのこと、 OX\_DATA が入っており、  \begin{quote}
 $c_{i2}$ は以下のようなリスト構造になっている。  (CMO\_LIST, {\sl int32} $n$,
   {\sl cmo\_int32} $b_1$, $\ldots$, {\sl cmo\_int32} $b_n$)
   \end{quote}
   
 \[  \overbrace{  第三要素 $c$ は以下のような cmo\_list であり, オブジェクトの送受信を制御
         \begin{tabular}{|c|c|c|c|c|} \hline  するために用いられる.  送受信の制御はメッセージの種類ごとに行われる.
         $c_{i21}$ & $c_{i22}$ & $\cdots$ & $c_{i2l}$    \\ \hline  \begin{quote}
         \end{tabular}  (CMO\_LIST, {\sl int32} $m$, {\sl cmo\_list} $\ell_1$, $\ldots$,
    }^{c_{i2}}   \]  {\sl cmo\_list} $\ell_m$)
   \end{quote}
   各 $\ell_i$ が制御のための情報を表す.  どの $\ell_i$ も一つ以上の要素を
   持っており, 第一要素は必ず cmo\_int32 となっていなければならない.  これ
   は制御すべきメッセージの識別子を入れるためである.
   
   各 $\ell_i$ の構造はメッセージの種類によって異なる.  ここでは, OX\_DATA
   の場合についてのみ説明する.  第一要素が OX\_DATA の場合, リスト $\ell_i$
   は以下のような構造となっている.  各 $c_i$ は cmo\_int32 であり, そのボディ
   は CMO の識別子である.  $c_i$ で指示された CMO のみが送受信することを許
   される.
   \begin{quote}
   (CMO\_LIST, 2, (CMO\_INT32, OX\_DATA), \\
   \ \ (CMO\_LIST, {\sl int32} $k$, {\sl cmo\_int32} $c_1$,
   $\ldots$, {\sl cmo\_int32} $c_k$))
   \end{quote}
   
 具体的な mathcap の例をあげる。  具体的な mathcap の例をあげよう.  名前が ``ox\_test'', バージョンナンバー
   が 199911250 のサーバで, Linux 上で動いており, このサーバのスタックマシ
   ンが命令 SM\_popCMO, SM\_popString, SM\_mathcap,
   SM\_executeStringByLocalParser を利用可能で, かつ オブジェクトを
   cmo\_int32, cmo\_string, cmo\_mathcap, cmo\_list のみに制限したいときの
   mathcap は
 \begin{quote}  \begin{quote}
 説明。説明。説明。説明。説明。  (CMO\_MATHCAP, (CMO\_LIST, 3, \\
 説明。説明。説明。説明。説明。  $\quad$ (CMO\_LIST, 4, (CMO\_INT32, $199911250$), (CMO\_STRING, 7, ``ox\_test''), \\
 説明。説明。説明。説明。説明。  $\qquad$ (CMO\_STRING, 9, ``199911250''), (CMO\_STRING, 4, ``i386'')) \\
 説明。説明。説明。説明。説明。  $\quad$ (CMO\_LIST, $5$, (CMO\_INT32, SM\_popCMO), \\
   $\qquad$ (CMO\_INT32, SM\_popString), (CMO\_INT32, SM\_mathcap), \\
   $\qquad$ (CMO\_INT32, SM\_executeStringByLocalParser)) \\
   $\quad$ (CMO\_LIST, $1$, (CMO\_LIST, $2$, (CMO\_INT32, OX\_DATA), \\
   $\qquad$ (CMO\_LIST, $4$, (CMO\_INT32, CMO\_INT32), \\
   $\qquad\quad$ (CMO\_INT32, CMO\_STRING), (CMO\_INT32, CMO\_MATHCAP), \\
   $\qquad\quad$ (CMO\_INT32, CMO\_LIST))))))
 \end{quote}  \end{quote}
   になる.
   
   
 {\large\bf これより以降は意味不明で私にはよく分かりませんでしたので、  \section{セキュリティ対策}
 たぶん読者も分からないでしょう}  
   
 なお、 mathcap データの中では CMO 形式で定義されている  OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している.  したがって
 32 bit 整数、文字列、リスト構造が使われており、  ネットワークによって接続される現代の多くのソフトウェアと同様, OpenXM 規
 mathcap データに含まれている内容を理解できるためには  約もまた通信時のセキュリティについて注意している.  以下, このことについ
 必然的にこれらも理解できる必要がある  て説明しよう.
 (ってことは CMO 形式のところでこれらを  
 説明しなければならないってことです)。  
   
 OpenXM 対応版の asir サーバである ox\_asir が返す mathcap を以下に示す。  第一に OpenXM では侵入者に攻撃の機会をできるだけ与えないようにするため,
   サーバは接続が必要になった時のみ起動している.  しかし, これだけでは接続
   を行なう一瞬のすきを狙われる可能性もある.  そこで接続を行なう時に, 接続
   を行なうポート番号を毎回変えている.  こうすることで, 特定のポート番号を
   狙って接続を行なう手口を防ぐことができる.
   
 なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に  さらにもう一段安全性を高めるために, 接続時に一時パスワードをクライアント
 持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、  が作成し, そのパスワードを使って認証を行なう.  このパスワードは一旦使用
 文字列 ``string'' を {\tt "string"} 、 32 bit 整数を  されれば無効になるので, もし仮になんらかの手段でパスワードが洩れたとして
 それに対応する 10 進数の整数で示す。  も安全である.
   
 %↓手で作ったので間違えている可能性あり。  なお, メッセージ自体には特に暗号化などの処置を行っていないので, そのまま
 %%古いバージョン。差し替えの必要あり。  ではパケット盗聴などを受ける可能性がある.  現在の実装では, 必要ならば
 \begin{verbatim}  ssh を利用して対応している.
 [ [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}  
   
 この mathcap データのリスト構造は大きく分けて 3 つの部分に分かれる。  
 最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。  
 %この最初の要素がまたリスト構造となっており、  
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  \section{OpenXM 以外のプロジェクト}\label{sec:other}
 スタックマシンに対する命令のうち、利用可能な命令の種類を表している。  
 スタックマシンへの命令はすべて 32 ビットの整数で表しており、  
 このリストは利用可能な命令に対応する 32 ビットの整数のリストとなっている。  
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  OpenXM 以外にも数式処理システム間の通信や数学データの共通表現を目指した
 理解可能なデータの形式を表している。  プロジェクトは存在する.  ここでは他のプロジェクトについても触れておこう.
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と  
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、  
 それぞれが一つのデータ形式についての情報となっている。  
 どのデータ形式についての情報かは最初の要素にある整数値をみれば  
 分かるようになっている。  
 この整数値は CMO 形式では 514 となっている。  
 最初のデータ形式を区別する整数値以後の要素は  
 各データ形式によってどのように使われるか定まっている。  
 CMO 形式では理解可能なデータのタグがリストの中に収まっている。  
 前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、  
 このリストに 20 が含まれているので、  
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  
   
 なお、データが受け取れることと、  \begin{itemize}
 データの論理構造が理解できることとはまったく別物であるので  \item ESPRIT OpenMath Project
 注意する必要がある。  
   
   http://www.openmath.org/omsoc/
   
 \section{セキュリティ対策}  数学的対象の SGML 的表記の標準化を目指した大規模なプロジェクト.  このプ
   ロジェクトでは数学データを数学的意味を保ったままで如何に表現すべきかとい
   う問題を追求している.  したがって既存の表現, 例えば \TeX による数式の表
   現と OpenMath による数式の表現とでは, 本質的に意味が異なる.  OpenMath で
   定義された表現は, 異なる種類の数式処理システムの間で情報を交換するときに
   利用することができる.  しかしながら, 数学システム同士の通信, 例えばある
   数学システムから別の数学システムを呼び出して計算させる方法などは, このプ
   ロジェクトの対象外である. OpenXM における共通データ形式と数学システム固
   有のオブジェクトとの変換は OpenMath 規約の Phrasebook と同じアイデアを用
   いている.
   
 OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している規約である。  % ここは書かなくてもいいように思えてきたので削除しました。
 ネットワークによって接続される現代の多くのソフトウェアと同様、  %OpenXM 規約の CMO 形式の定義は OpenMath 規約の content dictionary の概念
 OpenXM 規約もまた通信時のセキュリティについて注意している。  %に似ている(もちろん OpenMath の方がもっと大掛かりで厳密な規定である).
 以下、このことについて説明しよう。  
   
 {\large\bf 意味不明なことを書いているが、}  
   
 侵入者に攻撃の機会をできるだけ与えないようするた  \item NetSolve
 めに、接続が必要になった時のみ接続を待つようにし、  
 常に接続に関与するといったことは避けている(やっぱり意味不明である)。  
   
 また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、  http://www.cs.utk.edu/netsolve/
 接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい  
 るのかはやっぱり不明であるが)。  
 さらにもう一段安全性を高めるために、  
 接続時に 1 回だけ使用可能なパスワードを作成し、  
 そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ  
 ているのかが不明だけど)。  
 このパスワードは一旦使用されれば無効にするので、  
 もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。  
   
 %なお、上記のポート番号とパスワードは安全な手段で送られて  NetSolve はクライアント・サーバ型の分散システムであり, 単なる計算システ
 %いると仮定している。  ム以上のものを目指している.  クライアントは必要に応じて, サーバを呼び出
 %また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  して計算をさせる.  NetSolve の特徴は, サーバの呼び出しに Agent というソ
 %ことに注意しなければならない。  フトウェアを介在させることである.  Agent は呼び出し先などを決定するデー
 %なぜなら、現在の実装ではサーバ、およびクライアントの動作している  タベース的役割を果たす.  また Agent によって負荷分散が可能になる.  現在
 %コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。  の NetSolve は RPC を基礎にして実装されている.
   
 なお、接続が確立した後のメッセージの送受信に関しては、  
 特に暗号化などの処置を行っているわけではない。  
 もし必要があれば、通信路の暗号化を行なう機能がある  
 ソフトウェア ssh を使うことを考えている。  
   
 \section{他のプロジェクト}  \item MP (Multi Project)
   
 他のプロジェクトについても触れておこう。  http://symbolicnet.mcs.kent.edu/SN/areas/protocols/mp.html
   
 OpenMath プロジェクトは数学的なオブジェクトを  数学的なデータの共通表現を提供するプロジェクト.  MP の主な関心は, この
 コンピュータ上で表現する方法を決定している。  共通表現の最適化である.  数学システム間で, 命令を送信したりデータを受
 各ソフトウェア間でオブジェクトを交換する際の  け渡す仕組み(control integration)は, このプロジェクトの対象外である.
 オブジェクトの変換手順についても述べられている。  MP は既存の control integration に対して補完的役割を果たす.
 表現方法は一つだけでなく、 XML 表現や binary 表現などが  
 用意されている。  
 詳細は  
   
 http://www.openmath.org/omsoc/index.html A.M.Cohen  MP では数式を構文木の一種(annotated syntax tree)と捉える.  annotated
   syntax tree には数学的な意味を保ったまま表現されているという特徴がある
   (この点は OpenMath と似ている).  MP が提供する共通表現とは, この構文木の
   バイナリエンコーディング, つまりバイト列での表現のことである.  MP の定義
   する表現ではバイト列の長さが最適化されている.  また, バイトオーダーの選
   択も可能である(\ref{sec:messages} 節参照のこと).
   
   このプロジェクトでは C 言語および GNU Common Lisp で実装を行なっている.
   C 言語による実装(MP-C ライブラリ)は上記のウェブページから収得可能である.
   このライブラリを用いて通信を行なうには, なんらかの control integration
   が必要である.  control integration としては, ソケット, MPI, PVM などが利
   用できる.
   
 以下は書いてる途中。  
   
 NetSolve  \item MCP (Mathematical Computation Protocol)
   
 http://www.cs.utk.edu/netsolve/  http://horse.mcs.kent.edu/\~{}pwang/
   
   HTTP に似せた数学的な計算を行なうためのプロトコル.
   MCP は主に control integration を規定しており,
   クライアント・サーバ型の通信を行なう.
   MCP のメッセージはヘッダとボディから構成されている.
   ヘッダはテキストであり, 最初に現れる空行でヘッダとボディは
   区切られている.
   ボディの形式は固定ではなく,
   ヘッダを見ればボディの形式が分かるようになっている.
   
 MP  数式はボディに記述されて送られるが,
   このプロトコルでは数学的オブジェクトの表現方法についての規定はなく,
   そのため, オブジェクトの表現には MP や OpenMath で定められたものを
   使用することが考えられている.
   実際, 数式の表現に OpenMath 規約の XML 表現を用いた実装があり,
   GAP と Axiom の間で通信が行なわれている.
   この場合, MCP によって送信されるメッセージは
   ボディに OpenMath 形式で数式を記述したテキストである.
   
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html  \end{itemize}
   
   
 MCP  
   
 http://horse.mcs.kent.edu/~pwang/  
   
   
 \section{現在提供されているソフトウェア}  \section{現在提供されているソフトウェア}
   
 現在 OpenXM 規格に対応しているクライアントには  現在 OpenXM 規約に対応しているクライアントにはasir, sm1, Mathematica が
 asir, sm1, Mathematica がある。  ある.  これらのクライアントから OpenXM 規約に対応したサーバを呼び出すこ
 これらのクライアントから  とができる.  また OpenXM 規約に対応しているサーバには, asir, sm1,
 OpenXM 規格に対応したサーバを呼び出すことができる。  Mathematica, gnuplot, PHC pack などがあり, それぞれ ox\_asir, ox\_sm1,
 現在 OpenXM 規約に対応しているサーバソフトウェアには、  ox\_math, ox\_sm1\_gnuplot, ox\_sm1\_phc という名前で提供されている.
  asir, sm1, gnuplot, Mathematica などがあり、  さらに OpenMath 規約の XML 表現で表現されたオブジェクトと CMO 形式のオブ
 それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。  ジェクトを相互変換するソフトウェアが JAVA によって実装されており,
 また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の  OMproxy という名前で提供されている.
 データを変換するソフトウェアが JAVA によって実装されており、  
 OMproxy という名前で提供されている。  
   
 \begin{thebibliography}{99}  \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}  \bibitem{OpenXM-1999}
 野呂正行, 高山信毅:  野呂正行, 高山信毅:
 {Open XM の設計と実装 --- Open message eXchange protocol for Mathematics},  {Open XM の設計と実装
   --- Open message eXchange protocol for Mathematics},
 1999/11/22  1999/11/22
 \bibitem{Ohara-Takayama-Noro-1999}  
 小原功任, 高山信毅, 野呂正行:  
 {Open asir 入門}, 1999, 数式処理, Vol 7, No 2, 2--17. (ISBN4-87243-086-7, SEG 出版, Tokyo).  
 \end{thebibliography}  \end{thebibliography}
   
 \end{document}  \end{document}
Legend:
Removed from v.1.59  
changed lines
  Added in v.1.119
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>