III. ホストソフトウェア
接続の確立
私たちが想像できる最もシンプルな接続は、ローカルホストがTTYとして機能し、リモートホストにダイヤルアップする場合です。このような接続の開始と終了の問題を検討した後、ホストオペレーティングシステム間の通信のためにリンク0を予約することが決定されました。したがって、残りの31のリンクはダイヤルアップ回線として使用されます。
各ホストオペレーティングシステムは、そのユーザーレベルプログラムに、リモートホストとの接続を確立するためのプリミティブ (primitive) と、接続を切断するためのプリミティブを提供しなければなりません。これらのプリミティブが呼び出されると、オペレーティングシステムは空きリンクを選択し、選択したリンク上での接続を要求するメッセージをリンク0を介してリモートホストに送信しなければなりません。リモートホストのオペレーティングシステムは同意し、リンク0を介して受諾メッセージを送り返さなければなりません。両方のホストが接続を開始するために同じリンクを選択し、両方が本質的に同時に要求メッセージを送信する場合、単純な優先度スキームが呼び出され、優先度の低いホストが譲歩して別の空きリンクを選択します。使用可能な優先度スキームの1つは、単純にホストを識別番号でランク付けすることです。両方のホストが同時要求が行われたことを認識していますが、補完的なアクションを取ることに注意してください:優先度の高いホストは要求を無視し、優先度の低いホストは受諾と別の要求の両方を送信します。
このように確立された接続は、ログイン前の状態のTTYライクな接続です。これは、リモートホストオペレーティングシステムが最初にリンクをTTYがダイヤルアップしたかのように扱うことを意味します。リモートホストは同じエコーを生成し、同じログインシーケンスを期待し、同じ割り込み文字を探します。
大容量伝送
端末として機能するテレタイプには、大きなファイルの伝送を考えるときに2つの特別な欠点があります。1つ目は、一部の文字が特別な割り込み文字であることです。2つ目は、特別なバッファリング技術がよく採用されますが、これらは低速の文字単位の伝送にのみ適しています。
したがって、ファイルまたはその他の大量のデータの伝送に使用する別のクラスの接続を定義します。このクラスのリンクを開始するには、確立されたTTYライクなリンクの両端のユーザーレベルプログラムが、TTYライクなリンクと並行してファイルライクな接続の確立を要求しなければなりません。優先度スキームが再び機能します。優先度の高いホストがリンク0を介してメッセージを送信し、優先度の低いホストはそれを待ちます。もちろん、ユーザーレベルプログラムはこれを気にしません。空きリンクの選択は、優先度の高いホストによって行われます。
ファイルライクなリンクは、割り込み文字の検索が行われず、より高いデータレートに適したバッファリング技術が採用されるという点で区別されます。
プリミティブの要約
各ホストオペレーティングシステムは、そのユーザーに少なくとも以下のプリミティブを提供しなければなりません。このリストは必要であることが知られていますが、十分ではありません。
a) ホストxとのTTYライクな接続を開始する
b) 接続を終了する
c) TTYライクな接続を介して文字を送信/受信する
d) TTYライクな接続と並行してファイルライクな接続を開始する
e) ファイルライクな接続を終了する
f) ファイルライクな接続を介して送信/受信する
エラーチェック
各メッセージは、IMPに対して透過的な、その本体にメッセージ番号、ビットカウント、およびチェックサムを運ぶことを提案します。チェックサムについては、1152ビットで計算され、次に循環的に右に1ビットシフトされる16ビットのエンドアラウンドキャリーサム (end-around-carry sum) を提案します。1152ビットごとの右循環シフトは、IMPによるメッセージの再組み立てのエラーをキャッチするように設計されています。
より密接な相互作用
上記のプリミティブは、ユーザーがリモート施設を簡単に使用する方法を示唆しています。ネットワークのより複雑な使用がどのように実行されるかについては何も明らかにしていません。具体的には、一部のサイトでは、コンピュータを高度なコンソールに非常に応答性の高いものにするために多くの作業が投入されているという事実に関心があります。UCSBのCullerコンソールとSRIのEnglebartコンソールは、少なくとも2つの例です。些細なエコーのような応答に対して0.5秒程度の遅延が、コンソールの高度さを無関係にする程度まで相互作用を低下させることは明らかです。
ほとんどのコンソール相互作用は2つの部分に分割できると考えています。本質的にローカルで即時かつ些細な部分と、リモートでより長く重要な部分です。簡単な例として、キーボードとリフレッシュディスプレイ画面で構成されるコンソールにいるユーザーを考えてみましょう。ユーザーが入力しているプログラムは、キャリッジリターンに遭遇するまで文字列を蓄積し、次に文字列を処理します。文字が入力されている間、画面に文字を表示します。ルバウト文字 (rubout) が入力されると、前の非ルバウト文字を削除します。ユーザーが H E L L O <- <- P <CR> を入力した場合 (<- はルバウト、<CR> はキャリッジリターン)、9回のキーストロークを行ったことになります。これらのキーストロークのそれぞれがメッセージの送信を引き起こし、そのメッセージが今度はディスプレイステーションへの命令を呼び出す場合、すぐに退屈になります。
より良い解決策は、リモートプログラムのフロントエンド -- つまり <- と <CR> をスキャンする部分 -- が私たちのコンピュータに常駐することです。その場合、5文字のメッセージ、つまり H E L P <CR> のみが送信され、画面はローカルで管理されます。
このソリューションを実装するために、コンソール制御用の言語を作成することを提案します。この言語は、現在DELと名付けられており、サブシステム設計者が端末に必要なコンポーネントと、端末がキーボード、Lincoln Wandなどからの入力にどのように応答するかを指定するために使用されます。次に、初期プロトコルの一部として、リモートホストはローカルホストに、コンソールを制御するプログラムのソース言語テキストを送信します。このプログラムはサブシステム設計者によってDELで記述されますが、ローカルでコンパイルされます。
DELの仕様は議論中です。以下の図は操作のシーケンスを示しています。
A. リンク確立前
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
B. リンク確立とログイン後
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
C. DELプログラムの受信とコンパイル後
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
未解決の問題
-
IMPがコード変換を行う場合、チェックサムは正しくありません。
-
DELフロントエンドを要求する手順はまだ指定されていません。