跳轉到

D-20260710-04｜等待房 star 拓撲：兩層網路劃界

背景與驅動力

首測前 staged 清帳輪，等待房傳輸層仍是 OFFLINE 樁。直接重用賽內 RaceMesh 不可行：它是固定名單設計，成員進出即 all-or-nothing 重建，與等待房「隨到隨走」語意相反；擴充 signaling wire 亦被排除——signaling server 維持窄介面、不為房間邏輯加端點。需要一個房間期專用的傳輸模型。

考慮過的選項

  • 重用 RaceMesh 當等待房傳輸：固定名單、成員進出破壞整組連線；否。
  • 擴充 signaling server 承載房間訊息：違反 server 窄介面原則；否。
  • star 拓撲（採納）：成員各一條 WebRTC link 連房主，房主權威中繼。

決定

  • 等待房採 star 拓撲（新模組 src/room-runtime/）：成員各一條 link 連房主；房主為權威 Room，中繼聊天 ／ready／room-state／match-start。
  • presence 走 signaling 房域註冊（openRoomPresence＝ 房間存在性標記 ＋ 成員進出通知）；SDP 握手經此中繼。
  • 賽內 full-mesh 於 session start 全新建——race 路徑不動，對齊「mesh 於開賽確認後成形」的既有 canon；等待房與賽內是兩層拓撲、各自生滅。

後果與影響

房間期容忍成員自由進出、賽內保住固定名單 mesh 的決定性前提；開賽交棒點 ＝ 房主 startMatch 三閘通過後以 deriveMatchId（D-20260710-02）廣播 match-start，並附帶繼任房主 seededMembers 補收機制。同輪複審隨即對此拓撲補上入房密碼挑戰-應答與成員端校驗（D-20260710-05）。現況權威：room-runtime.md、matchmaking.md。