Does Tokio/Mio allow for busy socket detection?


#1

Long story short I’m debating rewriting my RTMP live streaming server and client from Elixir into Rust. The only way this makes sense (for my goals at least) is to take advantage of a networking event loop, meaning mio or tokio.

When a live streaming client or server sends video it needs to keep things as real time as possible, and it does this by dropping audio and video packets if the socket’s buffer is full (as opposed to waiting for the socket to be available to send again). This occurs when the connection between a client and a server degrades and cannot handle the bandwidth required for the live video (whether temporarily or permanently).

Is there a way to detect this situation in mio and/or tokio?


#2

I’m assuming you’re dealing with tcp?

If you try to write/send data to a tcp sock whose send buffer is full, mio will return an error with WouldBlock error code. That’s the “signal” that the peer (or network) is unable to handle the current bandwidth. You can then decide how to handle this case, such as dropping data.

Tokio I/O builds on top of mio, but provides a futures-based API. You won’t see WouldBlock directly, but instead your write operation’s future won’t resolve until the sock buffer has room again. So there you’d probably want to combine a write with a timeout future, and select the one which resolves first. If the timeout expires, then it’s a symptom of the same thing - network and/or client cannot handle the data rate.


#3

Yep TCP, sorry I should have noted that.

Thanks, that sounds like exactly what I need.