Feature request: Non-blocking WebSocket::read

[emilk]

WebSocket::read is currently blocking. I would love a non-blocking version that tries to read a message, and if there is none, returns immediately.

I want to accomplish something like this:

let socket = …
loop {
    while let Some(msg) = socket.try_read() {
        handle(msg);
    }

    if some_user_input {
        socket.send(…);
    }    

    …
}

I can accomplish this using tokio_tungstenite::connect_async and calling split on the resulting stream, but I rather not pull in async and tokio if I can avoid it!

[agalakhov]

WebSocket::read is blocking if and only if the underlying stream is blocking too. It is non-blocking if used with non-blocking version of TcpStream.

[agalakhov]

This feature is already there.

[emilk]

That's great news! But how do I accomplish this? Can I use tungstenite::connect or do I need to I need to use WebSocket::from_raw_socket? Is there an example I can follow?

[emilk]

I think I figured it out:

    match socket.get_mut() {
        tungstenite::stream::MaybeTlsStream::Plain(stream) => stream.set_nonblocking(true),
        tungstenite::stream::MaybeTlsStream::Rustls(stream) => {
            stream.get_mut().set_nonblocking(true)
        }
        _ => unimplemented!(),
    }?;

it would be nice if there was a socket.stream_mut() to access the underlying stream though

[agalakhov]

We already have this:
https://docs.rs/tungstenite/latest/tungstenite/protocol/struct.WebSocket.html#method.get_mut

[emilk]

Sorry, I meant the underlying TcpStream, instead of doing the incomplete match shown above

[agalakhov]

The WebSocket object does not know anything about the underlying stream at all. The underlying stream may or may not support non-blocking mode. While tungstenite provides a convenience wrapper for TcpStream and TLS from either rustls or native-tls, other variants have different ones. For example, tokio-tungstenite replaces std's TcpStream with the tokio one, which is always non-blocking and does not have any methods to switch modes. That's why we can't make any assumptions about underlying TcpStream. All we know is that it is readable and writable.