version 1.32, 1999/12/21 10:02:03 |
version 1.39, 1999/12/21 20:02:51 |
|
|
|
|
\title{タイトル未定} |
\title{タイトル未定} |
\author{ |
\author{ |
前川 将秀, |
前川 将秀\thanks{神戸大学理学部数学科}, |
野呂 正行, |
野呂 正行\thanks{富士通研究所}, |
小原 功任, \\ |
小原 功任\thanks{金沢大学理学部計算科学科}, \\ |
奥谷 幸夫, |
奥谷 幸夫 |
高山 信毅, |
%\thanks{神戸大学大学院自然科学研究科博士課程前期課程数学専攻}, |
|
\thanks{神戸大学大学院自然科学研究科数学専攻}, |
|
高山 信毅\thanks{神戸大学理学部数学教室}, |
田村 恭士 |
田村 恭士 |
|
%\thanks{神戸大学大学院自然科学研究科博士課程後期課程情報メディア科学専攻計算システム講座} |
|
\thanks{神戸大学大学院自然科学研究科情報メディア科学専攻} |
} |
} |
\date{1999年11月25日} |
\date{1999年11月25日} |
%\pagestyle{empty} |
%\pagestyle{empty} |
Line 44 OpenXM 規約独自のデータ形式である CMO 形式(Common Math |
|
Line 48 OpenXM 規約独自のデータ形式である CMO 形式(Common Math |
|
|
|
\section{OpenXM の計算モデル} |
\section{OpenXM の計算モデル} |
|
|
{\Huge この節では計算モデルの話をしなければいけませんよ、田村君} |
{\Huge この節では計算モデルの話をしなければいけません} |
|
|
OpenXM 規約でのメッセージの交換はサーバとクライアントの間で行なわれる。 |
OpenXM 規約での計算とはメッセージを交換することである。 |
|
そして、そのメッセージの交換はサーバとクライアントの間で行なわれる。 |
クライアントからサーバへメッセージを送り、 |
クライアントからサーバへメッセージを送り、 |
メッセージに対する返答を |
サーバからクライアントがメッセージを受け取ることによって |
|
計算の結果が得られる。 |
|
|
サーバはスタックマシンであると仮定されており、 |
サーバはスタックマシンであると仮定されており、 |
サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。 |
サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。 |
OpenXM のメッセージの中にはサーバに行なわせたい動作に対応するデータがあり、 |
ただし、OpenXM のメッセージの中にはサーバに行なわせたい動作に |
|
対応するデータがあり、 |
このメッセージを受け取ったサーバはそれに対応する動作を |
このメッセージを受け取ったサーバはそれに対応する動作を |
行なうことが期待されている。 |
行なうことが期待されている。 |
ただし、サーバは命令されない限り何も動作を行なおうとはしない。 |
しかし、サーバは命令されない限り何も動作を行なおうとはしない。 |
このため、クライアントはサーバへ送ったメッセージの結果を |
このため、クライアントはサーバの状態を気にせずにメッセージを送り、 |
サーバから |
一旦メッセージを送付し終えた後、 |
|
サーバへ送ったメッセージの結果を |
|
サーバから待つことなしに次の動作に移ることができる。 |
|
|
これはクライアントがサーバへ一旦メッセージを送付し終えると、 |
なお、サーバに対する動作に対応したデータは SM 形式として定義されている。 |
あとはサーバ側の状態を気にせずにクライアントは |
SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む |
クライアント自身の仕事に戻れることを意味する。 |
以外の動作をしないことになっている。 |
|
つまり、 SM 形式のデータがサーバにデータを受け取る以外の動作を |
|
行なわせる唯一のデータ形式である。 |
|
|
|
|
\section{OpenXM のメッセージの構造} |
\section{OpenXM のメッセージの構造} |
|
|
{\Huge この節では構造の話をしなければいけませんよ、田村君} |
%{\Huge この節では構造の話をしなければいけません} |
|
|
OpenXM のメッセージはバイトストリームであり、次のような構造を持つ。 |
OpenXM で規定されているメッセージはバイトストリームであり、 |
\begin{verbatim} |
次のような構造になっている。 |
ヘッダ ボディ |
|
\end{verbatim} |
\begin{tabular}{|c|c|} \hline |
ヘッダの長さは8バイトであると定められている。ボディの長さはメッセージご |
ヘッダ & \hspace{10mm} ボディ \hspace{10mm} \\ \hline |
とに異なる($0$でもよい)。 |
\end{tabular} |
ヘッダは次の二つの情報を持つ。 |
|
|
ヘッダの長さは 8 バイトであると定められている。 |
|
ボディの長さはメッセージごとに異なっているが、 |
|
長さは $0$ でもよいことになっている |
|
%なお、すべてのメッセージに ボディが必要というわけではなく、 |
|
%ボディのないメッセージも OpenXM 規約には存在することに |
|
%注意しなければならない。 |
|
|
|
ヘッダは次の二つの情報を持っている。 |
\begin{enumerate} |
\begin{enumerate} |
\item 前半の4バイト。タグと呼ばれ、メッセージの種類を表わす識別子である。 |
\item 前半の 4 バイトにある、メッセージの種類を表わす識別子。 |
\item 後半の4バイト。メッセージにつけられた通し番号である。 |
タグと呼ばれる。 |
|
\item 後半の 4 バイトにある、メッセージにつけられた通し番号。 |
\end{enumerate} |
\end{enumerate} |
|
それぞれの 4 バイトは 32 ビット整数とみなされて扱われる。 |
|
この場合に用いられる整数の表現方法の説明については後述するが、 |
|
基本的に表現方法はいくつかの選択肢から選ぶことが可能となっており、 |
|
またその選択は通信路の確立時に一度だけなされることに注意しなければならない。 |
|
|
それぞれの4バイトは32ビット整数とみなされて処理される。 |
%{\Huge 以下、書き直し} |
この場合に用いられる整数の表現方法については後述するが、基本的に |
|
表現方法はいくつかの選択肢から選ぶことが可能であり、 |
|
また選択は通信路の確立時に一度だけなされることに注意しておこう。 |
|
|
|
{\Huge 以下、書き直してね。} |
ボディの中身は各データ形式によって |
|
それぞれ独立に決められるようになっている。 |
|
もし、 OpenXM 規約でまだ定義されていないデータ形式を使いたい場合は、 |
|
メッセージのヘッダのタグをまだ使われてない整数値に設定し、 |
|
ボディにデータを埋め込めばよい。 |
|
なお、このような用途にも使えるように、 |
|
タグにはシステム固有の表現用に推奨されている整数の範囲がある。 |
|
|
ボディの中のデータがどのように格納されているかは |
|
各データ形式がそれぞれ独立に決められるようになっている。 |
|
もし、 OpenXM 規約でメッセージのやりとりを行ないたいが、 |
|
まだ規約で定義されていないデータ形式を使いたい場合は、 |
|
タグをまだ使われてなさそうな値 |
|
(システム固有の表現のために推奨されている値がある) |
|
に設定し、 ボディの部分にデータを埋め込めばよい。 |
|
なお、すべてのメッセージに ボディが必要というわけではなく、 |
|
ボディのないメッセージも OpenXM 規約には存在することに |
|
注意しなければならない。 |
|
|
|
サーバに対する動作に対応したデータは SM 形式として定義されている。 |
|
SM 形式以外のデータでは、サーバは受け取ったデータをスタックに積む |
|
以外の動作をしないことになっている。 |
|
つまり、 SM 形式のデータがデータを受け取る以外の動作を |
|
サーバに行なわせる唯一のデータ形式である。 |
|
このデータを受け取る以外の動作の中には、 |
|
データになんらかの加工を施す動作も入っている。 |
|
このデータになんらかの加工を施す動作の中には |
|
数学的な演算を行なう動作も含まれている。 |
|
以後、データになんらかの加工を施す動作のことを計算と呼ぶことにする。 |
|
|
|
\section{OpenXM の計算の進行方法} |
\section{OpenXM の計算の進行方法} |
|
|
OpenXM における計算とはメッセージの交換のことである。既に計算モデルの節 |
OpenXM における計算とはメッセージの交換のことである。 |
で説明したが(説明されているはずである)、OpenXM はサーバ・クライアントモ |
既に計算モデルの節で説明したが、 |
デルを採用していて、サーバはスタックマシンの構造を持つ。サーバが行うのは |
OpenXM はサーバ・クライアントモデルを採用していて、 |
基本的に次の事柄に限られる。クライアントからメッセージを送られるとサーバ |
サーバはスタックマシンの構造を持つ。 |
は、まずメッセージの識別子を調べ、OX\_COMMAND でなければスタックに積む。 |
サーバが行うのは基本的に次の事柄に限られる。 |
OX\_COMMAND であればメッセージのボディからスタックマシンのオペコードを取 |
クライアントからメッセージを受け取るとサーバは、 |
りだし、あらかじめ規約で定められたアクションを起こす。 |
まずメッセージの識別子を調べ、 SM 形式のデータでなければスタックに積む。 |
|
SM 形式のデータであればメッセージのボディから |
|
スタックマシンのオペコードを取りだし、 |
|
あらかじめ規約で定められた動作を行なう。 |
|
|
上の説明でわかるように、サーバはクライアントからの指示なしに、自らメッセー |
%上の説明でわかるように、 |
ジを送ることはない(例外? ox\_asir の mathcap)。 |
サーバはクライアントからの指示なしに、 |
|
自らメッセージを送らないことに注意しなければならない。 |
|
%(例外? ox\_asir の mathcap)。 |
|
|
{\Huge 以下、書き直してね、田村君} |
|
|
|
|
|
% クライアントがサーバへなんらかの計算を行なわせる場合、 |
|
% クライアントからサーバへ計算させたいデータをメッセージとして送り、 |
|
% そしてその結果をサーバからメッセージで受け取ることによって計算は行なわれる。 |
|
% ただし、サーバは結果の送信すらも命令されなければ行なうことはなく、 |
|
% クライアントは結果を受け取らずにサーバに次々と |
|
% 計算を行なわせることも可能である。 |
|
|
|
サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。 |
サーバがクライアントから受け取ったメッセージはすべてスタックに積まれる。 |
ただし、このままでは受け取ったメッセージに含まれるデータを |
次いでサーバに SM 形式のデータを送ると、 |
スタックに積み上げていくだけで、サーバは計算を行なおうとはしない。 |
初めてサーバはデータをスタックに積む以外のなんらかの動作を行なう。 |
次いでサーバに行なわせたい動作に対応したデータを送ると、 |
|
初めてサーバは計算などの、なんらかの動作を行なう。 |
|
このとき、必要があればサーバはスタックから必要なだけデータを取り出す。 |
このとき、必要があればサーバはスタックから必要なだけデータを取り出す。 |
ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても |
ここで、クライアントからの命令による動作中にたとえエラーが発生したとしても |
サーバはエラーオブジェクトをスタックに積むだけで、 |
サーバはエラーオブジェクトをスタックに積むだけで、 |
Line 148 OX\_COMMAND であればメッセージのボディからスタックマシ |
|
Line 147 OX\_COMMAND であればメッセージのボディからスタックマシ |
|
スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを |
スタックからデータを取り出し送信を行なう命令に対応した SM 形式のデータを |
サーバ側へ送ればよい。 |
サーバ側へ送ればよい。 |
|
|
|
{\Huge 以下、書き直し} |
|
|
クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、 |
クライアントがサーバへ計算を行なわせ、結果を得るという手順を追っていくと、 |
次のようになる。 |
次のようになる。 |
|
|
Line 259 OpenXM 対応版の asir サーバである ox\_asir が返す Math |
|
Line 260 OpenXM 対応版の asir サーバである ox\_asir が返す Math |
|
] |
] |
\end{verbatim} |
\end{verbatim} |
|
|
<<<<<<< genkou19991125.tex |
|
この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。 |
この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。 |
最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。 |
最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。 |
%この最初の要素がまたリスト構造となっており、 |
%この最初の要素がまたリスト構造となっており、 |
Line 381 OpenXM 規格に対応したサーバを呼び出すことができる。 |
|
Line 381 OpenXM 規格に対応したサーバを呼び出すことができる。 |
|
また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の |
また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の |
データを変換するソフトウェアが JAVA によって実装されており、 |
データを変換するソフトウェアが JAVA によって実装されており、 |
OMproxy という名前で提供されている。 |
OMproxy という名前で提供されている。 |
======= |
|
この MathCap データのリスト構造は大きく分けて 3 つの部分に分かれる。 |
|
最初の {\tt [199901160,"ox\_asir"]} の部分にはサーバの情報が入っている。 |
|
%この最初の要素がまたリスト構造となっており、 |
|
最初の要素はバージョンナンバーを、次の要素はサーバの名前を表している。 |
|
|
|
次の {\tt [276,275,$\cdots$,271]} の部分は |
|
サーバに対する動作に対応した理解可能なデータの種類を表している。 |
|
サーバの動作に対するデータはすべて 32 bit の整数で表しており、 |
|
このリストは理解可能なデータに対応する 32 bit 整数のリストとなっている。 |
|
|
|
最後の {\tt [ [514,[1,2,3,$\cdots$,60]],[2144202544,[0,1]] ]} の部分は |
|
理解可能なデータの形式を表している。 |
|
この部分はさらに {\tt [514,[1,2,3,$\cdots$,60]]} と |
|
{\tt [2144202544,[0,1]]} にの部分に分けることができ、 |
|
それぞれが一つのデータ形式についての情報となっている。 |
|
どのデータ形式についての情報かは最初の要素にある整数値をみれば |
|
分かるようになっている。 |
|
この整数値は CMO 形式では 514 となっている。 |
|
最初のデータ形式を区別する整数値以後の要素は |
|
各データ形式によってどのように使われるか定まっている。 |
|
CMO 形式では理解可能なデータのタグがリストの中に収まっている。 |
|
前節で CMO 形式では多倍長整数を表すタグが 20 であることを述べたが、 |
|
このリストに 20 が含まれているので、 |
|
ox\_asir は CMO 形式の多倍長整数を受け取れることがわかる。 |
|
|
|
なお、データが受け取れることと、 |
|
データの論理構造が理解できることとはまったく別物であるので |
|
注意する必要がある。 |
|
|
|
|
|
\section{セキュリティ対策} |
|
|
|
OpenXM では幾らかのセキュリティ対策を考えている。 |
|
OpenXM に対応したソフトウェアをクラックしても |
|
大した利点はないと思えるが、それは設計上の話であって、 |
|
予期せぬ手段で攻撃を受けた場合にどのような事態を |
|
招くかは想像し難い。 |
|
|
|
そこで、 OpenXM では侵入者に攻撃の機会を |
|
できるだけ与えないようにしている。 |
|
具体的には、接続が必要になった時のみ接続を待つようにし、 |
|
常に接続に関与するといったことは避けている。 |
|
|
|
しかし、これだけでは侵入者が接続を行なう一瞬のすきを |
|
狙ってくる可能性もある。 |
|
そこで接続を行なう時に、 |
|
接続を待つ port 番号をランダムに決めている。 |
|
こうすることで、特定の port 番号を狙って接続を行なう |
|
瞬間を待つ手口を幾らか防ぐことができる。 |
|
|
|
さらにもう一段安全性を高めるために、 |
|
接続時に 1 回だけ使用可能なパスワードを作成し、 |
|
そのパスワードを使って認証を行なう。 |
|
このパスワードは一旦使用されれば無効にするので、 |
|
もし仮になんらかの手段でパスワードが洩れたとしても安全である。 |
|
|
|
なお、上記の port 番号とパスワードは安全な手段で送られて |
|
いると仮定している。 |
|
また、同一のコンピュータ上に悪意のあるユーザはいないと仮定している |
|
ことに注意しなければならない。 |
|
なぜなら、現在の実装ではサーバ、およびクライアントの動作している |
|
コンピュータ上ではこの port 番号とパスワードがわかってしまうためである。 |
|
|
|
なお、接続が確立した後のメッセージの送受信に関しては、 |
|
特に暗号化などの処置が行なわれているわけではない。 |
|
もし必要があれば、通信路の暗号化を行なう機能がある |
|
ソフトウェアを使うことを考えている。 |
|
|
|
|
|
\section{他のプロジェクト} |
|
|
|
他のプロジェクトについて幾つか紹介する。 |
|
|
|
OpenMath プロジェクトは数学的なオブジェクトを |
|
コンピュータ上で表現する方法を決定している。 |
|
各ソフトウェア間でオブジェクトを交換する際の |
|
オブジェクトの変換手順についても述べられている。 |
|
表現方法は一つだけでなく、 XML 表現や binary 表現などが |
|
用意されている。 |
|
|
|
%以下、調べる必要あり。 |
|
%NetSolve |
|
|
|
%MP |
|
|
|
%MCP |
|
|
|
\section{現在提供されているソフトウェア} |
|
|
|
現在 OpenXM 規格に対応しているクライアントソフトウェアには |
|
asir, sm1, Mathematica がある。 |
|
これらのクライアントソフトウェアから |
|
OpenXM 規格に対応したサーバを呼び出すことができる。 |
|
現在 OpenXM 規約に対応しているサーバソフトウェアには、 |
|
asir, sm1, gnuplot, Mathematica などがあり、 |
|
それぞれ ox\_asir, ox\_sm1, ox\_math という名前で提供されている。 |
|
また、 OpenMath 規格の XML 表現で表現されたデータと CMO 形式の |
|
データを変換するソフトウェアが JAVA によって実装されており、 |
|
OMproxy という名前で提供されている。 |
|
>>>>>>> 1.30 |
|
|
|
\end{document} |
\end{document} |