高レベルプロトコル

ネットワークは、ユーザーと外部ホスト内の特定のサブシステムとの間に高度な対話が必要とされる場合に、特別な問題を提起します。これらの問題は、異種のコンソール、ローカルオペレーティングシステムのオーバーヘッド、およびネットワーク伝送遅延に起因して生じます。特別な方策を用いない限り、遠隔ユーザーが提供されるより洗練されたサブシステムを利用することは困難か、あるいは不可能でさえあるかもしれません。これらの困難はグラフィックスの領域で特に深刻ですが、テレタイプの対話においてさえ問題が生じる可能性があります。たとえば、外部のサブシステムが電話で接続されたテレタイプコンソール向けに設計されており、その後このサブシステムがネットワークユーザーにも利用可能になったとします。このサブシステムは以下の特性を持つかもしれません。

エコーと誤入力の訂正を除いて、キャリッジリターンが入力されるまで何の動作も行われません。
"^"、および "<-" とキャリッジリターンを除くすべての文字は、入力された時点でエコーされます。
<- は直前の文字を削除し、その文字としてエコーされます。
^ は以前に入力されたすべての文字を無視させます。キャリッジリターンとラインフィードがエコーされます。
キャリッジリターンは、キャリッジリターンに続くラインフィードとしてエコーされます。

入力された各文字がそれぞれ独自のメッセージで送られる場合、次の文字列は

H E L L O <- <- P c.r.

各方向に9つのメッセージを引き起こします。さらに、各文字は外部ホストへ送られる前に、ローカルホスト内のユーザーレベルプログラムによって処理されます。

さて、この特定の例が重要であるなら、私たちは規則 1 から 5 をローカルホストのプログラムに迅速に実装し、完成した行だけを外部ホストへ送るであろうことは明らかです。外部ホストのプログラムを、エコーを生成しないように変更できない場合、ローカルプログラムは適切にエコーできるだけでなく、外部ホストからの後続のエコーを捨て去ることもできます。しかし、問題は特定の対話方式ではありません。問題は、この種の方式が多数生じることを私たちが予想していることです。私たちはこれらの問題に対する一般的な解決策をまだ見つけていませんが、いくつかの観察と推測が道を開くかもしれません。

異種のコンソールに関して、コンソールが互換であることはまれですが、多くは等価であることに注意します。モデル 37 のテレタイプを IBM 2741 の等価物として扱うことは、おそらく妥当でしょう。同様に、ほとんどのストレージスコープは1つの等価類を形成し、ほとんどのリフレッシュ表示スコープは別の等価類を形成します。さらに、あるクラスのメンバーを別のクラスのものの代わりに使用できるが、その逆はできないという階層が生じるかもしれません。任意のスコープがテレタイプの適切な代替となりうるが、その逆はほとんどありえない、と私たちは想像できます。この観察から、コンソールのためのネットワーク全体にわたる言語が可能かどうかという疑問が生じます。そのような言語は、異なるクラスのコンソールを別々に扱うことを可能にし、各クラスに適した意味論を備えるでしょう。そうすれば各サイトは、自分のコンソールをネットワーク標準装置のように見せるためのインターフェースプログラムを書くことができます。

もう一つの観察は、ユーザーはシステムの応答速度を自分自身の期待と比較することによって対話システムを評価するということです。ユーザーが自分は些細な要求しかしていないと感じるときは、応答は即座であるべきです。別のときには、自分は実質的な要求をしたと感じ、したがって応答を待つ用意があります。いくつかの対話サブシステムは、応答をユーザーの期待に合わせて仕立てるために多大な労力が注がれているため、特に快適に使用できます。しかしネットワークでは、ローカルユーザーレベルのプロセスがローカルコンソールと外部サブシステムの間に介在し、些細な要求に対する応答時間が低下すると予想されます。さて、この対話の仕立て上げのすべてが、重い計算や I/O を行うサブシステムの部分とはかなり独立していることがあるかもしれません。そのような場合、サブシステムを2つの部分に分離できる可能性があります。一方の部分は、ユーザーへの出力をフォーマットし、ユーザーの入力を受理し、エコーのような計算上単純な応答を制御する「フロントエンド」です。上記の例では、1行を蓄積してエコーを生成するプログラムが、あるサブシステムのフロントエンドとなるでしょう。ここで私たちは、ローカルホストが相当な計算能力を持っているにもかかわらず、現在の設計ではローカルホストをデータ集中装置としてしか利用していないという事実に気づきます。これはいくらか皮肉なことです。なぜなら、ローカルホストはデータ集中装置として十分に活用されていないだけでなく、それが導入する遅延のために性能を低下させるからです。

これらの議論は、対話サブシステムのフロントエンドを書くためのネットワーク全体にわたる言語である、ネットワークインターフェース言語 (NIL) の可能性を検討するに至りました。この言語は、サブプログラムがネットワークのような接続を通じて通信するという特徴を持つでしょう。戦略は、サブシステムのフロントエンドのソースコードをローカルホストへ移送し、そこでコンパイルして実行することです。

予備的な議論の中で、私たちは NIL が、他の言語には一般に見られない少なくとも以下の意味論的性質を持つべきであることに合意しました。

並行性。メッセージは異なる接続上で非同期に到着し、ユーザー入力はサブシステムの出力と同期していないため、NIL は起こりうる並行性を正確にモデル化する意味論を含まなければなりません。
プログラムの連結。あるプログラムを他の2つのプログラムの間に挿入できることは非常に有用です。これを実現するには、プログラムの相互接続が実行時に指定され、ソースコードに暗黙的に含まれないようにします。
装置の代替可能性。ある装置を別の装置で置き換えられるように言語を定義するのは普通のことです。ここでの要件は、任意の装置が NIL プログラムによってモデル化できることです。たとえば、ネットワーク標準の表示制御装置が、それに送られるメッセージに従って木構造を操作する場合、これらの構造は NIL で容易に実装可能でなければなりません。

NIL はまだ完全には仕様化されておらず、その有用性について懸念が表明されています。これらの懸念は、対話システムを、ユーザーの期待を低コストで満たす移送可能なフロントエンドと、より実質的な本拠側の部分に分割することが可能であるという私たちの推測にかかっています。もしこの推測が誤りであれば、NIL は有用ではないでしょう。そうでなければ、追求する価値があると思われます。この推測の検証と NIL のさらなる開発は、低レベルの HOST-HOST プロトコルが安定した後に優先されるでしょう。