要約

  • sctp_peeloffは、確立済みのSCTPアソシエーションを一対多ソケットから一対一ソケットへ切り出す。新しいアソシエーションを確立する操作ではない。
  • 切り出した後のデータ操作と制御操作は新しい記述子を使う。元のソケットの終了処理だけでは、分離したアソシエーションを終了できない。

保守手順に「受付側ソケットを閉じる」と書いてあっても、それでサービス内の通信がすべて終わるとは限らない。途中で別のソケットへ切り出された通信があれば、その手順の対象から外れている可能性がある。手順どおりに実行できたことと、意図した範囲を終了できたことは別の問題だ。

SCTPのソケットAPIを記述するRFC 6458には、この違いが明確に現れる。sctp_peeloffは、共有ソケットに属している確立済みアソシエーションを独立したソケットへ分岐させる。元のソケットを閉じても、そのアソシエーションは終了しない。

これは故障の説明ではない。APIが定める分離の効果である。問われるのは、アプリケーションの実際の制御構造が変わったとき、運用側の責任分担も同じように変わっているか、ということになる。

分けたいのは通信量だけではない

一対多ソケットは、複数のアソシエーションを一つの記述子で扱える。必要な操作ではアソシエーション識別子を使い、対象を選ぶ。入口を集約できる一方、その背後の資源まで独立しているとは限らない。

RFC 6458の3.3節は、実装が送信側バッファの割り当てを複数のアソシエーションで共有している場合を取り上げる。あるアソシエーションが進まなくなると、その待機データが共有枠を使い切り、ほかのアソシエーションも送信できなくなる可能性がある。ノンブロッキングに設定するだけでは、この資源の結び付きはなくならない。

ここには複数の対処の場所がある。実装がアソシエーションごとに領域を確保する方法、アプリケーション側で未読データ量を制限する方法、最初から一対一ソケットを使う方法、そして停止し得る大きな交換の前に対象を切り出す方法だ。どこに制約を置くかが異なるのであり、単に同じ設定を言い換えたものではない。

ただし、この説明を特定OSの性能保証として読むべきではない。前提は実装の割り当て方法である。既存キューがどう移るか、コピーが発生するか、メモリー使用量や速度がどう変化するかは、これだけでは分からない。切り出しという制御上の選択肢と、その実装で得られる性能は分けて扱う必要がある。

新しい記述子を受け取る意味

sctp_peeloffの呼び出しでは、元のソケットと、切り出すアソシエーションの識別子を指定する。成功すれば非負の新しい記述子が返り、失敗すればマイナス一とエラー情報が返る。新たに到着した接続を通常の方法で受け付けるのではなく、すでに存在する対象を選んでいる。

9.2節は、その後のすべてのデータ操作と制御操作を新しいソケットで行うと定める。ここで重要なのは制御操作も含まれる点だ。データだけが別扱いになるのではない。

例えば、多数の通信を一つの受付ソケットで扱い、大きな交換だけを切り出すサービスを考えよう。これは仕組みを説明する仮定であり、実在するシステムの観測ではない。後で受付ソケットを閉じても、切り出した交換にはその終了操作が届かない。完全な終了管理には、新しい記述子を引き続き管理対象として保持する必要がある。

通信が残ること自体は問題とは限らない。長い処理を意図して続けるなら、むしろ分離の利点になり得る。問題になるのは、誰かが継続を選んだのではなく、古い一覧から見えなくなったために残っている場合だ。

空き時間の扱いも確認し直す

ソケットレベルやIPレベルのオプションには、対象ソケットという適用範囲がある。一対多ならそこに属するアソシエーション、一対一ならそのソケットが表すアソシエーションが範囲となる。受信・送信バッファについても、一対多の実際の扱いには実装差があると文書は説明している。

8.1.8節のSCTP_AUTOCLOSEは一対多ソケットだけに向けたオプションである。ユーザーデータの送受信がない時間を対象とし、既定値のゼロでは無効、非ゼロ値では秒数を指定する。この種の終了を通知で知るには、アソシエーションの状態変化通知を有効にする必要がある。

しかし、すでに動いているタイマーが切り出し時にどうなるかを、この記述だけで決めつけることはできない。自動的に解除、再開始、継承されるとする根拠にはならない。新しいソケットに必要な存続期間の規則を、採用する実装の挙動と照合するのが妥当な結論だ。

終了方法にも区別がある。一対一ソケットの通常のcloseはSCTPの正常な終了手順を開始し、その記述子で後続操作を行えなくする。ただしSO_LINGERが有効で待機時間がゼロなら、closeはアソシエーションを中止する。正の待機時間は呼び出しの待ち時間を制限するもので、復帰した後にもプロトコルの終了処理が続くことがある。

通知を受け取る記述子を残して終了を進める場合には、記述されたshutdownの意味も確認したい。SCTPのSHUT_WRはプロトコル全体の終了を開始し、TCPの半閉鎖と同じではない。そして、記述子の解放やプロトコルの終了だけで業務上の取引完了まで証明できるわけでもない。

規範と運用上の解釈を分ける

RFC Editorの書誌情報では、RFC 6458は2011年12月のInformational文書とされている。現在の各OSで何が実装されているかを調査した一覧ではない。今回確認した正誤表には別の箇所への検証済み修正があるが、9.2節の直接の修正はなかった。将来更新用に保留された項目や却下された項目を、採用済みの修正と混同してはならない。

組織上の読み取りは、その事実から先の分析である。Lu Hengはインターネット統治の代理問題に関する論考で、決定する権限と結果を引き受ける立場の関係を問う。この例では、分離を認める担当者が、その後の終了責任の所在まで把握しているかが確認点になる。技術者の動機を断定する話ではない。

BTW Mediaの存在理由を述べた論考が重視するのは、主張よりも現実である。この場面なら、「受付は閉じた」という説明ではなく、どの記述子がまだアソシエーションを制御しているかを確かめることに当たる。

切り出しは有用な境界を作る。後始末の責任だけをその境界の手前に残さないことが、運用上の条件となる。