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.../proposal.md

1.7 KiB
Raw Blame History

Why

The shared runtime already has an MVP-oriented dual-transport shape, but TODO step 5 is still undocumented at the spec level. We need to lock that contract before changing integration wiring so client and server hosts keep a clear, host-agnostic way to run reliable control traffic and high-frequency sync traffic on separate transport instances without prematurely redesigning ITransport.

What Changes

  • Document that SharedNetworkRuntime preserves separate reliable and sync transport inputs for the MVP and starts or stops both lanes when distinct instances are supplied.
  • Document that ServerNetworkHost preserves the same dual-transport constructor shape and attaches receive handling for both lanes without forking message contracts.
  • Require the shared runtime foundation to keep delivery-lane composition outside ITransport so hosts can use two transport instances instead of expanding the transport abstraction early.
  • Add implementation tasks to verify or tighten regression coverage around dual-transport startup and message-lane usage in the shared runtime and server host.

Capabilities

New Capabilities

Modified Capabilities

  • shared-network-foundation: Narrow the shared runtime contract so MVP hosts explicitly preserve dual-transport composition through SharedNetworkRuntime and ServerNetworkHost without widening ITransport.

Impact

Affected code is expected in Assets/Scripts/Network/NetworkApplication/SharedNetworkRuntime.cs, Assets/Scripts/Network/NetworkHost/ServerNetworkHost.cs, and related edit-mode regression tests. This change should not introduce new transport interfaces or Unity-specific dependencies into shared networking code.