要約
- RFC 3081はBEEPセッションを単一TCP接続へ対応させたが、TCPの接続単位のフロー制御を、各多重化チャネルの進行保証とは見なさなかった。
- 各チャネルは4096オクテットの初期受信枠を持ち、優先される
SEQフレームで枠を更新した。同優先度のチャネルにはround-robinが推奨された。
正しく届くことと、順番が来ること
四つのアプリケーション・チャネルが同じTCP接続を使っている。三つの受信側はすぐ読むが、四つ目だけが遅く、しかも送信側には巨大な応答が残っている。TCPは順序を守り、損失を回復し、接続を正常に保てる。それでも短い三つの仕事は、巨大な一つの後ろで待ち続け得る。
これは信頼性の故障ではない。信頼できる運搬路の中での配分問題である。
2001年3月にStandards Trackとして公開されたRFC 3081は、BEEPをTCP上へ写像した。一つのBEEPセッションは一つの確立済みTCP接続を使い、BEEPフレームはそのバイト列へ入る。単純な対応だが、文書は隔離まで単純化しなかった。複数の論理チャネルがTCPの単一フロー制御だけに依存すれば、飢餓やデッドロックが起こり得ると明記した。
TCPの帳簿は一冊だった
TCPには、どのバイトがセッション管理で、どれが短い照会で、どれが大きな応答か分からない。意味上のチャネルは上位層にある。そのためRFC 3081は、BEEPの各チャネルに独立したスライディング・ウィンドウを設けた。
新しいチャネルは4096オクテットのpayloadを送れる状態から始まる。受信側はSEQフレームで、次に期待するシーケンス番号と受け入れ可能な窓幅を通知する。二つの値がチャネル固有の上限を作り、そこへ達した送信側は、TCPへまだ書ける場合でもそのチャネルだけを止めなければならない。
これは再送機構ではない。順序と回復はTCPの仕事である。BEEPの計算が答えるのは「この会話が共有接続へ追加してよいアプリケーションデータは、あとどれだけか」という別の問いだった。
番号はいずれ一周する。RFC 3081はRFC 1982のserial number arithmeticを参照し、比較が曖昧にならない範囲へ窓を制限した。古い位置が一周後に新しい権限へ化けないための境界である。
解放する信号を、荷物の後ろへ置かない
信用枠の更新は、送信側へ届いて初めて働く。SEQが、それ自身の解放対象である通常データの後ろに並べば、フィードバックは停止し得る。RFCはSEQを他のフレームより優先した。
これは制御情報の価値が高いという主張ではない。因果関係の保護である。新しいpayloadを合法的に入れる前に、受信側が空き容量を伝えられなければならない。制御路に逃げ道がなければ、フロー制御は自らデッドロックを作る。
同じ優先度のチャネルにはround-robinが勧められた。すべてのOSバッファで同じ遅延や完全な公平性を約束するものではない。常時忙しい一つのチャネルを処理し続け、準備済みの隣へ一度も順番を渡さない実装を避ける最低線だった。
遅い読者はさらに上にいた
TCPへ到着したこと、BEEPの窓へ受け入れられたこと、アプリケーションへ渡ったこと、外部結果が生じたことは別の事実である。RFC 1122はTCPを信頼できるバイトストリームとして規定し、アプリケーション取引の完了器とはしなかった。RFC 9293もこの境界を保つ。
後続の利用例は区別の必要性を示す。RFC 3195は信頼性のあるsyslogをBEEP上に置き、RFC 4744はNETCONFを載せた。シーケンスが進んでもログ保存は証明されず、窓が開いても設定反映は証明されない。効果を宣言できるのは、その意味を所有するアプリケーションだけである。
窓は限定された許可だった
受信側はメモリと配送の費用を負うため、チャネル別容量を決めた。送信側は、信用枠を持つ候補から次のチャネルを選んだ。TCPは接続の混雑と信頼性を制御し、アプリケーションは仕事の完了を決めた。
RFC 3081の長く残る教訓は、レーンへ番号を付けるだけでは独立性にならないということだ。別々の予算、支配対象の交通に埋もれないフィードバック、そして一人の正当な利用者が共有資源の事実上の所有者にならないサービス規則が必要だった。
情報源
- https://www.rfc-editor.org/info/rfc3081
- https://www.rfc-editor.org/rfc/rfc3081.html
- https://datatracker.ietf.org/doc/rfc3081/
- https://www.rfc-editor.org/rfc/rfc3080.html
- https://www.rfc-editor.org/rfc/rfc1982.html
- https://www.rfc-editor.org/rfc/rfc1122.html
- https://www.rfc-editor.org/rfc/rfc9293.html
- https://www.rfc-editor.org/rfc/rfc3195.html
- https://www.rfc-editor.org/rfc/rfc4744.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
