KONOEコマンドメッセージング階層

1.はじめに

KONOEでは、たくさんのプロセスが分散した計算機の上で通信しながら走ることで 様々な機能を実現していきます。それらのプロセスを制御するための機構が 必要となります。

それらは、通常、コマンドメッセージの形態をとります。あるプロセスへコマンドを 送信すると、そのプロセスはそれを解読・実行し、その結果をリプライメッセージと して、送り手へ返送します。

2.コマンド送信経路の確立

コマンドの送受信はTCPソケットを使って行われます。通常、コマンドを解読 実行するプロセスは、様々なプロセスからコマンドを受け付けることになります。 そのためには、コマンドを実行するプロセスがサーバ、送る側のプロセスが クライアントとなるモデルが自然です。

コマンドはたとえばデバッグなどのためにポート番号を指定したtelnetなどで 送るような場合も考えられます。そのような使用を考えた場合、コマンドや リプライは可読なテキストであるべきです。

コマンドが正しく受け取られ、処理されたことを確認するために、コマンドには 必ずリプライを返す「コールアンドレスポンス」スキームを採用すべきです。 コマンドを送る側はそのために、リプライを受け取る制限時間を設定して 時間切れを監視する機構を持つべきです。時間切れはエラーとして通知される 必要があります。

3.コマンドの解読・実行

コマンドやリプライは上に述べたように可読なテキストとして記述されます。 それらを解読実行するためには厳密な文法が必要になります。KONOE独自の コマンド文法を採用することになります。まずコマンドですが、それが どのホストのどのプロセスへのコマンドであるかを表す必要があります。さらに、 あるプロセスは内部に多くのオブジェクトを持っています。KONOEではそれらの オブジェクトがコマンドの実行主体であると考えます。ですから、コマンドを 受け付けるオブジェクトを識別できなければなりません。

対象となるオブジェクトが指定されると、それに命令文を与えます。それは そのオブジェクトのメソッド呼び出しに対応します。メソッド名である 動詞と、それが必要とする引数のリストを与えます。

コマンドに対するリプライもテキストで返されます。これはどのオブジェクト からのリプライであるかを情報として持っていなければなりません。リプライは 必ずしも厳密な文法に従う必要はないかもしれません。たとえば人間がその リプライを読む場合はそうです。しかし、一般的にはあるプロセスがリプライを 解読する場合も考えなければなりません。リプライメッセージの文法を検討する ことは意味があります。

コマンド文法としては繰り返しや条件分岐、手続きや関数の呼び出しなど、 シェルスクリプトとしての機能を持たせたいものです。この場合、一行一行の 命令を実行するオブジェクトと流れ制御を行うオブジェクトは同じである必要は ありません。フロントエンドのプロセスが流れ制御を受け持ち、一行一行の命令を 該当するオブジェクトへ送るサービスを行うことになります。

概要へ戻る 目次へ戻る 次章「KONOEを構成するプロセス」へ


[intro/cmdmsg.html] Last Modified : 13-Mar-2001.

KONOEコラボレーション konoe-req@konoe.kek.jp