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

Diff for /OpenXM/doc/Attic/genkou19991125.tex between version 1.39 and 1.68

version 1.39, 1999/12/21 20:02:51 version 1.68, 1999/12/24 08:56:45
Line 1 
Line 1 
 \documentclass{jarticle}  \documentclass{jarticle}
   
 \title{タイトル未定}  %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.67 1999/12/24 08:08:48 tam Exp $
 \author{  
 前川 将秀\thanks{神戸大学理学部数学科},  \usepackage{jssac}
 野呂 正行\thanks{富士通研究所},  \title{
 小原 功任\thanks{金沢大学理学部計算科学科}, \\  1. 意味もない修飾過剰な語句は排除しましょう。\\
 奥谷 幸夫  2. 姓と名の間の2バイトの空白は何か理由があるの?
 %\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻},  (jssac の規約だっけ)\\
 \thanks{神戸大学大学院自然科学研究科数学専攻},  3. せっかく fill しているのをいじらないでくれ。
 高山 信毅\thanks{神戸大学理学部数学教室},  
 田村 恭士  
 %\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座}  
 \thanks{神戸大学大学院自然科学研究科情報メディア科学専攻}  
 }  }
 \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 を用いた通信しか実装されていない。
   そこで、この論文では具体的な実装は TCP/IP を用いていると仮定する。
   
 {\Huge この節では計算モデルの話をしなければいけません}  
   
 OpenXM 規約での計算とはメッセージを交換することである。  
 そして、そのメッセージの交換はサーバとクライアントの間で行なわれる。  
 クライアントからサーバへメッセージを送り、  
 サーバからクライアントがメッセージを受け取ることによって  
 計算の結果が得られる。  
   
 サーバはスタックマシンであると仮定されており、  
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。  
 ただし、OpenXM のメッセージの中にはサーバに行なわせたい動作に  
 対応するデータがあり、  
 このメッセージを受け取ったサーバはそれに対応する動作を  
 行なうことが期待されている。  
 しかし、サーバは命令されない限り何も動作を行なおうとはしない。  
 このため、クライアントはサーバの状態を気にせずにメッセージを送り、  
 一旦メッセージを送付し終えた後、  
 サーバへ送ったメッセージの結果を  
 サーバから待つことなしに次の動作に移ることができる。  
   
 なお、サーバに対する動作に対応したデータは SM 形式として定義されている。  
 SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む  
 以外の動作をしないことになっている。  
 つまり、 SM 形式のデータがサーバにデータを受け取る以外の動作を  
 行なわせる唯一のデータ形式である。  
   
   
 \section{OpenXM のメッセージの構造}  \section{OpenXM のメッセージの構造}
   
 %{\Huge この節では構造の話をしなければいけません}  通信の方法によってメッセージの構造は変わる。
   前節で仮定したとおり、この論文では TCP/IP の場合についてのみ説明を行なう。
   
 OpenXM で規定されているメッセージはバイトストリームであり、  OpenXM 規約で規定されているメッセージはバイトストリームとなっており、
 次のような構造になっている。  次のような構造になっている。
   
 \begin{tabular}{|c|c|} \hline  \begin{tabular}{|c|c|}
 ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\ \hline  \hline
   ヘッダ  & \hspace{10mm} ボディ \hspace{10mm} \\
   \hline
 \end{tabular}  \end{tabular}
   
 ヘッダの長さは 8 バイトであると定められている。  ヘッダの長さは 8 バイトであると定められている。
 ボディの長さはメッセージごとに異なっているが、  ボディの長さはメッセージごとに異なっているが、
 長さは $0$ でもよいことになっている  長さは $0$ でもよい。
 %なお、すべてのメッセージに ボディが必要というわけではなく、  
 %ボディのないメッセージも OpenXM 規約には存在することに  
 %注意しなければならない。  
   
 ヘッダは次の二つの情報を持っている。  ヘッダは次の二つの情報を持っている。
 \begin{enumerate}  \begin{enumerate}
 \item   前半の 4 バイトにある、メッセージの種類を表わす識別子。  \item   前半の 4 バイト。メッセージの種類を表わす識別子であり、
         タグと呼ばれる。          タグと呼ばれる。
 \item   後半の 4 バイトにある、メッセージにつけられた通し番号。  \item   後半の 4 バイト。メッセージにつけられた通し番号である。
 \end{enumerate}  \end{enumerate}
 それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。  それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。
 この場合に用いられる整数の表現方法の説明については後述するが、  この場合に用いられる整数の表現方法については後述するが、
 基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、  基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、
 またその選択は通信路の確立時に一度だけなされることに注意しなければならない。  またその選択は通信路の確立時に一度だけなされることに注意しなければならない。
   現在のOpenXM 規約では、タグ(整数値)として
   以下のものが定義されている。
   
 %{\Huge 以下、書き直し}  \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}
   
 ボディの中身は各データ形式によって  ボディの構造はメッセージの種類によって異なる。
 それぞれ独立に決められるようになっている。  この論文では OX\_DATA と \\
 もし、 OpenXM 規約でまだ定義されていないデータ形式を使いたい場合は、  OX\_COMMAND で識別されるメッセージについてのみ、説明する。
 メッセージのヘッダのタグをまだ使われてない整数値に設定し、  
 ボディにデータを埋め込めばよい。  
 なお、このような用途にも使えるように、  
 タグにはシステム固有の表現用に推奨されている整数の範囲がある。  
   
   既存のメッセージでは対応できない場合は、新しい識別子を定義することで新し
   い種類のメッセージを作成することができる。この方法は各数学ソフトウェアの
   固有の表現を含むメッセージを作成したい場合などに有効である。新しい識別子
   の定義方法については、\cite{OpenXM-1999} を参照すること。
   
   \section{OpenXM の計算モデル}
   
   OpenXM 規約での計算とはメッセージを交換することである。また、 OpenXM 規
   約ではクライアント・サーバモデルを採用しているので、メッセージの交換はサー
   バとクライアントの間で行なわれる。クライアントからサーバへメッセージを送
   り、クライアントがサーバからメッセージを受け取ることによって計算の結果が
   得られる。
   
   サーバはスタックマシンである。サーバがクライアントから受け取ったメッセー
   ジは、タグが OX\_COMMAND でなければすべてスタックに積まれる。タグが
   OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、このメッ
   セージを受け取ったサーバはそれに対応する動作を行なうことが期待されている。
   
   %{\large\bf 意味不明な書き方だけど、}
   サーバはメッセージを受け取らない限り、自ら何か動作を行なおうとはしない。
   これはクライアントが毎回サーバへメッセージを送るたびに、
   いつもサーバからのメッセージを待つ必要がないことを意味する。
   このため、クライアントはサーバの状態を気にせずにメッセージを送り、
   一旦メッセージを送付し終えた後、
   送ったメッセージの結果をサーバから待つことなしに次の動作に移ることができる。
   
 \section{OpenXM の計算の進行方法}  \section{OpenXM の計算の進行方法}
   
 OpenXM における計算とはメッセージの交換のことである。  %前の節と重複しているのでもう少しちゃんと考えて欲しいのだけれど、
 既に計算モデルの節で説明したが、  
 OpenXM はサーバ・クライアントモデルを採用していて、  
 サーバはスタックマシンの構造を持つ。  
 サーバが行うのは基本的に次の事柄に限られる。  
 クライアントからメッセージを受け取るとサーバは、  
 まずメッセージの識別子を調べ、 SM 形式のデータでなければスタックに積む。  
 SM 形式のデータであればメッセージのボディから  
 スタックマシンのオペコードを取りだし、  
 あらかじめ規約で定められた動作を行なう。  
   
 %上の説明でわかるように、  前節の説明でわかるように、
 サーバはクライアントからの指示なしに、  サーバはクライアントからの指示なしに、
 自らメッセージを送らないことに注意しなければならない。  自らメッセージを送らない。
 %(例外? ox\_asir の mathcap)。  %(例外? ox\_asir の mathcap)。
   
 サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。  
 次いでサーバに SM 形式のデータを送ると、  この辺はスタックマシンのところに書こう。
   
   
   サーバがクライアントから受け取ったオブジェクトはすべてスタックに積まれる。
   次いでサーバにスタックマシンへの命令を送ると、
 初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。  初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。
 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。  このとき、必要があればサーバはスタックから必要なだけデータを取り出す。
 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても  ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても
 サーバはエラーオブジェクトをスタックに積むだけで、  サーバはエラーオブジェクトをスタックに積むだけで、
 明示されない限りエラーを返さないことに注意しなければならない。  明示されない限りエラーすらもクライアントへ返さないことに
   注意しなければならない。
   
 結果が生じる動作をサーバが行なった場合、  結果が生じる動作をサーバが行なった場合、
 サーバは動作の結果をスタックに積んでいる。  サーバは動作の結果をスタックに積む。
 サーバに行なわせた動作の結果をクライアントが知りたい場合、  サーバに行なわせた動作の結果をクライアントが知りたい場合、
 スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを  スタックからデータを取り出し送信を行なう命令をサーバ側へ送ればよい。
 サーバ側へ送ればよい。  
   
 {\Huge 以下、書き直し}  %{\Huge 以下、書き直し}
   
 クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、  クライアントがサーバへメッセージを送り、
 次のようになる。  計算の結果を得るという手順を追っていくと次のようになる。
   
 \begin{enumerate}  \begin{enumerate}
 \item   まず、クライアントがサーバへ計算させたいデータを送る。  \item   まず、クライアントがサーバへメッセージを送る。
         サーバは送られてきたデータをスタックに積む。          サーバは送られてきたメッセージをスタックに積む。
 \item   クライアントがサーバに「計算を行なう動作に対応したデータ」を  \item   クライアントがサーバにスタックマシンへの命令を送ると、
         送ると、サーバは必要なだけスタックからデータを取り出し、          サーバは必要なだけスタックからデータを取り出し、
         実行した計算の結果をスタックに積む。          実行した結果をスタックに積む。
 \item   最後に「データを取り出し送信を行なう命令に対応したデータ」を  \item   最後に「スタックからデータを取り出し送信を行なう命令」を
         サーバへ送ると、サーバはスタックから計算結果の入っている          サーバへ送ると、サーバはスタックから計算結果の入っている
         データを取り出し、クライアントへ送出する。          データを取り出し、クライアントへ送出する。
 \end{enumerate}  \end{enumerate}
   
   \section{OpenXM スタックマシン}
   
   OpenXM 規約ではサーバはスタックマシンであると定義している。以下、OpenXM
   スタックマシンと呼ぶ。この節ではOpenXM スタックマシンの構造について説明
   しよう。
   
   さて、OpenXM 規約はスタックに積まれるオブジェクトの構造までは規定しない。
   つまり、オブジェクトの構造は各数学システムごとに異なっているということで
   ある。OpenXM 規約は通信時にやりとりされる共通のデータ形式については規定
   するが、OpenXM 規約に対応した各数学システムは、通信路からデータを受け取っ
   た際に、各数学システムの固有のデータ構造に変換してからスタックに積むこと
   を意味する。この変換は1対1対応である必要はない。
   
   次に OpenXM スタックマシンの命令コードについて説明する。OpenXM スタック
   マシンにおけるすべての命令は4バイトの長さを持つ。OpenXM 規約の他の規定と
   同様に、4バイトのデータは32ビット整数と見なされるので、この論文でもその
   表記にしたがう。OpenXM スタックマシンに対する命令はスタックに積まれるこ
   とはない。現在のところ、OpenXM 規約では以下の命令が定義されている。
   
   \begin{verbatim}
   #define SM_popSerializedLocalObject 258
   #define SM_popCMO 262
   #define SM_popString 263
   
   #define SM_mathcap 264
   #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_reset_connection  1030
   #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
   \end{verbatim}
   
   以下、どういうときに結果をスタックに積むかエラーの場合どうするかの説明が
   必要であろう。
   
 \section{CMO のデータ構造}  \section{CMO のデータ構造}
   
 OpenXM 間でやりとりされるメッセージを実際に作成する場合、  OpenXM 規約では、数学的オブジェクトを表現する方法として CMO 形式(Common
   Mathematical Object format)を定義している。この CMO 形式にしたがったデー
   タは、識別子が OX\_DATA であるようなメッセージのボディになることを想定し
   ている。
   
   CMO 形式におけるデータ構造は次のような構造をもつ。
   \begin{verbatim}
   ヘッダ     ボディ
   \end{verbatim}
   ヘッダは4バイトである。
   ボディの長さはそれぞれのデータによって異なるが、0でもよい。
   
   \begin{verbatim}
   説明。説明。説明。説明。説明。
   説明。説明。説明。説明。説明。
   説明。説明。説明。説明。説明。
   説明。説明。説明。説明。説明。
   \end{verbatim}
   
   
   %OpenXM 規約で定義されているメッセージを実際に作成する場合、
 CMO 形式で定義されている多倍長整数を理解しておくと、  CMO 形式で定義されている多倍長整数を理解しておくと、
 CMO 形式の他のデータ構造だけでなく、 OX 形式、 SM 形式のデータを  CMO 形式の他のデータ構造だけでなく、
 理解する助けになると思えるので、 CMO 形式の多倍長整数の  OpenXM 規約で定義されている様々なデータ構造を理解する助けになると思えるので、
 データ構造について説明する。  ここでは CMO 形式の多倍長整数のデータ構造についてのみ説明する。
   
 CMO 形式で定義されているデータは多倍長整数以外にも  CMO 形式で定義されているデータは多倍長整数以外にも
 文字列やリスト構造などがある。どのようなデータであるかは  文字列やリスト構造などがある。どのようなデータであるかは
 データの先頭にあるタグを見れば判別できるようになっている。  データの先頭 4 バイトにある(メッセージの識別子とは別にある)タグを見れば
 これはメッセージのデータの判別の仕方とおなじである。  判別できるようになっている。
   これはメッセージの種類の判別の仕方とおなじである。
 なお、タグは各データ毎に 32 bit の整数で表されており、  なお、タグは各データ毎に 32 bit の整数で表されており、
 多倍長整数は 20 となっている。  多倍長整数は 20 となっている。
   よく使われると思われる CMO 形式のタグをあげておく。
   \begin{verbatim}
   #define CMO_INT32    2 /* 32 ビット整数 */
   #define CMO_STRING   4 /* 文字列        */
   #define CMO_MATHCAP  5 /* mathcap(後述) */
   #define CMO_LIST    17 /* リスト構造    */
   #define CMO_ZZ      20 /* 多倍長整数    */
   \end{verbatim}
   
 ここで 32 bit の整数の表現方法について説明する必要がある。  ここで 32 bit の整数の表現方法について説明する必要がある。
 OpenXM ではバイト列で 32 bit の整数 20 を  OpenXM 規約ではバイトストリームで 32 bit の整数 20 を
 {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。  {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。
 この表現方法の違いはクライアントとサーバの最初の接続時に  この表現方法の違いはクライアントとサーバの最初の接続時に
 双方の合意で決定することになっている。  双方の合意で決定することになっている。
 なお、合意がない場合には  なお、合意がない場合には前者の表現方法
 前者の表現方法(以後、この表現方法を network byte order と呼ぶ)を  (以後、この表現方法をネットワークバイトオーダーと呼ぶ)を
 使うことになっている。  使うことになっている。
 また、負の数を表現する必要があるときには、  また、負の数を表現する必要があるときには、
 2 の補数表現を使うことになっている。  2 の補数表現を使うことになっている。
   
 表現したい多倍長整数の絶対値を 2 進数で表した場合の桁数を $n$ と  CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、
 したとき、次にくるデータは $[(n+31)/32]$ を 32 bit の整数となる。  符合付き絶対値表現を用いている。
 これは多倍長整数の絶対値を $2^{32}$ 進数で表した場合の桁数ととってもよい。  タグ以降の形式は次のようになる。
 ただし、表現したい数が負の場合は $[(n+31)/32]$ を 32 bit の整数で表した値を  
  2 の補数表現で負にして、正の場合と区別する。  
   
 表現したい多倍長整数の絶対値が $2^{32}$ 進数で $(b_0 b_1 ... b_k)_{2^{32}}$  \begin{tabular}{|c|c|c|c|c|} \hline
 と表せるとき、次にくるデータは $b_0$, $b_1$, $\cdots$, $b_k$ を  $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline
 それぞれ 32 bit の整数で表現した値となる。  \end{tabular}
 %以下は書き直しの必要があるかも...  
 なお、 GNU MP LIBRARY を用いると、  
 C 言語から多倍長整数や任意精度浮動小数を扱うことができる。  
 $b_0$, $b_1$, $\cdots$, $b_k$ をそれぞれ 32 bit 整数で表現した値は  
 この GNU MP LIBRARY で用いられている多倍長整数で使われている形式を  
 参考にして合わせてある。  
   
   ここで、 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$ を network byte order の多倍長整数で  $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}          {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01}
 \end{center}  \end{center}
Line 218  $4294967298 = 1 \times 2^{32} + 2$ を network byte ord
Line 311  $4294967298 = 1 \times 2^{32} + 2$ を network byte ord
 となる。  となる。
   
   
 \section{MathCap について}  \section{mathcap について}
   
 サーバおよびクライアント双方ともに OpenXM で規定されている  OpenXM 規約では、通信時に用いられるメッセージの種類を各ソフトウェアが制
 メッセージの中のデータ形式をすべて受け取れるわけではない。  限する方法を用意している。これは各ソフトウェアの実装によってはすべてのメッ
 しかも、 OpenXM 規約で規定されているデータ形式だけが  セージをサポートするのが困難な場合があるからである。また、各ソフトウェア
 受渡しに使われるというわけではない。  でメッセージの種類を拡張したい場合にも有効である。この制限(あるいは拡張)
 そこで、 OpenXM では相手側が受け取ることができるデータ形式を  は mathcap と呼ばれるデータ構造によって行われる。この節では mathcap のデー
 収得する方法を用意している。  タ構造と、具体的なメッセージの制限の手続きについて説明する。
   
 CMO 形式で定義されている MathCap データは  まず、手続きについて説明しよう。
 %理解可能なメッセージの  クライアント側の mathcap をサーバへ送ると、
 受け取ることができるデータ形式を表すデータであり、  すでに説明したように、サーバは受け取った mathcap をスタックに積み上げる。
 要求されればサーバはサーバ自身の MathCap データをスタックに積む。  次にクライアントはスタックマシンへの命令をサーバへ送ることにより、
 また、クライアントから MathCap データをサーバへ送ることもでき、  サーバはスタックに積まれている mathcap を取り出し、
 MathCap データをサーバとクライアントの間で交換することによって、  mathcap で設定されていないメッセージをクライアント側へ
 お互いに相手側が受け取ることができないデータ形式で  送らないように設定する。
 メッセージを送ってしまうのを防ぐことができる。  サーバ側の mathcap が欲しい場合には以下のようにする。
 なお、 MathCap データの中では CMO 形式で定義されている  クライアントがサーバに mathcap を要求すると、
 32 bit 整数、文字列、リスト構造が使われており、  サーバはサーバ自身の mathcap をスタックに積む。
 MathCap データに含まれている内容を理解できるためには  さらにサーバにスタックからデータを取り出し送信を行なう命令を送れば、
 必然的にこれらも理解できる必要がある。  サーバはスタックにある mathcap をクライアントへ送出する。
   このようにしてクライアントはサーバ側の mathcap を受け取れるわけである。
   
 OpenXM 対応版の asir サーバである ox\_asir が返す MathCap を以下に示す。  次に mathcap のデータ構造について説明する。
   mathcap は CMO 形式で定義されており、
   1 つの CMO 形式のオブジェクトを持つ。
   
 %なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に  そのオブジェクトは以下で説明する 3 つの要素からなるリストでなければならない。
 %持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、  
 %文字列 ``string'' を {\tt "string"} 、 32 bit 整数を  
 %それに対応する 10 進数の整数で示す。  
   
 %↓手で作ったので間違えている可能性あり。  \[      \begin{tabular}{|c|c|c|} \hline
 %%古いバージョン。差し替えの必要あり。          $A$ & $B$ & $C$ \\ \hline
 \begin{verbatim}          \end{tabular}   \]
 [ [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 つの部分に分かれる。  最初の要素 $A$ の部分は以下の図のようなリスト構造をしており、
 最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。  $a_1$ は 32 ビット整数でバージョンナンバーを、
 %この最初の要素がまたリスト構造となっており、  $a_2$ は文字列でシステムの名前を表すことになっている。
 最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。  
   
 次の {\tt [276,275,$\cdots$,271]} の部分は  \[      \begin{tabular}{|c|c|} \hline
 サーバに対する動作に対応した理解可能なデータの種類を表している。          $a_1$ & $a_2$   \\ \hline
 サーバの動作に対するデータはすべて 32 bit の整数で表しており、          \end{tabular}   \]
 このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。  
   
 最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は  2 番目の要素 $B$ の部分は次のようなリスト構造をしている。
 理解可能なデータの形式を表している。  この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて 32 ビットの整数である。
 この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と  スタックマシンへの命令はすべて 32 ビットの整数で表しており、
 {\tt [2144202544,[0,1]]} にの部分に分けることができ、  各 $b_i$ は利用可能な命令に対応する 32 ビットの整数となっている。
 それぞれが一つのデータ形式についての情報となっている。  
 どのデータ形式についての情報かは最初の要素にある整数値をみれば  
 分かるようになっている。  
 この整数値は CMO 形式では 514 となっている。  
 最初のデータ形式を区別する整数値以後の要素は  
 各データ形式によってどのように使われるか定まっている。  
 CMO 形式では理解可能なデータの tag がリストの中に収まっている。  
 前節で CMO 形式では多倍長整数を表す tag が 20 であることを述べたが、  
 このリストに 20 が含まれているので、  
 ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。  
   
 %%このリストの要素はまたリストとなっており、  \[      \begin{tabular}{|c|c|c|c|} \hline
 %この最後の部分もまたリストとなっており、          $b_1$ & $b_2$ & $\cdots$ & $b_n$        \\ \hline
 %あるデータ形式で理解可能なものを表現したリストを要素としている。          \end{tabular}   \]
 %{\tt [514,[1, 2, $\cdots$]]} の最初の 514 はこのリストが CMO 形式  
 %での理解可能なデータを表していることを示しており、  
 %その後のリストでは CMO 層で定義されているデータのうち、  
 %理解可能なデータの tag が並んでいる。  
   
   3 番目の要素 $C$ は以下のようなリスト構造をしている。
   \[  \overbrace{
           \begin{tabular}{|c|c|c|c|} \hline
           $c_1$ & $c_2$ & $\cdots$ & $c_n$        \\ \hline
           \end{tabular}
      }^{C}        \]
   %$n$ は OX\_COMMAND 以外の受け取れるメッセージのタグの種類の数に等しい。
   %要素数は 1 でももちろん構わない。
   各 $c_i$ もまた以下のようなリスト構造となっており、
   どの $c_i$ も最初の要素が 32 ビットの整数となっている。
   \[  \overbrace{
           \begin{tabular}{|c|c|c|c|c|} \hline
           $c_{i1}$ (32 ビットの整数) & $c_{i2}$ & $c_{i3}$ &
                   $\cdots$ & $c_{im}$     \\ \hline
           \end{tabular}
      }^{c_i}      \]
   このリストの最初の整数値は受け取れるメッセージのタグが入っている。
   $c_{i2}$ 以降については最初の $c_{i1}$ の値によってそれぞれ異なる。
   ここでは、最初の要素が OX\_DATA の場合についてのみ説明する。
   この $c_{i1}$ が OX\_DATA の場合、
   リスト $c_i$ は CMO 形式についての情報を表しており、
   $m=2$ と決められている。
   $c_{i1}$ にはもちろんのこと OX\_DATA が入っており、
   $c_{i2}$ は以下の図のようなリスト構造になっている。
   各要素は 32 ビットの整数であり、
   受け取ることが可能な CMO 形式のタグが入る。
   \[  \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 の例をあげよう。
   %なお、 $a_1$, $a_2$, $\cdots$, $a_n$ を要素に
   %持つリスト構造を {\tt [$a_1$, $a_2$, $\cdots$, $a_n$]} 、
   %文字列 ``string'' を {\tt "string"} 、 32 bit 整数を
   %それに対応する 10 進数の整数で示す。
   名前が ``ox\_test'' 、バージョンナンバーが 199911250 のサーバであれば、
   $A$ の部分は
   \begin{tabular}{|c|c|} \hline
   199911250 & "ox\_test" \\ \hline
   \end{tabular}
   となる。
   さらに、このサーバのスタックマシンが
   命令コード 2, 3, 5, 7, 11 番を利用可能
   (実際にはこのような命令コードは存在しない)であれば、 $B$ の部分は
   \begin{tabular}{|c|c|c|c|c|} \hline
   2 & 3 & 5 & 7 & 11 \\ \hline
   \end{tabular}
   となり、
   CMO 形式の 32 ビット整数、文字列、 mathcap 、リスト構造のみが
   受け取れるときには、 $C$ の部分は
   \begin{tabular}{|c|} \hline
           \\[-5mm]
           \begin{tabular}{|c|c|} \hline
                   & \\[-5mm]
                   OX\_DATA &
                   \begin{tabular}{|c|c|c|c|} \hline
                   CMO\_INT32 & CMO\_STRING & CMO\_MATHCAP & CMO\_LIST \\ \hline
                   \end{tabular} \\[0.8mm] \hline
           \end{tabular} \\[1.4mm] \hline
   \end{tabular} \\
   となる。
   CMO\_ZZ がないので、このサーバは多倍長整数が
   送られてこないことを期待している。
   
 なお、データが受け取れることと、  なお、データが受け取れることと、
 データの論理構造が理解できることとはまったく別物であるので  データの論理構造が理解できることとはまったく別物であるので
 注意する必要がある。  注意する必要がある。
Line 300  ox\_asir は CMO 形式の多倍長整数を受け取れることがわか
Line 441  ox\_asir は CMO 形式の多倍長整数を受け取れることがわか
   
 \section{セキュリティ対策}  \section{セキュリティ対策}
   
 OpenXM では幾らかのセキュリティ対策を考えている。  OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している。
 OpenXM に対応したソフトウェアをクラックしても  ネットワークによって接続される現代の多くのソフトウェアと同様、
 大した利点はないと思えるが、それは設計上の話であって、  OpenXM 規約もまた通信時のセキュリティについて注意している。
 予期せぬ手段で攻撃を受けた場合にどのような事態を  以下、このことについて説明しよう。
 招くかは想像し難い。  
   
 そこで、 OpenXM では侵入者に攻撃の機会を  {\large\bf 意味不明なことを書いているが、}
 できるだけ与えないようにしている。  
 具体的には、接続が必要になった時のみ接続を待つようにし、  
 常に接続に関与するといったことは避けている。  
   
 しかし、これだけでは侵入者が接続を行なう一瞬のすきを  侵入者に攻撃の機会をできるだけ与えないようするた
 狙ってくる可能性もある。  めに、接続が必要になった時のみ接続を待つようにし、
 そこで接続を行なう時に、  常に接続に関与するといったことは避けている(やっぱり意味不明である)。
 接続を待つ port 番号をランダムに決めている。  
 こうすることで、特定の port 番号を狙って接続を行なう  
 瞬間を待つ手口を幾らか防ぐことができる。  
   
   また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、
   接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい
   るのかはやっぱり不明であるが)。
 さらにもう一段安全性を高めるために、  さらにもう一段安全性を高めるために、
 接続時に 1 回だけ使用可能なパスワードを作成し、  接続時に 1 回だけ使用可能なパスワードを作成し、
 そのパスワードを使って認証を行なう。  そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ
   ているのかが不明だけど)。
 このパスワードは一旦使用されれば無効にするので、  このパスワードは一旦使用されれば無効にするので、
 もし仮になんらかの手段でパスワードが洩れたとしても安全である。  もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。
   
 なお、上記の port 番号とパスワードは安全な手段で送られて  %なお、上記のポート番号とパスワードは安全な手段で送られて
 いると仮定している。  %いると仮定している。
 また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している  %また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している
 ことに注意しなければならない。  %ことに注意しなければならない。
 なぜなら、現在の実装ではサーバ、およびクライアントの動作している  %なぜなら、現在の実装ではサーバ、およびクライアントの動作している
 コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。  %コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。
   
 なお、接続が確立した後のメッセージの送受信に関しては、  なお、接続が確立した後のメッセージの送受信に関しては、
 特に暗号化などの処置が行なわれているわけではない。  特に暗号化などの処置を行っているわけではない。
 もし必要があれば、通信路の暗号化を行なう機能がある  もし必要があれば、通信路の暗号化を行なう機能がある
 ソフトウェアを使うことを考えている。  ソフトウェア ssh を使うことを考えている。
   
   
 \section{他のプロジェクト}  \section{他のプロジェクト}
   
 他のプロジェクトについても触れておこう。  他のプロジェクトについても触れておこう。
   
   \begin{itemize}
   \item OpenMath
   
 OpenMath プロジェクトは数学的なオブジェクトを  OpenMath プロジェクトは数学的なオブジェクトを
 コンピュータ上で表現する方法を決定している。  コンピュータ上で表現する方法を決定している。
 各ソフトウェア間でオブジェクトを交換する際の  各ソフトウェア間でオブジェクトを交換する際の
Line 352  OpenMath プロジェクトは数学的なオブジェクトを
Line 492  OpenMath プロジェクトは数学的なオブジェクトを
 http://www.openmath.org/omsoc/index.html A.M.Cohen  http://www.openmath.org/omsoc/index.html A.M.Cohen
   
   
 以下は書いてる途中。  \item NetSolve
   
 NetSolve  
   
 http://www.cs.utk.edu/netsolve/  http://www.cs.utk.edu/netsolve/
   
   
 MP  \item MP
   
 http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html  http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html
   
   
 MCP  \item MCP
   
 http://horse.mcs.kent.edu/~pwang/  http://horse.mcs.kent.edu/~pwang/
   \end{itemize}
   
   
 \section{現在提供されているソフトウェア}  \section{現在提供されているソフトウェア}
Line 377  asir, sm1, Mathematica がある。
Line 516  asir, sm1, Mathematica がある。
 OpenXM 規格に対応したサーバを呼び出すことができる。  OpenXM 規格に対応したサーバを呼び出すことができる。
 現在 OpenXM 規約に対応しているサーバソフトウェアには、  現在 OpenXM 規約に対応しているサーバソフトウェアには、
  asir, sm1, gnuplot, Mathematica などがあり、   asir, sm1, gnuplot, Mathematica などがあり、
 それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。  それぞれ ox\_asir, ox\_sm1, ox\_sm1\_gnuplot, ox\_math
 また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の  という名前で提供されている。
 データを変換するソフトウェアが JAVA によって実装されており、  また、 OpenMath 規格の XML 表現で表現されたオブジェクトと CMO 形式の
   オブジェクトを変換するソフトウェアが JAVA によって実装されており、
 OMproxy という名前で提供されている。  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.39  
changed lines
  Added in v.1.68
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>