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

阶段 5

Browse Source
This commit is contained in:
SepComet
2026-03-27 13:27:14 +08:00
parent ff9ee1291f
commit e5851795c7
43 changed files with 1544 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/specs/shared-network-foundation/spec.md
+14 -1
View File
@@ -1,7 +1,7 @@
# shared-network-foundation Specification
## Purpose
Define the shared transport and message-routing foundation that both client and server hosts use without depending on Unity-specific runtime host classes.
Define the shared transport, session-lifecycle, and message-routing foundation that both client and server hosts use without depending on Unity-specific runtime host classes.
## Requirements
### Requirement: Shared network core is host-agnostic
@@ -37,3 +37,16 @@ The shared client/server foundation SHALL preserve the existing `ITransport` sen
- **WHEN** a client host sends a business message through the shared core to a server host using the shared core
- **THEN** the message is encoded using the same envelope contract on the client side
- **THEN** the server host decodes and routes it through the shared message-routing layer without a host-specific protocol fork
### Requirement: Shared runtime owns host-agnostic session lifecycle orchestration
The shared network foundation SHALL include host-agnostic session lifecycle orchestration alongside transport startup and message routing. Client and server hosts MUST be able to compose the shared foundation with session orchestration that consumes transport events, login results, and heartbeat signals without depending on Unity-specific runtime types, while supporting both single-session client composition and multi-session server composition.
#### Scenario: Client host composes runtime with single-session lifecycle manager
- **WHEN** the Unity client constructs its shared networking runtime
- **THEN** that runtime includes shared session lifecycle management for its single remote session in addition to transport and message routing
- **THEN** Unity-specific code remains responsible only for reacting to lifecycle state changes and driving host behavior
#### Scenario: Server host composes shared foundation with multi-session orchestration
- **WHEN** a non-Unity server host constructs the runtime networking stack for multiple remote peers
- **THEN** it uses the shared transport and message-routing foundation together with shared multi-session lifecycle orchestration
- **THEN** server-specific cleanup, admission, and gameplay reactions stay in the server host adapter rather than forking the shared lifecycle contract