This way the existing netcode transports can be reused for the in-memory transport and WebTransport, which should reduce diffs/complexity for both of them, and allows WebTransport to use netcode ConnectTokens which are an essential part of the architecture.
This abstraction would also make it very easy to insert custom TransportSockets that artificially add packet loss and latency for testing purposes. Other performance characteristics of the architecture would remain the same with that approach (compared to writing entirely new transports with injected packet loss/latency), which is important for high-quality testing.
The main disadvantage of this approach is WebTransport would end up double-encrypting all packets. It may be possible to configure renet not to encrypt packets if the user can promise they were already encrypted. Needs careful thought.
UkoeHB
commented
2 months ago
This way the existing
netcodetransports can be reused for the in-memory transport and WebTransport, which should reduce diffs/complexity for both of them, and allows WebTransport to usenetcodeConnectTokens which are an essential part of the architecture.This abstraction would also make it very easy to insert custom
TransportSocketsthat artificially add packet loss and latency for testing purposes. Other performance characteristics of the architecture would remain the same with that approach (compared to writing entirely new transports with injected packet loss/latency), which is important for high-quality testing.The main disadvantage of this approach is WebTransport would end up double-encrypting all packets. It may be possible to configure renet not to encrypt packets if the user can promise they were already encrypted. Needs careful thought.