\documentclass{jarticle} %% $OpenXM: OpenXM/doc/genkou19991125.tex,v 1.69 1999/12/24 10:08:41 tam Exp $ \usepackage{jssac} \title{ 1. 意味もない修飾過剰な語句は排除しましょう。\\ %2. 姓と名の間の2バイトの空白は何か理由があるの? %(jssac の規約だっけ) <- 規約っす\\ 3. せっかく fill しているのをいじらないでくれ。 } \author{奥 谷 　 行 央\affil{神戸大学大学院自然科学研究科} \mail{okutani@math.sci.kobe-u.ac.jp} \and 小 原 　 功 任\affil{金沢大学理学部} \mail{ohara@kappa.s.kanazawa-u.ac.jp} \and 高 山 　 信 毅\affil{神戸大学理学部} \mail{takayama@math.sci.kobe-u.ac.jp} \and 田 村 　 恭 士\affil{神戸大学大学院自然科学研究科} \mail{tamura@math.sci.kobe-u.ac.jp} \and 野 呂 　 正 行\affil{富士通研究所} \mail{noro@para.flab.fujitsu.co.jp} \and 前 川 　 将 秀\affil{神戸大学理学部} \mail{maekawa@math.sci.kobe-u.ac.jp} } \art{} \begin{document} \maketitle \section{OpenXMとは} OpenXM は数学プロセス間でメッセージを交換するための規約である。 数学プロセス間でメッセージをやりとりすることにより、 ある数学プロセスから他の数学プロセスを呼び出して計算を行なったり、 他のマシンで計算を行なわせたりすることが目的である。 なお、 OpenXM とは Open message eXchange protocol for Mathematics の略である。 OpenXM の開発の発端は野呂と高山により、 asir と kan/sm1 を相互に呼び出す機能を実装したことである。 初期の実装では、相手側のローカル言語の文法に従った文字列を送っていた。 この方法では相手側のソフトが asir なのか kan/sm1 なのかを判別するなどして、 相手側のローカル言語の文法に合わせた文字列を作成しなければならない。 このローカル言語の文法に従った文字列を送る方法は、 効率的であるとはいい難いが、使いやすいとも言える。 現在の OpenXM 規約では共通表現形式によるメッセージを用いている。 上記の文字列を送る方法の利点を生かすため、 OpenXM 規約では共通表現形式の中の文字列として、 ローカル言語の文法に従った文字列を用いたメッセージの交換も可能となっている。 OpenXM 規約では通信の方法に幾らかの自由度があるが、 現在のところは TCP/IP を用いた通信しか実装されていない。 そこで、この論文では具体的な実装は TCP/IP を用いていると仮定する。 \section{OpenXM のメッセージの構造} 通信の方法によってメッセージの構造は変わる。 前節で仮定したとおり、この論文では TCP/IP の場合についてのみ説明を行なう。 OpenXM 規約で規定されているメッセージはバイトストリームとなっており、 次のような構造になっている。 \begin{tabular}{|c|c|} \hline ヘッダ & \hspace{10mm} ボディ \hspace{10mm} \\ \hline \end{tabular} ヘッダの長さは 8 バイトであると定められている。 ボディの長さはメッセージごとに異なっているが、 長さは $0$ でもよい。 ヘッダは次の二つの情報を持っている。 \begin{enumerate} \item 前半の 4 バイト。メッセージの種類を表わす識別子であり、 タグと呼ばれる。 \item 後半の 4 バイト。メッセージにつけられた通し番号である。 \end{enumerate} それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。 この場合に用いられる整数の表現方法については後述するが、 基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、 またその選択は通信路の確立時に一度だけなされることに注意しなければならない。 現在の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} ボディの構造はメッセージの種類によって異なる。 タグが OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、 それ以外のメッセージは何らかのオブジェクトを表している。 この論文では OX\_DATA と OX\_COMMAND で識別される メッセージについてのみ、説明する。 既存のメッセージでは対応できない場合は、新しい識別子を定義することで新し い種類のメッセージを作成することができる。この方法は各数学ソフトウェアの 固有の表現を含むメッセージを作成したい場合などに有効である。新しい識別子 の定義方法については、\cite{OpenXM-1999} を参照すること。 \section{OpenXM の計算モデル} OpenXM 規約での計算とはメッセージを交換することである。また、 OpenXM 規 約ではクライアント・サーバモデルを採用しているので、メッセージの交換はサー バとクライアントの間で行なわれる。クライアントからサーバへメッセージを送 り、クライアントがサーバからメッセージを受け取ることによって計算の結果が 得られる。 サーバはスタックマシンである。サーバがクライアントから受け取ったメッセー ジは、タグが OX\_COMMAND でなければすべてスタックに積まれる。タグが OX\_COMMAND となっているメッセージはスタックマシンへの命令であり、このメッ セージを受け取ったサーバはそれに対応する動作を行なうことが期待されている。 %{\large\bf 意味不明な書き方だけど、} サーバはメッセージを受け取らない限り、自ら何か動作を行なおうとはしない。 これはクライアントが毎回サーバへメッセージを送るたびに、 いつもサーバからのメッセージを待つ必要がないことを意味する。 このため、クライアントはサーバの状態を気にせずにメッセージを送り、 一旦メッセージを送付し終えた後、 送ったメッセージの結果をサーバから待つことなしに次の動作に移ることができる。 \section{OpenXM の計算の進行方法} %前の節と重複しているのでもう少しちゃんと考えて欲しいのだけれど、 前節の説明でわかるように、 サーバはクライアントからの指示なしに、 自らメッセージを送らない。 %(例外? ox\_asir の mathcap)。 この辺はスタックマシンのところに書こう。 サーバがクライアントから受け取ったオブジェクトはすべてスタックに積まれる。 次いでサーバにスタックマシンへの命令を送ると、 初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。 このとき、必要があればサーバはスタックから必要なだけデータを取り出す。 ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても サーバはエラーオブジェクトをスタックに積むだけで、 明示されない限りエラーすらもクライアントへ返さないことに 注意しなければならない。 結果が生じる動作をサーバが行なった場合、 サーバは動作の結果をスタックに積む。 サーバに行なわせた動作の結果をクライアントが知りたい場合、 スタックからデータを取り出し送信を行なう命令をサーバ側へ送ればよい。 %{\Huge 以下、書き直し} クライアントがサーバへメッセージを送り、 計算の結果を得るという手順を追っていくと次のようになる。 \begin{enumerate} \item まず、クライアントがサーバへメッセージを送る。 サーバは送られてきたメッセージをスタックに積む。 \item クライアントがサーバにスタックマシンへの命令を送ると、 サーバは必要なだけスタックからデータを取り出し、 実行した結果をスタックに積む。 \item 最後に「スタックからデータを取り出し送信を行なう命令」を サーバへ送ると、サーバはスタックから計算結果の入っている データを取り出し、クライアントへ送出する。 \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_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} 以下、どういうときに結果をスタックに積むかエラーの場合どうするかの説明が 必要であろう。 \section{CMO のデータ構造} OpenXM 規約では、数学的オブジェクトを表現する方法として CMO 形式(Common Mathematical Object format)を定義している。この CMO 形式にしたがったデー タは、識別子が OX\_DATA であるようなメッセージのボディになることを想定し ている。 CMO 形式におけるデータ構造は次のような構造をもつ。 \begin{verbatim} ヘッダ ボディ \end{verbatim} ヘッダは4バイトである。 ボディの長さはそれぞれのデータによって異なるが、0でもよい。 \begin{verbatim} 説明。説明。説明。説明。説明。 説明。説明。説明。説明。説明。 説明。説明。説明。説明。説明。 説明。説明。説明。説明。説明。 \end{verbatim} CMO 形式で定義されている多倍長整数を理解しておくと、 CMO 形式の他のデータ構造だけでなく、 OpenXM 規約で定義されている様々なデータ構造を理解する助けになると思えるので、 ここでは CMO 形式の多倍長整数のデータ構造についてのみ説明する。 %ここでは CMO 形式の中でもよく使われるもののみについて説明する。 >>>>>>> 1.68 CMO 形式で定義されているデータは多倍長整数以外にも 文字列やリスト構造などがある。どのようなデータであるかは データの先頭 4 バイトにある(メッセージの識別子とは別にある)タグを見れば 判別できるようになっている。 これはメッセージの種類の判別の仕方とおなじである。 なお、タグは各データ毎に 32 bit の整数で表されており、 多倍長整数は 20 となっている。 よく使われると思われる CMO 形式のタグをあげておく。 \begin{verbatim} #define CMO_INT32 2 /* (CMO 形式の)32 ビット整数 */ #define CMO_STRING 4 /* 文字列 */ #define CMO_MATHCAP 5 /* mathcap(後述) */ #define CMO_LIST 17 /* リスト構造 */ #define CMO_ZZ 20 /* 多倍長整数 */ \end{verbatim} タグ以降はデータ本体であり、データ本体の構造はデータの種類によって異なる。 整数値 $123456789$ を表す CMO\_INT32 は \begin{tabular}{|c|c|} \hline CMO\_INT32 & $123456789$ \\ \hline \end{tabular} と定義されているが、これを以後 (CMO\_INT32, 123456789) として表す。 ここで 32 bit の整数の表現方法について説明する必要がある。 OpenXM 規約ではバイトストリームで 32 bit の整数 20 を {\tt 00 00 00 14} と表す方法と {\tt 14 00 00 00} と表す方法がある。 この表現方法の違いはクライアントとサーバの最初の接続時に 双方の合意で決定することになっている。 なお、合意がない場合には前者の表現方法 (以後、この表現方法をネットワークバイトオーダーと呼ぶ)を 使うことになっている。 また、負の数を表現する必要があるときには、 2 の補数表現を使うことになっている。 CMO 形式の多倍長整数は、 Gnu MPライブラリ等を参考にしており、 符合付き絶対値表現を用いている。 タグ以降の形式は次のようになる。 \begin{tabular}{|c|c|c|c|c|} \hline $f$ & $b_0$ & $b_1$ & $\cdots$ & $b_{n-1}$ \\ \hline \end{tabular} ここで、 1 つの枠は 4 バイトを表し、 $f$ は符合付き 32 ビット整数を、 $b_0$, $b_1$, $\cdots$, $b_{n-1}$ は符合なし 32 ビット整数を表している。 さらに、 $|f| = n$ が成り立たなければならない。 このオブジェクトは \[ \mbox{sgn}(f) \times \{ b_0 (2^{32})^0 + b_1 (2^{32})^1 + \cdots + b_{n-1} (2^{32})^{n-1} \} \] という整数であると定義されている。 ただし、 \[ \mbox{sgn}(f) = \left\{ \begin{array}{ll} 1 & f>0 \\ 0 & f=0 \\ -1 & f<0 \\ \end{array} \right. \] である。 ここで具体例をだそう。 $4294967298 = 1 \times 2^{32} + 2$ を CMO 形式の ネットワークバイトオーダー、多倍長整数で表現すると、 \begin{center} {\tt 00 00 00 14 00 00 00 02 00 00 00 02 00 00 00 01} \end{center} となる。また、同じ表現方法で $-1$ を表現すると、 \begin{center} {\tt 00 00 00 14 ff ff ff ff 00 00 00 01} \end{center} となる。 \section{mathcap について} OpenXM 規約では、通信時に用いられるメッセージの種類を各ソフトウェアが制 限する方法を用意している。これは各ソフトウェアの実装によってはすべてのメッ セージをサポートするのが困難な場合があるからである。また、各ソフトウェア でメッセージの種類を拡張したい場合にも有効である。この制限(あるいは拡張) は mathcap と呼ばれるデータ構造によって行われる。この節では mathcap のデー タ構造と、具体的なメッセージの制限の手続きについて説明する。 まず、手続きについて説明しよう。 クライアント側の mathcap をサーバへ送ると、 すでに説明したように、サーバは受け取った mathcap をスタックに積み上げる。 次にクライアントはスタックマシンへの命令をサーバへ送ることにより、 サーバはスタックに積まれている mathcap を取り出し、 mathcap で設定されていないメッセージをクライアント側へ 送らないように設定する。 サーバ側の mathcap が欲しい場合には以下のようにする。 クライアントがサーバに mathcap を要求すると、 サーバはサーバ自身の mathcap をスタックに積む。 さらにサーバにスタックからデータを取り出し送信を行なう命令を送れば、 サーバはスタックにある mathcap をクライアントへ送出する。 このようにしてクライアントはサーバ側の mathcap を受け取れるわけである。 次に mathcap のデータ構造について説明する。 mathcap は CMO 形式で定義されており、 1 つの CMO 形式のオブジェクトを持つ。 そのオブジェクトは以下で説明する 3 つの要素からなるリストでなければならない。 \[ \begin{tabular}{|c|c|c|} \hline $A$ & $B$ & $C$ \\ \hline \end{tabular} \] 最初の要素 $A$ の部分は以下の図のようなリスト構造をしており、 $a_1$ は 32 ビット整数でバージョンナンバーを、 $a_2$ は文字列でシステムの名前を表すことになっている。 \[ \begin{tabular}{|c|c|} \hline $a_1$ & $a_2$ \\ \hline \end{tabular} \] 2 番目の要素 $B$ の部分は次のようなリスト構造をしている。 この $b_1$, $b_2$, $\cdots$, $b_n$ はすべて 32 ビットの整数である。 スタックマシンへの命令はすべて 32 ビットの整数で表しており、 各 $b_i$ は利用可能な命令に対応する 32 ビットの整数となっている。 \[ \begin{tabular}{|c|c|c|c|} \hline $b_1$ & $b_2$ & $\cdots$ & $b_n$ \\ \hline \end{tabular} \] 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 がないので、このサーバは多倍長整数が 送られてこないことを期待している。 なお、データが受け取れることと、 データの論理構造が理解できることとはまったく別物であるので 注意する必要がある。 \section{セキュリティ対策} OpenXM 規約は TCP/IP を用いて通信を行うことを考慮している。 ネットワークによって接続される現代の多くのソフトウェアと同様、 OpenXM 規約もまた通信時のセキュリティについて注意している。 以下、このことについて説明しよう。 {\large\bf 意味不明なことを書いているが、} 侵入者に攻撃の機会をできるだけ与えないようするた めに、接続が必要になった時のみ接続を待つようにし、 常に接続に関与するといったことは避けている(やっぱり意味不明である)。 また、侵入者が接続を行なう一瞬のすきを狙ってくる可能性もあるので、 接続を行なう時に接続を待つポート番号をランダムに決めている(誰が決めてい るのかはやっぱり不明であるが)。 さらにもう一段安全性を高めるために、 接続時に 1 回だけ使用可能なパスワードを作成し、 そのパスワードを使って認証を行なう(誰がパスワードを決めて誰が認証を行っ ているのかが不明だけど)。 このパスワードは一旦使用されれば無効にするので、 もし仮になんらかの手段でパスワードが洩れたとしても安全だと考えている。 %なお、上記のポート番号とパスワードは安全な手段で送られて %いると仮定している。 %また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している %ことに注意しなければならない。 %なぜなら、現在の実装ではサーバ、およびクライアントの動作している %コンピュータ上ではこのポート番号とパスワードがわかってしまうためである。 なお、接続が確立した後のメッセージの送受信に関しては、 特に暗号化などの処置を行っているわけではない。 もし必要があれば、通信路の暗号化を行なう機能がある ソフトウェア ssh を使うことを考えている。 \section{他のプロジェクト} 他のプロジェクトについても触れておこう。 \begin{itemize} \item OpenMath OpenMath プロジェクトは数学的なオブジェクトを コンピュータ上で表現する方法を決定している。 各ソフトウェア間でオブジェクトを交換する際の オブジェクトの変換手順についても述べられている。 表現方法は一つだけでなく、 XML 表現や binary 表現などが 用意されている。 詳細は http://www.openmath.org/omsoc/index.html A.M.Cohen \item NetSolve http://www.cs.utk.edu/netsolve/ \item MP http://symbolicNet.mcs.kent.edu/SN/areas/protocols/mp.html \item MCP http://horse.mcs.kent.edu/~pwang/ \end{itemize} \section{現在提供されているソフトウェア} 現在 OpenXM 規格に対応しているクライアントには asir, sm1, Mathematica がある。 これらのクライアントから OpenXM 規格に対応したサーバを呼び出すことができる。 現在 OpenXM 規約に対応しているサーバソフトウェアには、 asir, sm1, gnuplot, Mathematica などがあり、 それぞれ ox\_asir, ox\_sm1, ox\_sm1\_gnuplot, ox\_math という名前で提供されている。 また、 OpenMath 規格の XML 表現で表現されたオブジェクトと CMO 形式の オブジェクトを変換するソフトウェアが JAVA によって実装されており、 OMproxy という名前で提供されている。 \begin{thebibliography}{99} \bibitem{Ohara-Takayama-Noro-1999} 小原功任, 高山信毅, 野呂正行: {Open asir 入門}, 1999, 数式処理, Vol 7, No 2, 2--17. (ISBN4-87243-086-7, SEG 出版, Tokyo). \bibitem{OpenXM-1999} 野呂正行, 高山信毅: {Open XM の設計と実装 --- Open message eXchange protocol for Mathematics}, 1999/11/22 \end{thebibliography} \end{document}