UDP sockets

[yoshuawuyts]

With QUIC becoming a thing, it's reasonable that soon services that traditionally operated over TCP will start operating over UDP. Think HTTP/3 and gRPC.

I'm thinking it might be useful to expose UDP variants of the .bind() and .bind_or() methods, so moving from one protocol to the other doesn't require switching CLI parsers.

I was thinking probably the easiest way is to keep .bind() and .bind_or() operate on TCP, but add the .udp_bind() and .udp_bind_or() methods for UDP connections.

Unresolved questions

• Is there possibly a better API we could expose? Perhaps with the From trait (if that's not too magicky?).
• Should we maybe create API symmetry and rename .bind() to .tcp_bind() ?

[deg4uss3r]

I really like the thought of symmertry, or .bind("tcp")/..bind("udp")? I also think even without QUIC, UDP definitely has its place in models, so this is definitely a great idea.

I can probably help with the code behind issue as well, I just have to work/communciate after work hours...

[yoshuawuyts]

@deg4uss3r I really like this passage from Elegant APIs in Rust:

Don’t “stringly type” your API

Coming from dynamically typed languages, you might be tempted to use strings with specific values in various places.

For example: You want a function to print some input text in a color, so you use a parameter color of type &str. That also means you expect your users to write one of the names from a limited number of color names (like ["red", "green", "blue", "light golden rod yellow"]).

This is not what you should do in Rust! If you know all possible variants beforehand, use an enum. This way, you don’t need to parse/pattern match the string – and deal with possible errors – but can be sure that a user of your API can only ever supply valid inputs.

---

If we avoid going with strings and rely on enums instead, the .bind() API would require 2 imports to work. I feel like the point of this module is to reduce as much boilerplate as possible in order to open a socket, and introducing an enum like that would probably pull it away from that.

Instead I'm thinking that probably having a .bind_udp() method / built-in conversion would be the way to go.

I hope this all makes sense. Would be really awesome to see a patch for this functionality! :tada:

[deg4uss3r]

@yoshuawuyts Thanks for the link, I definitely agree and absolutely make perfect sense!