メインコンテンツまでスキップ

適応可能なメカニズム

我々は、Network を念頭に置かずに計画され、疑いなく、Network への導入時点で存在する Network 標準に容易には従わないであろう問題プログラムを、Network での使用に適応させたいと考えている。 この非互換性の問題は、異なるホストハードウェアと同様に、Network の基礎をなす研究の根本的な一部である。 そのような各プログラムに大規模なフロントエンドを要求することは、妥当な目標ではない。 我々は Network を、a) サービスを提供するホスト、b) サービスに端末を接続する寄生ホスト、c) サービスの利用者と提供者の双方として振る舞うホストのスペクトル、の集合体と見なしている。 各寄生ホストが、その利用者が必要とするすべてのサービスについて異なるプロトコルとデータ形式を扱うことを要求するのは、妥当な目標ではない。 その結果、通信を望みながら同じ言語を話さないプログラムと端末が生じる。

プロトコルとデータ形式の問題への一つのアプローチは、プログラムと端末が Network 資源に容易にアクセスするために使用できる適応可能なメカニズムを提供することである。 ARPA は Rand で Adaptive Communicator Project を支援しており、これは人をプログラムに接続するための教示可能なフロントエンドプロセスを調査する研究活動である。 調査されている多様な端末装置には、音声、タブレット、高度なグラフィックス端末などが含まれる。

Adaptive Communicator は非常に有望に見えるが、しばらくの間は利用可能にならない。 Rand の Network Project は、適応可能なアプローチ（適応的ではない、すなわちヒューリスティクスなし、自己学習なし）を取ることを選んだ。 我々の問題は、Rand の研究者が、異なるプログラムプロトコルとデータ構成を要求する異なる同時アプリケーションを持っていると仮定して、彼らを容易に Network に参加させることである。

適応とは何を意味するかを示すために、プロトコルとデータ形式を別々に記述する。 プロトコルは、NCP コマンドに対応する（そして NCP によるその発行をもたらす）「システムコール」のシーケンスである。 データ形式は通常のメッセージ内容の記述であり、NCP にとって意味を持たない。

Form Machine（データ形式への適応）​

読者に文脈を伝えるために述べると、Form Machine は、ある形式の 正規 表現_を認識する有限状態機械のクラスに属し、我々の場合それがデータ形式を記述する。 しかしながらこの記法は特定の記述を目的としているため、我々の目的にとっては、正規表現の言語よりも簡潔でありうる。

Form Machine は、データ形式の要件が異なる多様なプログラムと端末を結合する実験的なソフトウェアパッケージである。 我々は、Form Machine が（ネットワークトラフィックを削減するために）さまざまなサービス提供ホストに配置されることを想定している。

Form Machine のアイデアを試すために、我々は IBM OS から呼び出し可能な二つのサブルーチンを実装している。すなわち、データ形式の形式を記述する文をコンパイルするコンパイラと、コンパイルされた形式をデータストリーム上で実行する実行者である。

Form Machine のテストを説明するには、Rand にある別のプログラム——Network Services Program (NSP)——に言及する必要がある。これは、Network Control Program を任意のプログラムと Video Graphics Consoles の双方に接続する多重アクセスプログラムである。 （我々は端末を、異なるインターフェースを持つ単なる別のプログラムと見なしている。すなわち、# 文字/行、# 行/ページ、固有のハードウェア機能、それが置かれるアプリケーションなどである。） Form Machine のサブルーチンは、コンソールまたはプログラムの指示に応じて NSP から呼び出し可能である。

運用上、コンソールの利用者は、自分が使用するデータ形式に名前を付け、指定する。 その形式はコンパイルされ、後で使用するために保存される。 将来、利用者が Network 接続を確立しデータを伝送したいと望む時点で、利用者は名前を付けた形式を、ポート——象徴的に名付けられた Network 全二重接続——の各側に動的に関連付ける。 受信または送信されるデータストリームはコンパイルされた形式に従って実行され、変換されたデータストリームはその後、それぞれコンソール／プログラムまたは Network へ渡される。

我々の Form Machine 記法の構文の詳細は、ネットワークコミュニティ全体にとって重要ではない。 しかしながら、その記法が備える機能は関心の対象である。 それは最終的に、高性能 CRT ディスプレイ、TTY、および任意のファイル構造の記述を包含することになる。 その実現可能性を試すために、そのような機能の一部分が実装されている。

現在の版は、以下の機能によって特徴付けられる:

  1. 文字コード変換（すなわち、十進、八進、十六進、8 ビット ASCII、7 ビット ASCII、EBCDIC、および二進）。

  2. 複数の区切り文字列（多くの端末は複数の終了信号を持つ）。

  3. リテラルの挿入（主に表示情報の提示に用いられる）。

  4. 任意の文字列のスキップまたは削除（表示されるべきでないレコードシーケンス番号などを除去するために用いられる）。

  5. レコードシーケンス番号の生成。

  6. 文字列長の計算と挿入。

  7. 任意 のデータ文字列長指定。例えば、「十六進リテラル文字列の後に 任意 個の EBCDIC 文字が続き、その後に区切り文字列が続く、……」。

  8. Network メッセージの連結。すなわち、不完全なデータ文字列に対してコンパイル済み形式を実行すること。

  9. データフィールドの転置。

  10. 単一行メッセージと複数行メッセージの双方に対する、明示的および不定の乗数。

実装されていないが、成功すれば追加される予定の機能には、次のものが含まれる:

  1. グラフィックス指向の記述。

  2. 一般的な数値変換。

  3. 条件文。

  4. ポインタ機能。

Protocol Manager（NCP コマンドシーケンスへの適応）​

NSP は、端末利用者とプログラムが NCP プロトコルレベルで作業することを可能にする。すなわち、LISTEN、INIT などである。 また、それら自身にとってのみ意味のある情報を伝送し加工することも可能にする。 この「ハンズオン」のアプローチは、システムプログラマの観点、あるいは探求的な観点から望ましい。 しかしながら、与えられた遠隔プログラムを繰り返し使用する研究者にとっては、「定型の」プロトコルシーケンスを定義し、保存し、取り出し、実行できるようにすることで、面倒な「ハンドシェイク」を排除することが望ましい。

我々は現在、NCP コマンドシーケンスに対して上記の操作を可能にする、NSP のモジュールとしての Protocol Manager を仕様化している。 このモジュールの機能は次のとおりである:

  1. シーケンスは「ブレークポイント」を含むことができ、これによりコンソール利用者は文脈上必要な任意の情報を動的に挿入できる。

  2. コマンドのパラメータは、プロトコル対話の間に遠隔側から値が供給されるトークンを含むことができる。 例えば、Note #66 において、サーバーが提供するソケット番号は、ユーザーが後続の RTS、STR コマンドで使用することになっている。