要約

  • RFC 1080 は、DO と WILL で限定的な権限に双方が同意した後に限り、Telnetプロセスが相手へソフトウェアフロー制御の有効・無効を要求できるようにした。
  • 対象はユーザーTelnetプロセスから接続端末へ向かうローカル出力であり、TCP、遠隔アプリケーション、ネットワーク全体ではない。要求を送った事実も、ドライバーの適用を証明しない。
  • 合意成立時にはフロー制御が有効という既知の初期状態が生まれる。オプションを撤回すると遠隔権限は終わり、状態は実装固有の既定値へ戻り得る。

文字の値だけでは意味が決まらない

RFC 854 のNetwork Virtual Terminalは、128個すべてのUS-ASCIIコードをキーボードから生成できた。遠隔のエディターにとってControl-SやControl-Qは、受け取るべき通常の入力になり得る。

一方、端末ドライバーは同じ値をソフトウェアフロー制御に使った。一般にXOFFであるControl-Sが表示出力を止め、XONであるControl-Qが再開する。ドライバーがローカルで文字を消費すれば、サーバーのプログラムには届かない。

バッファー保護には前者が必要でも、編集コマンドには後者が必要になる。衝突していたのは符号化ではなく、同じ値をどの境界で解釈するかだった。

1988年11月の RFC 1080 は、TOGGLE-FLOW-CONTROL にオプション番号33を与えた。遠隔側が端末を所有する仕組みではなく、ローカル状態の変更を依頼する小さな窓口である。

コマンドより先に同意が必要だった

RFC 855 は、パラメーターを持つTelnetオプションを二段階に分けた。まず DO/WILL でオプション使用に合意し、その後でサブネゴシエーションを行う。

典型的にはホストが DO を送り、端末に接続したユーザーTelnetが WILL を返す。前者は有効・無効の要求を送る意思を示し、後者はその要求に応じる役割を受け入れる。

DONT と WONT は役割の拒否であって、現在のローカル状態の報告ではない。遠隔制御を拒みながら、クライアント自身の方針でXON/XOFFを使うことは可能だった。

合意前に ON や OFF を送ってはならない。撤回後も同じである。到着したコマンドが、自分を有効にする権限まで同時に作ることを防いだ。

双方向にも使えるが、通常は非対称だった。遠隔アプリケーションは文字をそのまま必要とする時を知り、ローカルクライアントは端末への実経路を管理していた。

合意した瞬間に初期状態が決まった

DO/WILL の後、DO の送信側は OFF または ON を要求できた。変わるのはユーザーTelnetから端末表示へ向かうソフトウェアフロー制御であり、TCPの受信ウィンドウや遠隔プロセスではない。

RFC 1080 は、合意成立直後に WILL の送信側がフロー制御を有効にするよう定めた。別の ON を待たず、開始状態を既知にしたのである。

ただし後の変更に確認応答はなかった。パケットキャプチャーは、許された OFF 要求が送られたことを示せる。ローカルドライバーが適用したこと、画面が実際に止まったこと、文字がアプリケーションへ届いたことまでは示せない。

未知のサブコマンドは無視される。拡張に耐える規則だが、応答がないことを対応済みの証拠にはできない。

撤回後は「最後の要求」が真実ではない

どちらの側も DONT または WONT でオプションを止められた。その後は、再度 DO/WILL が成立するまで新しい状態要求を送れない。

ローカルのフロー制御は、最後の ON や OFF に固定されるとは限らない。実装が定める既定値へ戻ってよい。したがって「最後に見たコマンド」だけを状態台帳にすると、撤回、再接続、再起動の後に誤る。

遠隔側が持っていたのは、合意が生きている間だけの委任だった。委任の終了後にローカル方針が戻ることは、相互運用性の失敗ではなく権限境界そのものだった。

画面の停止はTCPの停止ではない

RFC 1080 の対象方向は、ユーザーTelnetプロセスから接続端末への出力だけである。端末からTelnetへの入力は別の挙動を持ち得る。専用信号を使うハードウェアフロー制御なら、文字を横取りしない。

TCPのウィンドウ制御や輻輳制御とも異なる。遠隔アプリケーションは出力を作り続け、TCPやバッファーはデータを保持し続けるかもしれない。表示が止まることとネットワークが止まることは同じではない。

Control-Sを押した記録、ドライバーがXOFFを消費した記録、ネットワーク上の OFF、目に見える停止は、別々の観測点に属する。

Linemodeは他のローカル処理を分けた

RFC 1184 は、行編集やシグナル処理をクライアント側で行うLinemodeを定めた。高遅延の回線では、一文字ごとの往復より完成した行を送る方が使いやすい。

フロー状態も近い問題だが、RFC 1184 は既存の TOGGLE-FLOW-CONTROL を使い続け、Linemodeのビットへ統合しなかった。新しい状態機械が古い状態機械を黙って上書きしないためである。

この分離は証拠の位置も示す。キーボード、ドライバー、Telnetクライアント、サーバーアプリケーションの各段階で文字は消費・変換され得る。

RFC 1372が確認不能な差を追加した

RFC 1372 は1992年にRFC 1080を置き換え、RESTART-XON と RESTART-ANY を追加した。前者はXONだけで再開し、後者は新たなXOFF以外の任意の文字で再開するよう要求する。

フロー制御の有効状態は合意時に既知だったが、再開条件の初期値はシステム依存だった。サーバーは望む条件を別に要求する必要があった。

しかし両方を実装できないクライアントは要求を無視でき、サーバーへ通知する方法はなかった。送信した希望と、ローカル能力の間には確認できない空白が残った。

多くのドライバーはXON/XOFFを消費する。任意文字再開では、出力を再開した通常文字がそのままアプリケーションへ進む場合もある。再開と文字配送は一つの結果ではない。

シリアルポート制御は別の対象だった

RFC 2217 は後に、シリアルポートのフロー方式と、Telnetセッション全体の FLOWCONTROL-SUSPEND/RESUME を定義した。後者はデータとコマンドの両方を停止する。

デバイス設定、セッション停止、ローカルXON/XOFF解釈は異なる制御面である。名称の類似だけで相互の証拠を代用できない。

IANAのTelnet Optionsレジストリー は、現在も33をRemote Flow ControlとしてRFC 1372に結び付ける。番号の継続性は示すが、現在の実装数や適用結果は示さない。

一つのモードを五つの記録に分ける

必要なのは、①セッション内の同意、②同意中に送った要求、③ローカルで適用された状態、④対象文字が消費されたか転送されたか、⑤画面とアプリケーションで観測した結果である。

RFC 1080 は最初の二つと初期状態を提供した。残りはローカルまたはエンドツーエンドの観測が必要だった。

歴史的な価値は、古い端末を遠隔支配したことではない。用途、入口、出口を狭く定義したことで、同じ文字の二つの意味を調整可能にした点にある。

情報源と限界

RFC 854はNVT、RFC 855は合意手順、RFC 1080は原仕様、RFC 1184はLinemode、RFC 1372は再開条件、RFC 2217はシリアルとセッション制御、IANAは番号登録を示す。現在の普及、認証、一般的な権限、適用済み状態、実事故、ユーザー結果は示さない。