Review of async networking code

Hi,
I have a project where I'm building a multiplayer networking library for the bevy game engine.
I'm adding multiple Transports that are basically a way to just read/write a slice of bytes over the network.

I've added to dabble with async with it but I feel like i'm doing a lot of things wrong still.
(For example a big problem that I had was that I was using tokio::select, but my futures were not cancel-safe and I was losing some data everytime one of the futures was chosen).

The repo is here: GitHub - cBournhonesque/lightyear: Networking library for the Bevy game engine
but i'm particulary interested in thoughts on how the Transport trait is implemented (for example lightyear/lightyear/src/transport/webtransport/client_native.rs at main · cBournhonesque/lightyear · GitHub and lightyear/lightyear/src/transport/webtransport/server.rs at main · cBournhonesque/lightyear · GitHub)

Some questions I have:

  1. some of the crates I use (tungstenite/wtransport) apparently need the tokio reactor, but bevy uses the smol executor, so I had to wrap my futures with GitHub - smol-rs/async-compat: Compatibility adapter between tokio and futures . Are there any caveats to doing so?
  2. I currently don't have a good way for the server or client to forcefully close the io or connection. How should I do that, via a drop?
  3. Can futures be cancelled and stopped on wasm? I wasn't able to find any function to do that.
  4. I was a bit confused by Streams. Are they just futures that can return None (on top of Poll:Pending and Poll:Ready) to indicate that the stream is definitively closed?
  5. I'm using this "oneshot" channel to close the connection if the sink or stream are closed (lightyear/lightyear/src/transport/websocket/server.rs at main · cBournhonesque/lightyear · GitHub) but it doesn't seem great to me.. Should I instead be using smol::race? Race in smol::future - Rust
  6. I've deployed the examples with wasm here: Examples - Lightyear cheatbook
    but it looks like when a client switches to a different tab the client wasm thread doesn't make any progress anymore, so the connection times out very quickly. What can I do to avoid this? Is there a way to make wasm run in the background? Or should I just increase the connection timeouts?

I know that's a lot of questions; but any help is appreciated! I feel like async is fairly daunting and i'd really like to have some mentoring.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.