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

Diff for /OpenXM/doc/Attic/genkou19991125.tex between version 1.41 and 1.99

version 1.41, 1999/12/22 11:58:58 version 1.99, 1999/12/26 08:20:46
Line 1 
Line 1 
 \documentclass{jarticle}  \documentclass{jarticle}
   
 \title{タイトル未定}  %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.98 1999/12/26 07:42:22 tam Exp $
 \author{  
 前川 将秀\thanks{神戸大学理学部数学科},  \usepackage{jssac}
 野呂 正行\thanks{富士通研究所},  
 小原 功任\thanks{金沢大学理学部計算科学教室}, \\  \title{OpenXM プロジェクトの現状について}
 奥谷 行央  \author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科}
 %\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻},                  \mail{okutani@math.sci.kobe-u.ac.jp}
 \thanks{神戸大学大学院自然科学研究科数学専攻},    \and  小 原 　 功 任\affil{金沢大学理学部}
 高山 信毅\thanks{神戸大学理学部数学教室},                  \mail{ohara@kappa.s.kanazawa-u.ac.jp}
 田村 恭士    \and  高 山 　 信 毅\affil{神戸大学理学部}
 %\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座}                  \mail{takayama@math.sci.kobe-u.ac.jp}
 \thanks{神戸大学大学院自然科学研究科情報メディア科学専攻}    \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}
 }  }
 \date{1999年11月25日}  \art{}
 %\pagestyle{empty}  
   
 \begin{document}  \begin{document}
 \maketitle  \maketitle
   
   
 \section{OpenXMとは}  \section{OpenXMとは}
   
 OpenXM は数学プロセス間でメッセージを交換するための規約である。数学プロ  OpenXM は数学プロセス間でメッセージを交換するための規約である.  数学プロ
 セス間でメッセージをやりとりさせることにより、ある数学プロセスから他の数  セス間でメッセージをやりとりすることにより, ある数学プロセスから他の数学
 学プロセスを呼び出して計算を行なったり、他のマシンで計算を行なわせたりす  プロセスを呼び出して計算を行なったり, 他のマシンで計算を行なわせたりする
 ることが目的である。なお、 OpenXM とは Open message eXchange protocol  ことが目的である.  なお, OpenXM とは Open message eXchange protocol for
 for Mathematics の略である。  Mathematics の略である.  OpenXM の開発の発端は野呂と高山により, asir と
 OpenXM の開発の発端は野呂と高山により、 asir と kan/sm1 を  kan/sm1 を相互に呼び出す機能を実装したことである.
 相互に呼び出す機能を実装したことである。  
 %\footnote{この段落必要?}  
   
 %発端となった asir と kan/sm1 での実装時には、  初期の実装では, 相手側のローカル言語の文法に従った文字列を送っていた.
 初期の実装では、相手側のローカル言語の文法に従った文字列を送っていた。  この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどし
 現在の OpenXM 規約では共通表現形式によるメッセージを用いている。  て, 相手側のローカル言語の文法に合わせた文字列を作成しなければならない.
 この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別して、  このローカル言語の文法に従った文字列を送る方法は, 効率的であるとはいい難
 相手側のローカル言語の文法に合わせて文字列を作成する必要がない。  いが, 使いやすいとも言える.
 しかし、ローカル言語の文法に従った文字列を送る方法も、  
 効率的であるとはいい難いが、使いやすい。  
 そのため、 OpenXM 規約では共通表現形式の中の文字列として  
 表現して送ることが可能となっている。  
   
 %OpenXM 規約独自のデータ形式である CMO 形式(Common Mathematical Object format)  現在の OpenXM 規約では共通表現形式によるメッセージを用いている.  上記の
 %以外にも、 MP や OpenMath の XML, binary 表現形式といった他の形式をも  文字列を送る方法の利点を生かすため, OpenXM 規約では共通表現形式の中の文
 %扱えるようにしてある。  字列として, ローカル言語の文法に従った文字列を用いたメッセージの交換も可
   能となっている.
   
 {\Huge TCP/IP 実装の話}  OpenXM 規約では通信の方法に自由度があるが, 現在のところは TCP/IP
   を用いた通信しか実装されていない.  \footnote{asir には MPI を用いた実装
   もある.}  そこで, この論文では TCP/IP を用いた実装に準拠して
   OpenXM の説明をする.
   
   
 \section{OpenXM の計算モデル}  \section{OpenXM のメッセージの構造}
   
 {\Huge この節では計算モデルの話をしなければいけません}  通信の方法によってメッセージの構造は変わる.  この論文では TCP/IP の場合
   についてのみ説明を行なう.
   
 OpenXM 規約での計算とはメッセージを交換することである。  OpenXM 規約で規定されているメッセージはバイトストリームとなっており, 次
 そして、そのメッセージの交換はサーバとクライアントの間で行なわれる。  のような構造になっている.
 クライアントからサーバへメッセージを送り、  \begin{center}
 サーバからクライアントがメッセージを受け取ることによって  \begin{tabular}{|c|c|}
 計算の結果が得られる。  \hline
   ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\
   \hline
   \end{tabular}
   \end{center}
   ヘッダの長さは 8 バイトであると定められている.  ボディの長さはメッセージ
   ごとに異なっているが, 長さは $0$ でもよい.
   
 サーバはスタックマシンであると仮定されており、  ヘッダは次の二つの情報を持っている.
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。  \begin{enumerate}
 ただし、OpenXM のメッセージの中にはサーバに行なわせたい動作に  \item
 対応するデータがあり、  前半の 4 バイト. メッセージの種類を表す識別子であり, タグと呼ばれる.
 このメッセージを受け取ったサーバはそれに対応する動作を  \item
 行なうことが期待されている。  後半の 4 バイト. メッセージにつけられた通し番号である.
 しかし、サーバは命令されない限り何も動作を行なおうとはしない。  \end{enumerate}
 このため、クライアントはサーバの状態を気にせずにメッセージを送り、  それぞれの 4 バイトは 32 ビット整数とみなされて扱われる.
 一旦メッセージを送付し終えた後、  
 サーバへ送ったメッセージの結果を  
 サーバから待つことなしに次の動作に移ることができる。  
   
 なお、サーバに対する動作に対応したデータは SM 形式として定義されている。  この場合に用いられる 32 ビット整数の表現方法について説明しておこう.  問
 SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む  題になるのは負数の表現とバイトオーダーの問題である.  まず, 負数を表す必
 以外の動作をしないことになっている。  要があるときには2の補数表現を使うことになっている.  次にバイトオーダーで
 つまり、 SM 形式のデータがサーバにデータを受け取る以外の動作を  あるが, OpenXM 規約は複数のバイトオーダーを許容する.  ただし一つの通信路
 行なわせる唯一のデータ形式である。  ではひとつのバイトオーダーのみが許され, 通信路の確立時に一度だけ選ばれる.
   
   現在のOpenXM 規約では, タグ(整数値)として以下のものが定義されている.
   
 \section{OpenXM のメッセージの構造}  \begin{verbatim}
   #define OX_COMMAND              513
   #define OX_DATA                 514
   #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}
   
 %{\Huge この節では構造の話をしなければいけません}  ボディの構造はメッセージの種類によって異なる.  OX\_COMMAND で識別される
   メッセージはスタックマシンへの命令であり, それ以外のメッセージは何らかの
   オブジェクトを表している.  この論文では OX\_DATA と OX\_COMMAND で識別さ
   れるメッセージについてのみ, 説明する.
   
 OpenXM で規定されているメッセージはバイトストリームであり、  既存のメッセージでは対応できない場合は, 新しい識別子を定義することで新し
 次のような構造になっている。  い種類のメッセージを作成することができる. この方法は各数学ソフトウェアの
   固有の表現を含むメッセージを作成したい場合などに有効である. 新しい識別子
   の定義方法については, \cite{OpenXM-1999} を参照すること.
   
 \begin{tabular}{|c|c|} \hline  
 ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\ \hline  
 \end{tabular}  
   
 ヘッダの長さは 8 バイトであると定められている。  \section{OpenXM の計算モデル}
 ボディの長さはメッセージごとに異なっているが、  
 長さは $0$ でもよい。  
 %なお、すべてのメッセージに ボディが必要というわけではなく、  
 %ボディのないメッセージも OpenXM 規約には存在することに  
 %注意しなければならない。  
   
 ヘッダは次の二つの情報を持っている。  OpenXM 規約での計算とはメッセージを交換することである. また, OpenXM 規
   約ではクライアント・サーバモデルを採用しているので, メッセージの交換はサー
   バとクライアントの間で行なわれる.
   \footnote{現在, 主に野呂が OpenXM の計算モデルの拡張を考えている.
   効率的分散計算のアルゴリズムの多くはサーバ同士の通信も要求する.}
   クライアントからサーバへメッセージを送
   り, クライアントがサーバからメッセージを受け取ることによって計算の結果が
   得られる. このメッセージのやりとりはクライアントの主導で行われる. つまり,
   クライアントは自由にメッセージをサーバに送付してもよいが, サーバからは自
   発的にメッセージが送付されることはない. この原理はサーバはスタックマシン
   であることで実現される. スタックマシンの構造については \ref{sec:oxsm} 節
   で述べる.
   
   サーバがクライアントから受け取ったオブジェクト(つまり OX\_COMMAND でない
   メッセージのボディ)はすべてスタックに積まれる. スタックマシンへの命令
   (OX\_COMMAND で識別されるメッセージのボディ)を受け取ったサーバは命令に対
   応する動作を行なう. このとき, 命令によってはスタックからオブジェクトを取
   り出すことがあり, また(各数学システムでの)計算結果をスタックに積むことが
   ある. もし, 与えられたデータが正しくないなどの理由でエラーが生じた場合に
   はサーバはエラーオブジェクトをスタックに積む. 計算結果をクライアントが得
   る場合にはスタックマシンの命令 SM\_popCMO または SM\_popString をサーバ
   に送らなければならない. これらの命令を受け取ってはじめて, サーバからクラ
   イアントへメッセージが送られる.
   
   まとめると, クライアントがサーバへメッセージを送り, 計算の結果を得るとい
   う手順は以下のようになる.
   
 \begin{enumerate}  \begin{enumerate}
 \item   前半の 4 バイトにある、メッセージの種類を表わす識別子。  \item
         タグと呼ばれる。  まず, クライアントがサーバへオブジェクトを送る.  サーバは送られてきたオ
 \item   後半の 4 バイトにある、メッセージにつけられた通し番号。  ブジェクトをスタックに積む.
   \item
   クライアントがサーバに計算の命令を送ると, サーバはあらかじめ定めれらた動
   作を行う.  一部の命令はスタックの状態を変更する.  例えば
   SM\_executeFunction, \\ SM\_executeStringByLocalParser などの命令は, ス
   タック上のオブジェクトから計算を行う.  SM\_popCMO もしくは SM\_popString
   は, スタックの最上位のオブジェクトを取りだし, クライアントに送り返す.
 \end{enumerate}  \end{enumerate}
 それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。  
 この場合に用いられる整数の表現方法の説明については後述するが、  
 基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、  
 またその選択は通信路の確立時に一度だけなされることに注意しなければならない。  
   
 %{\Huge 以下、書き直し}  
   
 ボディの中身は各データ形式によって  \section{OpenXM スタックマシン}\label{sec:oxsm}
 それぞれ独立に決められるようになっている。  
 もし、 OpenXM 規約でまだ定義されていないデータ形式を使いたい場合は、  
 メッセージのヘッダのタグをまだ使われてない整数値に設定し、  
 ボディの部分にデータを埋め込めばよい。  
 なお、このような用途にも使えるように、  
 タグにはシステム固有の表現用に推奨されている整数の範囲がある。  
   
   OpenXM 規約ではサーバはスタックマシンであると定義している. 以下, OpenXM
   スタックマシンと呼ぶ. この節ではOpenXM スタックマシンの構造について説明
   しよう.
   
 \section{OpenXM の計算の進行方法}  まず, OpenXM 規約は通信時にやりとりされる共通のデータ形式については規定
   するが, OpenXM スタックマシンがスタックに積む, オブジェクトの構造までは
   規定しない. つまり, オブジェクトの構造は各数学システムごとに異なっている
   ということである. このことは通信路からデータを受け取った際に, 各数学シス
   テムが固有のデータ構造に変換してからスタックに積むことを意味する. この変
   換は1対1対応である必要はない.
   しかし, 変換方法はあいまいさがないように文書化されている必要がある.
   後述する OpenMath ではこの文章を phrase dictionary と呼んでいる.
   
 OpenXM における計算とはメッセージの交換のことである。  次に OpenXM スタックマシンの命令コードについて説明する. OpenXM スタック
 既に計算モデルの節で説明したが、  マシンにおけるすべての命令は4バイトの長さを持つ. OpenXM 規約の他の規定と
 OpenXM はサーバ・クライアントモデルを採用していて、  同様に, 4バイトのデータは32ビット整数と見なされるので, この論文でもその
 サーバはスタックマシンの構造を持つ。  表記にしたがう. OpenXM スタックマシンに対する命令はスタックに積まれるこ
 サーバが行うのは基本的に次の事柄に限られる。  とはない. 現在のところ, OpenXM 規約では以下の命令が定義されている.
 クライアントからメッセージを受け取るとサーバは、  
 まずメッセージの識別子を調べ、 SM 形式のデータでなければスタックに積む。  
 SM 形式のデータであればメッセージのボディから  
 スタックマシンのオペコードを取りだし、  
 あらかじめ規約で定められた動作を行なう。  
   
 %上の説明でわかるように、  \begin{verbatim}
 サーバはクライアントからの指示なしに、  #define SM_popSerializedLocalObject               258
 自らメッセージを送らないことに注意しなければならない。  #define SM_popCMO                                 262
 %(例外? ox\_asir の mathcap)。  #define SM_popString                              263
   
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。  #define SM_mathcap                                264
 次いでサーバに SM 形式のデータを送ると、  #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
 サーバに行なわせた動作の結果をクライアントが知りたい場合、  
 スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを  
 サーバ側へ送ればよい。  
   
 {\Huge 以下、書き直し}  #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}
   
 クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、  スタックマシンに対する命令の中には実行によって結果が返ってくるものがある.
 次のようになる。  結果が返ってくる命令を実行した場合, サーバはその結果をスタックに積む.
   たとえば, 命令 SM\_executeStringByLocalParser はスタックに積まれているオ
   ブジェクトをサーバ側のローカル言語の文法に従った文字列とみなして計算を行
   なうが, 行なった計算の結果はスタックに積まれる.
   
 \begin{enumerate}  なお, 命令の実行中にエラーが起こり, 結果が得られなかった場合には,
 \item   まず、クライアントがサーバへ計算させたいデータを送る。  エラーオブジェクトがスタックに積まれる.
         サーバは送られてきたデータをスタックに積む。  
 \item   クライアントがサーバに「計算を行なう動作に対応したデータ」を  
         送ると、サーバは必要なだけスタックからデータを取り出し、  
         実行した計算の結果をスタックに積む。  
 \item   最後に「データを取り出し送信を行なう命令に対応したデータ」を  
         サーバへ送ると、サーバはスタックから計算結果の入っている  
         データを取り出し、クライアントへ送出する。  
 \end{enumerate}  
   
   \section{CMO のデータ構造}\label{sec:cmo}
   
 \section{CMO のデータ構造}  OpenXM 規約では, 数学的オブジェクトを表現する方法として CMO 形式(Common
   Mathematical Object format)を定義している. この CMO 形式にしたがったデー
   タは, 識別子が OX\_DATA であるようなメッセージのボディになることを想定し
   ている.
   
 OpenXM 間でやりとりされるメッセージを実際に作成する場合、  CMO 形式におけるデータ構造は次のような構造をもつ.
 CMO 形式で定義されている多倍長整数を理解しておくと、  \begin{center}
 CMO 形式の他のデータ構造だけでなく、 OX 形式、 SM 形式のデータを  \begin{tabular}{|c|c|}
 理解する助けになると思えるので、 CMO 形式の多倍長整数の  \hline
 データ構造について説明する。  ヘッダ        & \hspace{10mm} ボディ \hspace{10mm} \\
   \hline
   \end{tabular}
   \end{center}
   ヘッダは4バイトである. ボディの長さはそれぞれのデータによって異なるが,
   0でもよい.
   
 CMO 形式で定義されているデータは多倍長整数以外にも  メッセージと同様にヘッダは4バイト単位に管理される. すなわち, CMO ではヘッ
 文字列やリスト構造などがある。どのようなデータであるかは  ダは一つだけの情報を含む. この4バイトのヘッダのことをタグともいう. さて,
 データの先頭にあるタグを見れば判別できるようになっている。  CMO では, タグによってボディの論理的構造が決定する. すなわち, タグはそれ
 これはメッセージのデータの判別の仕方とおなじである。  ぞれのデータ構造と1対1に対応する識別子である. それぞれの論理的構造は
 なお、タグは各データ毎に 32 bit の整数で表されており、  \cite{OpenXM-1999} に詳述されている. 現在の OpenXM 規約では以下の CMO が
 多倍長整数は 20 となっている。  定義されている.
 ここで 32 bit の整数の表現方法について説明する必要がある。  
 OpenXM ではバイト列で 32 bit の整数 20 を  
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。  
 この表現方法の違いはクライアントとサーバの最初の接続時に  
 双方の合意で決定することになっている。  
 なお、合意がない場合には  
 前者の表現方法(以後、この表現方法を network byte order と呼ぶ)を  
 使うことになっている。  
 また、負の数を表現する必要があるときには、  
 2 の補数表現を使うことになっている。  
   
 表現したい多倍長整数の絶対値を 2 進数で表した場合の桁数を $n$ と  \begin{verbatim}
 したとき、次にくるデータは $[(n+31)/32]$ を 32 bit の整数となる。  #define CMO_ERROR2                         0x7f000002
 これは多倍長整数の絶対値を $2^{32}$ 進数で表した場合の桁数ととってもよい。  #define CMO_NULL                           1
 ただし、表現したい数が負の場合は $[(n+31)/32]$ を 32 bit の整数で表した値を  #define CMO_INT32                          2
  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}
   
 表現したい多倍長整数の絶対値が $2^{32}$ 進数で $(b_0 b_1 ... b_k)_{2^{32}}$  この中で CMO\_ERROR2, CMO\_NULL, CMO\_INT32, CMO\_DATUM, CMO\_STRING,
 と表せるとき、次にくるデータは $b_0$, $b_1$, $\cdots$, $b_k$ を  CMO\_MATHCAP, CMO\_LIST で識別されるオブジェクトは最も基本的なオブジェ
 それぞれ 32 bit の整数で表現した値となる。  クトであって, すべての OpenXM 対応システムに実装されていなければならない.
 %以下は書き直しの必要があるかも...  
 なお、 GNU MP LIBRARY を用いると、  
 C 言語から多倍長整数や任意精度浮動小数を扱うことができる。  
 $b_0$, $b_1$, $\cdots$, $b_k$ をそれぞれ 32 bit 整数で表現した値は  
 この GNU MP LIBRARY で用いられている多倍長整数で使われている形式を  
 参考にして合わせてある。  
   
 ここで具体例をだそう。  これらについての解説を行う前に記法について, 少し説明しておく.  この論文
 $4294967298 = 1 \times 2^{32} + 2$ を network byte order の多倍長整数で  では, 大文字で CMO\_INT32 と書いた場合には, 上記で定義した識別子を表す.
 表現すると、  また CMO\_INT32 で識別されるオブジェクトのクラス(あるいはデータ構造) を
 \begin{center}  cmo\_int32 と小文字で表すことにする.
         {\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}  
 となる。  
   
   さて cmo を表現するための一つの記法を導入する. この記法は CMO expression
   と呼ばれている. その正確な形式的定義は \cite{OpenXM-1999} を参照すること.
   
 \section{MathCap について}  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 は単なる表
   記法であることに特に注意してほしい.
   
 サーバおよびクライアント双方ともに OpenXM で規定されている  さて, この記法のもとで cmo\_int32 を次のデータ構造であると定義する.
 メッセージの中のデータ形式をすべて受け取れるわけではない。  \begin{quote}
 しかも、 OpenXM 規約で規定されているデータ形式だけが  cmo\_int32 := (CMO\_INT32,  {\sl int32})
 受渡しに使われるというわけではない。  \end{quote}
 そこで、 OpenXM では相手側が受け取ることができるデータ形式を  同様に, 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 形式で定義されている MathCap データは  \section{mathcap について}
 %理解可能なメッセージの  
 受け取ることができるデータ形式を表すデータであり、  
 要求されればサーバはサーバ自身の MathCap データをスタックに積む。  
 また、クライアントから MathCap データをサーバへ送ることもでき、  
 MathCap データをサーバとクライアントの間で交換することによって、  
 お互いに相手側が受け取ることができないデータ形式で  
 メッセージを送ってしまうのを防ぐことができる。  
 なお、 MathCap データの中では CMO 形式で定義されている  
 32 bit 整数、文字列、リスト構造が使われており、  
 MathCap データに含まれている内容を理解できるためには  
 必然的にこれらも理解できる必要がある。  
   
 OpenXM 対応版の asir サーバである ox\_asir が返す MathCap を以下に示す。  OpenXM 規約では, 通信時に用いられるメッセージの種類を各ソフトウェアが制
   限する方法を用意している. これは各ソフトウェアの実装によってはすべてのメッ
   セージをサポートするのが困難な場合があるからである. また, 各ソフトウェア
   でメッセージの種類を拡張したい場合にも有効である. この制限(あるいは拡張)
   は mathcap と呼ばれるデータ構造によって行われる. この節では mathcap のデー
   タ構造と, 具体的なメッセージの制限の手続きについて説明する.
   
 %なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に  まず, 手続きについて説明しよう.
 %持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、  
 %文字列 ``string'' を {\tt "string"} 、 32 bit 整数を  
 %それに対応する 10 進数の整数で示す。  
   
 %↓手で作ったので間違えている可能性あり。  第一にサーバの機能を制限するには次のようにする. クライアントが mathcap
 %%古いバージョン。差し替えの必要あり。  オブジェクトをサーバへ送ると, サーバは受け取ったmathcap をスタックに積む.
 \begin{verbatim}  次にクライアントが命令 SM\_setMathCap を送ると, サーバはスタックの最上位
 [ [199901160,"ox_asir"],  に積まれている mathcap オブジェクトを取り出し, mathcap で設定されていな
   [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"]} の部分にはサーバの情報が入っている。  SM\_mathcap を送ると, サーバは mathcap オブジェクトをスタックに積む.
 %この最初の要素がまたリスト構造となっており、  さらに命令 SM\_popCMO を送ると, サーバはスタックの最上位のオブジェクト
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  (すなわち mathcap オブジェクト)をボディとするメッセージをクライアントに
   送付する. クライアントはそのオブジェクトを解析して, 制限をかける.
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  次に mathcap のデータ構造について説明する.
 サーバに対する動作に対応した理解可能なデータの種類を表している。  mathcap は cmo の一種であるので, すでに説明したように
 サーバの動作に対するデータはすべて 32 bit の整数で表しており、  \begin{quote}
 このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。  cmo\_mathcap := (CMO\_MATHCAP, {\sl cmo\_list})
   \end{quote}
   の構造をもつ(\ref{sec:cmo} 節を参照のこと).
   ボディは cmo\_list オブジェクトでなければならない.
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  さて, mathcap オブジェクトのボディの cmo\_list オブジェクトは以下の条件
 理解可能なデータの形式を表している。  を満たすことを要求される.  まず, その cmo\_list オブジェクトは少なくとも
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と  リスト長が 3 以上でなければならない.
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、  \begin{quote}
 それぞれが一つのデータ形式についての情報となっている。  (CMO\_LIST, {\sl int32}, {\sl cmo} $a$, {\sl cmo} $b$, {\sl cmo} $c$, $\ldots$)
 どのデータ形式についての情報かは最初の要素にある整数値をみれば  \end{quote}
 分かるようになっている。  
 この整数値は CMO 形式では 514 となっている。  
 最初のデータ形式を区別する整数値以後の要素は  
 各データ形式によってどのように使われるか定まっている。  
 CMO 形式では理解可能なデータのタグがリストの中に収まっている。  
 前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、  
 このリストに 20 が含まれているので、  
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  
   
 %%このリストの要素はまたリストとなっており、  第一要素 $a$ はまた cmo\_list であり, リスト長は 4 以上, $a_1$ は
 %この最後の部分もまたリストとなっており、  cmo\_int32 でバージョンを表す. $a_2$, $a_3$, $a_4$ は cmo\_string であり,
 %あるデータ形式で理解可能なものを表現したリストを要素としている。  それぞれ数学システムの名前, バージョン, HOSTTYPE を表すことになっている.
 %{\tt [514,[1, 2, $\cdots$]]} の最初の 514 はこのリストが CMO 形式  \begin{quote}
 %での理解可能なデータを表していることを示しており、  (CMO\_LIST, {\sl int32},
 %その後のリストでは CMO 層で定義されているデータのうち、  {\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 スタックマシンを制御するために
 データの論理構造が理解できることとはまったく別物であるので  用いられる.  各 $b_i$ は cmo\_int32 であり, ボディはスタックマシンの命令
 注意する必要がある。  コードである.  \ref{sec:oxsm} 節で説明したが, スタックマシンへの命令はす
   べて {\sl int32} で表されていたことに注意しよう.
   \begin{quote}
   (CMO\_LIST, {\sl int32} $n$,
   {\sl cmo\_int32} $b_1$, $\ldots$, {\sl cmo\_int32} $b_n$)
   \end{quote}
   
   第三要素 $c$ は以下のような cmo\_list であり, オブジェクトの送受信を制御
   するために用いられる.  送受信の制御はメッセージの種類ごとに行われる.
   \begin{quote}
   (CMO\_LIST, {\sl int32} $m$, {\sl cmo\_list} $\ell_1$, $\ldots$,
   {\sl cmo\_list} $\ell_m$)
   \end{quote}
   各 $\ell_i$ が制御のための情報を表す.  どの $\ell_i$ も一つ以上の要素を
   持っており, 第一要素は必ず cmo\_int32 となっていなければならない.  これ
   は制御すべきメッセージの識別子を入れるためである.
   
 \section{セキュリティ対策}  各 $\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}
   
 OpenXM では幾らかのセキュリティ対策を考えている。  具体的な mathcap の例をあげよう.  名前が ``ox\_test'', バージョンナンバー
 OpenXM に対応したソフトウェアをクラックしても  が 199911250 のサーバで, Linux 上で動いており, このサーバのスタックマシ
 大した利点はないと思えるが、それは設計上の話であって、  ンが命令 SM\_popCMO, SM\_popString, SM\_mathcap,
 予期せぬ手段で攻撃を受けた場合にどのような事態を  SM\_executeStringByLocalParser を利用可能で, かつ オブジェクトを
 招くかは想像し難い。  cmo\_int32, cmo\_string, cmo\_mathcap, cmo\_list のみに制限したいときの
   mathcap は
   \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}
   になる.
   
 そこで、 OpenXM では侵入者に攻撃の機会を  
 できるだけ与えないようにしている。  
 具体的には、接続が必要になった時のみ接続を待つようにし、  
 常に接続に関与するといったことは避けている。  
   
 しかし、これだけでは侵入者が接続を行なう一瞬のすきを  \section{セキュリティ対策}
 狙ってくる可能性もある。  
 そこで接続を行なう時に、  
 接続を待つポート番号をランダムに決めている。  
 こうすることで、特定のポート番号を狙って接続を行なう  
 瞬間を待つ手口を幾らか防ぐことができる。  
   
 さらにもう一段安全性を高めるために、  OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している. ネットワーク
 接続時に 1 回だけ使用可能なパスワードを作成し、  によって接続される現代の多くのソフトウェアと同様, OpenXM 規約もまた通信
 そのパスワードを使って認証を行なう。  時のセキュリティについて注意している. 以下, このことについて説明しよう.
 このパスワードは一旦使用されれば無効にするので、  
 もし仮になんらかの手段でパスワードが洩れたとしても安全である。  
   
 なお、上記のポート番号とパスワードは安全な手段で送られて  第一に OpenXM では侵入者に攻撃の機会をできるだけ与えないようにするため,
 いると仮定している。  サーバは接続が必要になった時のみ起動している.  しかし, これだけでは接続
 また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  を行なう一瞬のすきを狙われる可能性もある.  そこで接続を行なう時に, 接続
 ことに注意しなければならない。  を行なうポート番号を毎回変えている.  こうすることで, 特定のポート番号を
 なぜなら、現在の実装ではサーバ、およびクライアントの動作している  狙って接続を行なう手口を防ぐことができる.
 コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。  
   
 なお、接続が確立した後のメッセージの送受信に関しては、  さらにもう一段安全性を高めるために, 接続時に一時パスワードをクライアント
 特に暗号化などの処置が行なわれているわけではない。  が作成し, そのパスワードを使って認証を行なう.  このパスワードは一旦使用
 もし必要があれば、通信路の暗号化を行なう機能がある  されれば無効になるので, もし仮になんらかの手段でパスワードが洩れたとして
 ソフトウェアを使うことを考えている。  も安全である.
   
   なお, メッセージ自体には特に暗号化などの処置を行っていないので, そのまま
   ではパケット盗聴などを受ける可能性がある.  現在の実装では, 必要ならば
   ssh を利用して対応している.
   
 \section{他のプロジェクト}  
   
 他のプロジェクトについても触れておこう。  \section{OpenXM 以外のプロジェクト}
   
 OpenMath プロジェクトは数学的なオブジェクトを  OpenXM 以外にも数式処理システム間の通信を目指したプロジェクトは存在する.
 コンピュータ上で表現する方法を決定している。  ここでは他のプロジェクトについても触れておこう.
 各ソフトウェア間でオブジェクトを交換する際の  
 オブジェクトの変換手順についても述べられている。  
 表現方法は一つだけでなく、 XML 表現や binary 表現などが  
 用意されている。  
 詳細は  
   
 http://www.openmath.org/omsoc/index.html A.M.Cohen  \begin{itemize}
   \item ESPRIT OpenMath Project
   
   http://www.openmath.org/omsoc/
   
 以下は書いてる途中。  数学的対象の SGML 的表記の標準化を目指した大規模なプロジェクト. 異なる種
   類の数式処理システムの間で情報を交換するときに, OpenMath で定義された表
   現を利用することができる.  実際の情報交換の手続きはこのプロジェクトの
   範囲外であるが, 別のプロジェクトとして,
   例えば MCP を用いた実装があり, GAP と Axiom の間で通信が行わ
   れている.  OpenXM は OpenMath 規約の phrasedictionary と同じアイデアを用
   いている.
   
 NetSolve  \item NetSolve
   
 http://www.cs.utk.edu/netsolve/  http://www.cs.utk.edu/netsolve/
   
   NetSolve はクライアント・サーバ型の分散システムであり, 単なる計算システ
   ム以上のものを目指している.  クライアントは必要に応じて, サーバを呼び出
   して計算をさせる.  NetSolve の特徴は, サーバの呼び出しに Agent というソ
   フトウェアを介在させることである.  Agent は呼び出し先などを決定するデー
   タベース的役割を果たす.  また Agent によって負荷分散が可能になる.  現在
   の NetSolve は RPC を基礎にして実装されている.
   
 MP  \item MP
   
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html  http://symbolicnet.mcs.kent.edu/SN/areas/protocols/mp.html
   
   科学技術計算を行なうソフトウェア間で数学的なデータを効率的に交換させるこ
   とを目的としたプロトコルを作成している. 木構造を用いて, 簡単かつ柔軟なも
   のを目指しており, データの表現方法や交換方法によらずにソフトウェアを作る
   ことができるようにするのが目標である.  現在すでに, C 言語で利用可能なラ
   イブラリが提供されている.
   
 MCP  \item MCP (Mathematical Computation Protocol)
   
 http://horse.mcs.kent.edu/~pwang/  http://horse.mcs.kent.edu/\~{}pwang/
   
   数学的な計算を行なうための HTTP に似たプロトコル.  クライアント・サー
   バモデルを採用しており, ピアツーピアのストリームコネクションを行なう.
   数学的なオブジェクトをどのように表現するかについては規定されておらず,
   MP や MathML で定められた方法で表現することが考えられる.
   すでに OpenMath の XML 表現を用いた実装が存在する.
   この場合 MCP によって送信されるデータは, 本文に OpenMath 形式で数式を記
   述したテキストである.
   
   \end{itemize}
   
   
 \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}
   \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.41  
changed lines
  Added in v.1.99
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>