Client sometimes only receives one message out of two

[jamesmcl113]

I'm currently building a simple chat server and client, with the server based heavily off the chat example in the repo. It was working fine for a long time but I'm now running into an issue when I try and send two responses to the client sequentially. Once the client has connected successfully, I want to send two responses however sometimes only the first one is received on the client side.

server/main.rs

    send_response(
        &mut user.bytes,
        Response::Server(model::ServerResponse::JoinedServer {
            username: name.clone(),
        }),
    )
    .await;

    send_response(
        &mut user.bytes,
        Response::Server(model::ServerResponse::JoinedRoom {
            room_name: "main".to_string(),
        }),
    )
    .await;

and send_response is defined:

pub async fn send_response(stream: &mut Stream, res: Response) {
    let res_bytes: Vec<u8> = res.into();
    stream.send(Bytes::from(res_bytes)).await.unwrap();
    <Framed<TcpStream, BytesCodec> as SinkExt<Bytes>>::flush(stream)
        .await
        .unwrap();
}

(I added the flushing here to try and fix the issue but as far as I can tell it makes no difference.)

And on the client side I use tokio::select to read from the stream and send a message that can be picked up by the synchronous part of the code:

        std::thread::spawn(move || {
            rt.block_on(async move {
                loop {
                    let mut buf = [0u8; 1024];
                    tokio::select! {
                        res = reader.read(&mut buf) => {
                            match res {
                                Ok(0) => todo!(),
                                Ok(n) => {
                                    let res: model::Response = bincode::deserialize(&buf[0..n]).unwrap();
                                    tx.send(res).unwrap();
                                },
                                Err(_) => todo!(),
                            }
                        }
                        task = recv.recv() => {
                            if let Some(task) = task {
                                tokio::spawn(handle_task_raw(writer.clone(), task));
                            }
                        }
                    }
                }
            });
        });

The main loop of the client tries to read from this channel and display the responses:

    loop {
        while let Ok(res) = rx.try_recv() {
            state.handle_response(res);
        }

        terminal.draw(|f| ui(f, &state))?;

        match event::poll(Duration::from_millis(100)) {
             // snipped input handling code
         }
    }

I'm out of ideas for why this behaviour is happening so any help would be much appreciated. Full code can be found here.

[Darksonn]

When you read/write directly to a TcpStream, then there are no "message boundaries". You are simply sending a sequence of individual bytes in some order. Some examples:

• Writes can be split: A single write of [a, b, c] might be appear as two reads [a, b], [c]
• Writes can be merged: Two writes of [a, b], [c, d] might appear as a single read [a, b, c, d]
• And any other split is possible: Two writes of [a, b], [c, d] might appear as three reads [a], [b, c], [d].

You are using BytesCodec, so this is the behavior you are asking for.

If you don't want this, you must use a different codec. For example the length delimited codec will keep track of message boundaries for you. It does this by writing the length of each message before the message so that it knows how many bytes to read to get the full message.

[jamesmcl113]

Thanks for this response. So could I just use the length delimited codec on the server side and read messages as normal on the client side? Currently I'm just using a BufReader in the client to get messages.
And another question, why don't I get any errors on the client side if the writes are being merged/split?

[Darksonn]

No, both sides must use the length delimited codec.

As for why you weren't getting errors, well, the splitting was probably happening in a lucky way.