-
Notifications
You must be signed in to change notification settings - Fork 75
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
Configurable network adapters #141
Configurable network adapters #141
Conversation
4713188
to
6de268f
Compare
CI fails on building a dependency with |
700da91
to
affbb9f
Compare
CI issue will be resolved with the next nightly (tomorrow?), see rust-lang/rust#109199 |
6d3fc90
to
56e7542
Compare
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.
I really like how the information arrives to the adapters. Very neat! 🚀
Should I expect another PR with the broadcast implementation? Anyways, I like this PR as it is open the door to future implementations with different configurations.
I left some minor comments related to documentation. It should be great an example with its usage, to teach the user how to use it.
I wanted to hear your opinion before putting too much effort into it. :-) will work on the details tomorrow. |
Great! 💯 |
The implementation is complete. It's actually just |
56e7542
to
14ea4cd
Compare
I think I addressed all your comments. I also wrapped the configuration properties in an |
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.
I understand your reason about leaving the broadcast
as an option. Nevertheless I think it's difficult for a user to chose between 3 choices when they have 2 effective values true
or false
: should I choose between None
, Some(false)
or Some(true)
🤔? None
means true
or means false
for this configuration?
I would prefer these None
mapping to a sane default value. And the user could always see what they are in the default()
implementation (in case the thing get complex and we need it explicitelly).
src/network.rs
Outdated
/// let config = UdpConnectConfig { broadcast: Some(true)}; | ||
/// let addr = "255.255.255.255:7777"; | ||
/// let (conn_endpoint, _) = handler.network().connect_with(TransportConnect::Udp(config), addr).unwrap(); |
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.
Nice!
src/network/adapter.rs
Outdated
/// The [`TransportConnect`] wraps custom transport options for transports that support it. It | ||
/// is guaranteed by the upper level to be of the variant matching the adapter. Therefore other | ||
/// variants can be safely ignored. | ||
/// variant matching |
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.
I think this line does not fit here: /// variant matching
src/adapters/udp.rs
Outdated
) -> io::Result<ConnectionInfo<Self>> { | ||
let config = match config { | ||
TransportConnect::Udp(config) => config, | ||
_ => unreachable!(), |
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.
It's reachable if the user choose an invalid one, right? Maybe a panic()!
explaining there was a wrong configuration?
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.
I don't think that can happen? Because if the user chooses a different variant of TransportConnect
it will not end up in this adapter.
The user calls NetworkController::connect_with()
with the specific TransportConnect
struct. In that function the adapter is chosen based on TransportConnect::id()
which matches the variant to a Transport
variant and returns Trasnport::id()
which is then used select the corresponding adapter. So unless you have an bug in the matching in TransportConnect::id()
it actually is unreachable. And I think TransportConnect::id()
is simple enough to assume it to be bug free.
However, if you prefer a panic!()
I wont loose any sleep over it. ;-)
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, ok, you're right! It is fine then to leave the unreachable()!
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.
I see you have just changed it to panic!()
. Whatever solution you choose is ok for me
Signed-off-by: Konrad Gräfe <kgraefe@paktolos.net>
14ea4cd
to
894dbd2
Compare
sorry, forgot about Option |
Signed-off-by: Konrad Gräfe <kgraefe@paktolos.net>
894dbd2
to
dbdf48d
Compare
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.
Very neat and high quality PR!
Relates to #54