How to exchange data in a block_on section?

Question

I'm learning Rust and Tokio and I suspect I may be going in the wrong direction.

I'm trying to open a connection to a remote server and perform a handshake. I want to use non-blocking IO so I'm using Tokio's thread pool. The handshake needs to be performed quickly or the remote will close the socket so I'm trying to chain the message exchange in a single block_on section:

let result: Result<(), Box<dyn std::error::Error>> = session
    .runtime()
    .borrow_mut()
    .block_on(async {
        let startup = startup(session.configuration());
        stream.write_all(startup.as_ref()).await?;

        let mut buffer:Vec<u8> = Vec::new();
        let mut tmp = [0u8; 1];
        loop {
            let total = stream.read(&mut tmp).await;
            /*
            if total == 0 {
                break;
            }
            */
            if total.is_err() {
                break;
            }
            buffer.extend(&tmp);
        }
        Ok(())
    });

My problem is what to do when there are no more bytes in the socket to read. My current implementation reads the response and after the last byte hangs, I believe because the socket is not closed. I thought checking for 0 bytes read would be enough but the call to read() never returns.

What's the best way to handle this?

Answer 1

From your comment:

Nope, the connection is meant to remain open.

If you read from an open connection, the read will block until there are enough bytes to satisfy it or the other end closes the connection, similar to how blocking reads work in C. Tokio is working as-intended.

If closing the stream does not signal the end of a message, then you will have to do your own work to figure out when to stop reading and start processing. A simple way would to just prefix the request with a length, and only read that many bytes.

Note that you'd have to do the above no matter what API you'd use. The fact that you use tokio or not doesn't really answer the fundamental question of "when is the message over".