Ticketing 応答マッチングルール(クライアント実装)
レスポンスはリクエストに対して順不同で届くことがあるため(待機していた獲得への応答は、 順番が来た時点で届く)、クライアントは次のルールを使ってレスポンスをリクエストに 対応付ける必要があります — 1つの接続上で入り交じったレスポンスを元のリクエストへ 振り分けるデマルチプレクシングの仕組みです。
| ルール | 詳細 |
|---|---|
| マッチングキー | queue/server capacity満杯による確定拒否。即時Busyを返し、内部自動再試行なし |
| 同じ(op, key)を持つ複数のリクエスト | FIFOを前提にしてはいけない — 必ず識別子で特定する。下記参照 |
| 登録のタイミング | 待機者はリクエストを送信する前に登録する(レスポンスが先に届いてしまう競合を防ぐため) |
N/Tの扱い | 非エラー値として返す(「存在しなかった」/「タイムアウトした」) |
Bの扱い | 待機キューが満杯 — 即座に失敗させず、waitの予算内でバックオフして再試行する |
Mの扱い | allowlist内addressだけをleader hintに保存して接続を閉じる。owner/keyがなく送信済みpendingに相関不可 |
Lの扱い | leader hintのみ更新して接続維持。request応答ではなくserver通知 |
E no_leader / E not_active / E auth_failed | 接続を閉じerror別backoff。no_leaderはleader hintも無効化 |
その他のE/未知のレスポンス | 相関不能なのでconnection-fatal。送信済みacquireはIndeterminate |
| マッチする待機者がないレスポンス | protocol/session不一致として接続終了。Aなら既知exact tokenをreserved release laneへ |
FIFOではなく識別子でマッチングすべき理由
同じkeyでも即時成功、queue待機、B拒否は完了時点が異なります。複数keyも1接続でpipelineされるため、応答順は要求順と一致しません。FIFOではなくechoされたidentifier、op、keyを全て確認します。
中断されたリクエストと孤立したロック
中断したrequestがserverで既にgrantされていればlockが残る場合があります。request byteを1つでも送った後に確定応答がなければIndeterminateです。同じownerでstatus照会のようにAを再送してはいけません。tokenを既にparseした場合のみbest-effort exact-token Rを送り、未知tokenのgrantはlease expiryが回収します。
送信後cancelやframing errorで接続を閉じる理由も同じです。pendingだけ破棄すると発行済み応答が孤立します。ただしsocket closeはcommit済みgrantのrelease証明ではありません。token既知ならexact-token R、未知ならlease expiryまでIndeterminateです。