-
-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TransportSocket trait for injecting the socket into netcode transports #145
Conversation
…ets to netcode transports
/// Implementation of [`TransportSocket`] for `UdpSockets`. | ||
#[derive(Debug)] | ||
pub struct NativeSocket { | ||
socket: UdpSocket, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe implement From
to make it easier to initialize?
And I would declare it as NativeSocket(UdpSocket)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't do it, new()
returns a Result
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see.
|
||
#[derive(Debug)] | ||
#[cfg_attr(feature = "bevy", derive(bevy_ecs::system::Resource))] | ||
pub struct NetcodeClientTransport { | ||
socket: UdpSocket, | ||
socket: Box<dyn TransportSocket>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered using generic instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah generic would get rid of the dynamic dispatch, but then all user code that gets the netcode transport resources has to parameterize on the socket type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense.
Closing this as implemented in renet2. |
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 usenetcode
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.