要約

  • RFC 1116は行編集と一部の信号処理をTelnetクライアントへ置いた。キーごとの通信を行ごとの少数パケットへ減らし、長遅延回線でも入力中の応答を手元で返した。
  • DO/WILLはサブネゴシエーションの許可、MODE_ACKは編集・信号モード、SLC_ACKは特殊文字の割当てを確認した。アプリケーション命令の受領確認ではない。
  • 行終端やFORWARDMASKがバッファを送出すると、その部分はもうローカル編集できない。それでも遠端への到着、解釈、認可、実行、完了は別々に観測する必要がある。

待ち時間を消したのは近端の仕事だった

RFC 1116 は、文字単位Telnetの費用を具体的に描いた。各キーに数パケットを使う代わりに、Linemodeなら一つのコマンド行に数パケットで済む。長い遅延を持つ装置では、利用者は入力が終わった後だけネットワークを待てばよい。パケット単位で課金される回線にも利点があった。

計算機側の事情もある。スーパーコンピュータは一文字ずつの処理を得意としないことがあり、前段のコンピュータに編集を任せれば、遠端は本来のベクトル計算に資源を使えた。Linemodeは通信量の節約であると同時に、処理位置の再設計だった。

だから表示の即時性は、遠端が速く答えた証拠ではない。クライアントが遠端へ尋ねずに描画と編集を済ませた証拠である。

現在のRFC Editor記録は1989年8月の提案と後継関係を示し、IETF Datatrackerは文書情報を保つ。1990年10月のRFC 1184はRFC 1116を廃止し、モードと視覚編集用文字を追加したが、ローカル編集の基本構造は引き継いだ。

オプション合意の後にモード合意があった

RFC 855 のTelnetオプション手順は二段階である。DOとWILLでパラメータを「話し合う」ことに合意し、その後SBとSEの間で実際のパラメータを交換する。DONTまたはWONTで以後の交渉を止められる。

Linemodeの既定はWONTとDONTだった。TCP/Telnet接続が存在するだけではローカル編集は始まらない。DO/WILLが成立しても、それは編集・信号状態を交渉する入口にすぎない。

次にMODEがEDITとTRAPSIGを配置する。通常、サーバが変更を始め、クライアントが確認した。EDITは入力行をどちらが処理するかを決め、TRAPSIGは割込み、ブレーク、中止、EOF、サスペンドに対応する文字をクライアントがTelnet命令へ変換するかを決めた。

MODE_ACKは双方を同じマスクへ収束させる。確認対象はモードであり、その後に入力される行ではない。まして接続先プロセスの成否を知る手段ではなかった。

送出点は行末だけではなかった

EDIT中、消去や再表示はローカルバッファに作用する。通常の行終端を押すと、RFC 1184の規則でCR LFを伴う編集済みデータが送られる。それまでは、遠端へ取消しを送らずに何度でも書き直せた。

一方、FORWARDMASKは特定のASCII文字を見た時点でバッファを送るようサーバが求める仕組みだった。SLC_FORW1とSLC_FORW2も送出文字を持つ。ローカル端末ドライバが要求された集合を正確に実装できなければ、クライアントはより広い制御文字集合で送る条件で受け入れることもできた。

この局面では、要求マスクと実効マスクを同一視できない。さらにRFC 1184は、送った部分はもう編集できないと注意する。近端では明確な不可逆点だった。

だが、その不可逆性はサーバ側の効果を作らない。データはTCPを渡り、Telnetとして復号され、接続先プロセスに渡り、構文とポリシーを満たし、処理を開始し、結果を返さなければならない。ローカルバッファが観測できるのは最初の送出までである。

SLCのACKはキー設定に対するものだった

SLC（Set Local Characters）は機能、修飾子、ASCII文字の三つ組を交換した。機能には、未対応、対応するが変更不能、明示値、既定値という段階があった。設定に同意すればSLC_ACKを付けて返した。

このACKは、将来そのキーが起こす動作の受領証ではない。キーが押されたか、Telnet命令に変換されたか、遠端へ届いたか、接続先プロセスが応答したかは一切含まない。

RFC 1184では、ABORT、EOF、SUSPの機能がなければ受信側が無視できた。入力・出力をフラッシュする修飾子は助言であり、利用者インターフェースが上書きできた。制御名が存在することと、プロセスが停止したことの間には実装と観測が必要だった。

ローカルエコーは往復時間ではない

RFC 857 は、相手のために行うエコーと、自分自身のために行うエコーを分けている。Telnet Echoオプションは後者を支配しない。Linemodeで文字が即座に見えるのは、クライアントのローカル判断で成立する。

出力フロー制御も別だった。RFC 1116とRFC 1184はFLOWをMODEへ入れず、RFC 1080 のRemote Flow Controlへ委ねた。そこでは別の合意後に、利用者TelnetプロセスがXON/XOFFを消費するかを切り替える。これはキーボード編集でも、アプリ停止でも、TCPのフロー制御や輻輳でもない。

状態を分けたからこそ、「画面が反応した」という一件だけで端末全体を説明できなかった。

結果の証拠は遠端から始め直す

IANA Telnet Optionsレジストリは34番をLinemodeとして登録し、RFC 1184を参照する。番号の意味を共有する記録であって、現在の利用率や個別実装の適合を示す記録ではない。

RFC 854 はNVTとTelnet制御命令の土台を提供する。データや信号の運び方は規定しても、アプリケーションの認可や業務結果は決めない。RFC 1184自身もセキュリティ問題を論じていない。

したがって証拠列は、ローカル行完成、送出、サーバ受信、Telnet復号、プロセス入力、ポリシー受入れ、実行開始、実行終了、応答受信、応答の対応付けまで分ける。Linemodeが高速化したのは列の前半であり、後半を省略したのではない。

出典