basil
/
RUDPClient
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
RUDPClient/openspec/changes/archive/2026-03-28-preserve-dual-tr.../specs/shared-network-foundation/spec.md

2.4 KiB
Raw Blame History

MODIFIED Requirements

Requirement: Shared core preserves current transport and message contracts

The shared client/server foundation SHALL preserve the envelope-based business-message contract across client and server hosts while allowing delivery-policy selection behind the shared message-routing layer. Reliable control traffic MUST continue to use the existing ITransport contract, and high-frequency sync traffic MUST remain composable by supplying a second host-agnostic sync transport instance to SharedNetworkRuntime or ServerNetworkHost rather than by expanding ITransport for MVP-specific lane semantics. The shared message-type contract MUST allow hosts to distinguish MoveInput, ShootInput, CombatEvent, and PlayerState as separate business messages across both delivery lanes.

Scenario: Shared runtime starts distinct reliable and sync transports

  • WHEN a client host constructs SharedNetworkRuntime with one reliable transport and a different sync transport instance
  • THEN starting the runtime starts both transport instances
  • THEN stopping the runtime stops both transport instances while keeping the same shared message-routing contract

Scenario: Server host composes both transport lanes without protocol forks

  • WHEN a server host constructs ServerNetworkHost with one reliable transport and a different sync transport instance
  • THEN it observes inbound activity from both transport lanes through shared host logic
  • THEN it routes messages with the same envelope and message-type contract instead of defining a lane-specific protocol fork

Scenario: Shared hosts exchange the same envelope format across delivery lanes

  • WHEN a client host sends a business message through either the reliable control path or the high-frequency sync path
  • THEN the payload is encoded with the same shared envelope and message-type contract
  • THEN the server host decodes and routes it through shared networking logic without a host-specific protocol fork

Scenario: Hosts preserve dual-transport composition outside ITransport

  • WHEN a host needs separate reliable and sync lanes for MVP gameplay traffic
  • THEN it provides separate transport instances plus delivery-policy configuration to shared runtime or host entry points
  • THEN the shared networking core does not require ITransport itself to grow MVP-specific multi-lane APIs