Learning Async Rust with Too Many Web Servers

• tcpproxy

  3 121 5.3 Rust

  A cross-platform TCP proxy in tokio and rust (by mqudsi)

  Thanks. Perhaps I did go overboard with that disclaimer.. probably because I myself made the mistake of initially using [0] the oh-so-convenient tokio::io::copy() instead of writing my own copy method that would drop the other half of the connection when one side was closed.

  The copy_with_abort() routine is still taking the easy way out in this not-optimized-for-heavy-production-use sample because it uses a broadcast channel per connection to reactively signal that the other half of the connection should be closed (rather than timing out every x ms to see if an abort flag has been set). In the real world, I'd probably replace the join! macro with a manual event loop to be able to do the same but without creating a broadcast channel per-connection.

  (I maintain an extremely lightweight "awaitable bools" library for rust [1] that is perfect for this kind of thing (roughly equivalent to a "bounded broadcast_channel<()> of queue length 1, but each "channel" is only a single (optionally stack-allocated) byte) — but it's for event loops in synchronous code and not async executor compatible.)

  [0]: https://github.com/mqudsi/tcpproxy/commit/0164ef836a49f2f738...

  [1]: https://github.com/neosmart/rsevents

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• rsevents

  4 19 10.0 Rust

  Auto- and manual-reset events for rust

  

  Thanks. Perhaps I did go overboard with that disclaimer.. probably because I myself made the mistake of initially using [0] the oh-so-convenient tokio::io::copy() instead of writing my own copy method that would drop the other half of the connection when one side was closed.

  The copy_with_abort() routine is still taking the easy way out in this not-optimized-for-heavy-production-use sample because it uses a broadcast channel per connection to reactively signal that the other half of the connection should be closed (rather than timing out every x ms to see if an abort flag has been set). In the real world, I'd probably replace the join! macro with a manual event loop to be able to do the same but without creating a broadcast channel per-connection.

  (I maintain an extremely lightweight "awaitable bools" library for rust [1] that is perfect for this kind of thing (roughly equivalent to a "bounded broadcast_channel<()> of queue length 1, but each "channel" is only a single (optionally stack-allocated) byte) — but it's for event loops in synchronous code and not async executor compatible.)

  [0]: https://github.com/mqudsi/tcpproxy/commit/0164ef836a49f2f738...

  [1]: https://github.com/neosmart/rsevents

• glommio

  30 3,123 7.5 Rust

  Glommio is a thread-per-core crate that makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans.

  

  I think you missed one which is based on io_uring [1].

  In my benchmarks with a slightly tweaked version it was 2x faster than Nginx and and 30x faster than Python's SimpleHttpServer.

  [1] https://github.com/DataDog/glommio/blob/master/examples/hype...

Suggest a related project