要約

  • Jon PostelとJoyce Reynoldsによる1983年5月のRFC 860は、TELNETのオプション番号6、TIMING-MARKを定めた。片側がDO TIMING-MARKを求め、応じる側はバッファを通過した適切な位置にWILL TIMING-MARKを差し込んで返す。
  • 想定された場面の一つは、誤ったコマンドの後に利用者が先回りして文字を打ち続けることだ。サーバーは戻ってきた目印までの入力を捨て、利用者がエラーを見てから打った文字で解釈を再開できる。捨てる判断は目印を求めた側にある。

最初のコマンドを打ち終え、返事を待たずに次も入力する。ところがサーバーは一行目でつまずき、画面に疑問符を出す。二行目はもう端末側のバッファを出発したかもしれないし、ネットワークの途中にいるかもしれない。サーバーがその文字を新しい命令として読めば、単なる打ち間違いに続きの仕事まで巻き込まれる。RFC 860の問いは、古い入力をどこまで片づけるか、である。

TELNET本体の仕様は双方がデータを送る接続を定め、オプションの規則は追加の動作を申し出たり断ったりする方法を与えた。Timing Markは、その交渉を入力の後始末に使う。名前に「時」が入っていても、ここで欲しいのは時計の値よりデータ列上の位置だ。人間が疑問符を見た瞬間と、サーバーがキューの文字を読む瞬間には距離がある。

サーバーはIAC DO TIMING-MARKを送る。相手が協力するなら、IAC WILL TIMING-MARKを帰りの流れの適切な場所に入れる。RFCの説明では、目印は相手の送信側バッファを経て端末側へ進み、受信側バッファを通って戻る。戻りを確認したサーバーは、先に流れていたデータが折り返し地点を越えたと分かる。そこで初めて、エラー表示前の先回り入力と、表示後の訂正を仕分けられる。

手順は具体的だ。サーバーは改行と疑問符を送り、その後にTiming Markを要求し、エラーメッセージを送る。返答のWILLが来るまでは入力を読みながら捨てる。届いた後で文字の解釈を再開する。境目は、利用者が疑問符を見てから最初に打った文字の直前に置かれる。サーバーの発見時刻で機械的に切るより、画面を見た利用者の行動に合った切り方だ。

誰がゴミ箱を使うかも明記された。RFC 860では、不要な文字を捨てる責任はDOを送る側にある。相手は信頼できる境界を返し、依頼した側が自分の入力を処理する。同じ仕組みは逆向きにも働く。端末がサーバーから古い出力を受け続けているなら、端末側から目印を求め、WILLが返るまで古い表示を捨て、新しいコマンド以後の出力を画面に戻せる。

返事の意味は段階的だ。WILLは指定の位置に目印を置いたと約束する。WON'Tはその約束を断るが、それまでのデータを受け取ったことは示す。DON'Tは以前のWILLを無視したという通知だ。初期状態の接続には明示的な同期はない。RFCは往復遅延の測定も用途に挙げている。折り返し地点が分かれば測定しやすいが、目印そのものは時刻を記すものではない。

利用者がサーバーの要求を予想する場合まで想定されていた。端末側が自分で決めた場所に先にWILLを置き、また入力を始める。後から届くDOには端末のソフトウェアが整合を取る。少々せっかちな人間を、単なる例外として片づけていない。二つの機械のバッファと画面を見た人の「今」をつなぐには、往復できる合図が必要だった。

打ち間違いを見つけたサーバーは謝るように疑問符を出せる。Timing Markのおかげで、キーボードがその知らせを受け取った後の文字を、続きとして扱えるようになった。会話をやり直す場所が、両側に見えるようになったのである。