要約

  • STOP_SENDING は受信側が一方向のデータをもう望まないことを示すが、過去のバイトが無視された証拠ではない。
  • RESET_STREAM が終わらせるのは相手の送信方向だけであり、final size は消費したフロー制御クレジットを示す。
  • 転送の記録は、遠隔アプリケーションの受理、取消し、永続的な影響、補償、最終結果とは分けて扱う。

クライアントはタイムアウトを契機に応答を不要と判断し、アプリケーションエラーコードを添えて STOP_SENDING を送ることがある。これは明確な QUIC の転送イベントだが、遠隔の注文、ジョブ、依頼が取り消されたという意味ではない。ネットワーク上のバイトの状態と、アプリケーション内の処理状態は同じ状態機械ではないからだ。

RFC 9000 では、ストリームから受け取っているデータに関心がなくなったアプリケーションが読み取りを中止できる。受信側が Recv または Size Known にある場合、反対方向の終了を促すため、転送層は STOP_SENDING を送るべきである。ただし、このフレームは受信データが無視されることを保証しない。先に届いた STREAM バイトは、アプリケーションへ渡され、処理されていたかもしれない。STOP_SENDING の後に届く STREAM バイトも、転送層が破棄したとしても、ストリームと接続のフロー制御には加算される。

相手の応答は別の状態遷移である。相手の送信側が Ready または Send なら RESET_STREAM を送らなければならない。Data Sent なら、未処理のデータが確認されるか失われたと判断されるまで遅らせてもよい。失われた場合は、そのデータを再送する代わりに RESET_STREAM を送るべきである。相手は STOP_SENDING のアプリケーションエラーコードをコピーするのが望ましいが、別のコードを選ぶこともできる。したがって、二つのコードは別々の観測値として記録する。

重要なのは方向である。RESET_STREAM が突然終了させるのは送信側だけだ。双方向ストリームでは、反対方向は独立して残る。両方向を止めたい場合、エンドポイントは自分の送信方向に RESET_STREAM を送り、反対方向の終了を促すために STOP_SENDING を使う。それでも接続全体が閉じたことや、要求と応答、業務フローが終了したことにはならない。

final size はフロー制御の証拠である。接続レベルでそのストリームが消費したクレジット量を示し、いったん判明すれば変わらない。正常終了でもリセットでも、値は確実に伝えられる。しかし、完了した仕事の量、遠隔処理の受理、影響の取消しを示す値ではない。RESET_STREAM の後に送信と STREAM フレームの再送が止まるのは、転送の動作が止まるという意味であり、アプリケーション状態が元に戻るという意味ではない。

信頼性にも限界がある。QUIC は失われたパケット全体をそのまま再送せず、必要な情報を新しいフレームで送り直す。RESET_STREAM は確認されるまで、またはストリームの全データが確認されるまで送られる。STOP_SENDING は受信側が Data Recvd または Reset Recvd に達するまで送られる。受信や確認が示すのは QUIC の状態機械の進展であって、過去のバイトが消費されなかったこと、処理が取り消されたこと、影響が戻されたこと、補償が成功したことではない。

証跡には接続識別子、stream ID、開始者、単方向か双方向か、影響を受けた方向を記録する。読み取りを止める判断、STOP_SENDING の送信と再送、各エラーコード、RESET_STREAM とそのコード、final size、フロー制御の計算、後続 STREAM バイトも分離する。遠隔での受理や消費、取消しの受諾または拒否、永続的影響、ロールバック、補償、最終結果は別のアプリケーション証拠で示さなければならない。

この線引きは周辺の論点とも異なる。TR-045 は ACK とパケット処理、TR-046 はフロー制御の許可、TR-052 は DATAGRAM の境界と配送保証の欠如、TR-053 は CONNECTION_CLOSE と接続状態の終了を扱う。STOP_SENDING は、接続が生きたまま一つのストリーム方向を止めるための要求である。