要約

  • URGは第二の配送路を作らない。通常のシーケンス空間にある位置を有効にし、受信アプリケーションへ緊急状態を知らせる。
  • Telnetは通知とストリーム内DATA MARKを組み合わせた。TCPは注意を引き、アプリケーションの印が意味を確定した。
  • 実装はRFC 1122の一バイト修正に収束しなかった。RFC 6093は配備済みの意味へ戻しつつ新規利用を止め、RFC 9293も互換性だけを残した。

追い越さない緊急性

RFC 793では、URGが立つと16ビットのフィールドが有効になり、セグメントのシーケンス番号との和が緊急ポインタになる。受信側がその位置まで読んでいない間だけ、アプリケーションは緊急モードに入る。

これは優先配送ではなく、同じ順序付きストリームについての状態通知である。緊急中に境界が更新されても新しい通知が見えないことがあり、送信回数と受信イベント数も一致しない。

Telnetが二つを組にした理由

RFC 854のSynchは、TCP緊急通知とDATA MARKから成る。通知が停止要求に気付かせ、通常のストリームに置かれたDATA MARKが特別な走査の終端を示す。複数通知は併合され得るため、意味は印の側に残った。

RFC 959は、転送中のFTPサーバーへABORなどを届ける際にTelnet Interrupt Process、Synch、FTPコマンドの順を提案した。TCPが中止を決めたのではない。後続コマンドを読む機会を作っただけだ。

一つの文書に二つの境界

RFC 793のヘッダー説明は緊急データの次のバイトを指し、SEND処理はSND.NXT-1、つまり最後の緊急バイトを使った。RFC 1011は前者を誤りとし、RFC 1122はLASTを必須にした。任意長の緊急列も要求された。

ところが文書を直しても、既に動くカーネルの境界は自動では動かない。

一バイトを外へ出したソケット

RFC 6093が調べた主要実装は、ほぼすべて「緊急データの次」を使っていた。さらに多くのAPIは最後の一バイトを通常読み出しから外し、MSG_OOBで渡した。名称は帯域外でも、ワイヤ上には別帯域がない。

一バイトの待ち箱は次の通知で上書きされ得る。SO_OOBINLINEでインラインに戻せても、対向実装や経路装置まで同じ意味にはできない。

経路が通知を消す

一部の中間装置はURGを消し、ポインタをゼロにした。データは届くが、アプリケーションを起こすイベントが消える。セキュリティ検査と端点が異なるストリームを再構成する危険も生まれる。

RFC 6093は既存実装に合わせて「次のバイト」へ戻す一方、新規アプリケーションには利用しないよう求めた。旧アプリはインライン配送を使い、URGが失われても正しく動くべきだとした。RFC 9293も、実装の対応は必須、新規依存は非推奨という線を守る。

情報源と限界

RFCは意図、矛盾、Telnet/FTP利用、調査された実装と中間装置を示す。全OSが同じ、全経路がURGを消す、または一斉に移行したとは証明しない。URGは認証でもネットワーク優先権でもない。

残ったのは互換フィールドであり、新しい正しさを支配する資格ではない。