Semantics for UnixStream.read

[wweic]

Hey, I'm using UnixSteam for communication among 2 processes, and one process acts as client and the other acts as server. The client sends messages to the server on the Unix Domain Docket and wait for server response on the same socket.

I'm using the following snippet to read all data on the socket:

async fn receive_response(sock: &mut net::UnixStream) -> io::Result<()> {
    let mut buffer = [0; 5000];
    let mut total = 0;
    loop {
        println!("try reading");
        let n = match sock.read(&mut buffer[..]).await {
            Ok(n) if n == 0 => break,
            Ok(n) => {
                println!("read bytes length: {:?}", n);
                total = total + n as i32;
                n
            },
            Err(e) => {
                eprintln!("failed to read from socket; err = {:?}", e);
                break;
            }
        };

    }
    println!("Receiving bytes length: {:?}", total);
    Ok(())
}

Something I noticed is that the code will block indefinitely rather than return when there is no more data from the server. Is my observation correct? Thanks a lot for any advices.

My tokio version is 0.2.24.

[Darksonn]

The read call will block if there is no data available unless the server has closed the connection. Only when it is closed will read return Ok(0).

Note that your first clause in the match can be simplified to Ok(0) instead of using an if guard.

[wweic]

Thank you @Darksonn for the prompt response!!

Given the semantics of the read function, it's seems tricky to exhaust the data in a UnixStream? Say the server send the data over the socket back to client with 2 writes to the socket, and how can the client exhaust all the data in the socket without blocking itself? The client doesn't know if there is any more data in the docket without calling read, but in the case that there is no data in the socket, the client will block itself. Is there a solution for it? Of cause we can send the size of the data at the beginning, and the client knows how much data it can expect from the socket.

[Darksonn]

Generally you should always design your protocol so you know from looking at the data when you are done reading (e.g. include the length). You cannot rely on whether there is data right now to know whether the other end is done sending — what if they are sending more, but the connection is slow, so it seems like they stopped sending?

Of course, if you want to check whether data is available, we provide a try_read method, but you should always be prepared for the case where more data is coming shortly, but just has not yet arrived.