basil/RUDPClient
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

process TODO.md step8

Browse Source
This commit is contained in:
SepComet
2026-03-29 10:49:32 +08:00
parent ef01760924
commit c5fbd8e36d
26 changed files with 1005 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/specs/multi-session-lifecycle/spec.md
+6 -1
View File
@@ -13,7 +13,7 @@ The shared networking core SHALL provide a multi-session lifecycle coordinator f
- **THEN** lifecycle changes for one peer do not overwrite or hide the state of the other peer
### Requirement: Multi-session hosts can observe and evaluate each managed session
The multi-session lifecycle coordinator SHALL expose per-session lookup or enumeration and MUST evaluate timeout, heartbeat, login, reconnect, and authoritative movement tick rules for each managed session independently using the shared session lifecycle vocabulary. Server-side stale-input acceptance and authoritative movement tracking MUST remain scoped to the peer that produced the traffic.
The multi-session lifecycle coordinator SHALL expose per-session lookup or enumeration and MUST evaluate timeout, heartbeat, login, reconnect, authoritative movement tick rules, and authoritative combat input rules for each managed session independently using the shared session lifecycle vocabulary. Server-side stale-input acceptance, shoot validation, and authoritative gameplay tracking MUST remain scoped to the peer that produced the traffic.
#### Scenario: Timeout affects only one managed session
- **WHEN** one managed session stops receiving liveness updates while another session continues receiving heartbeat or message activity
@@ -30,6 +30,11 @@ The multi-session lifecycle coordinator SHALL expose per-session lookup or enume
- **THEN** stale-input acceptance is evaluated independently for each managed peer
- **THEN** one peer's late or advanced movement input does not overwrite or suppress the other's authoritative movement state
#### Scenario: Shoot validation remains peer-scoped
- **WHEN** two managed peers send `ShootInput` traffic with different tick progress, target choices, or validation failures
- **THEN** acceptance and rejection are evaluated independently for each sending peer
- **THEN** one peer's stale or invalid shoot request does not overwrite or suppress the other's authoritative combat state
### Requirement: Session removal is explicit and does not corrupt remaining peers
The multi-session lifecycle coordinator SHALL support explicit removal or disconnection handling for one managed session without resetting unrelated sessions that remain active.