如何在go中发现客户端正在从tcp缓冲区读取

Question

I'm starting to use golang for a quite amount of time for a project. In my project I have to implement a tcp server which responds to tcp clients. The server has to send a number of messages to a client. The problem is that when a server writes a message to a client connection, it has to wait until the client has read that message from buffer and then send another message (the server has to wait until the client calls the reader.ReadString('\\n') method).

In my server code I wrote:

for {
    data := <-client.outgoing
    client.writer.WriteString(data + "\n")
    client.writer.Flush()
}

but the server sends all the messages to client without waiting for ReadString in client.

How to make server wait until the client read a message and then send the other message?

Answer 1

I think that either the assignment is ambiguous or you're misinterpreting it and solving the XY problem .

The short answer is that you can never know whether the client has read a message just by looking at the TCP conversation . You have to implement this "protocol" in your application.

Here are a few problems:

1. From your application you don't really have access to what TCP is doing. You get a stream on which you can perform I/O.

   • The fact that a write to your stream "succeeds" only means that TCP has agreed to try to transport your stuff and has an independent copy. It doesn't say anything about whether the data has been received and it doesn't even mean the data has been even sent
   • You may find certain mechanisms to peer into TCP's inner workings (such as ioctl s, SIOCINQ , SIOCOUTQ or various setsockopts): these won't help

2. Even if you find out what your TCP is doing, this only tells you what the remote TCP is doing . So if you have full control over your TCP and even see the acknowledgments from the peer, you still don't know what the application is doing . It's very possible the application didn't read the data yet (it might not have requested the data, the TCP might be withholding it in a buffer for some weird reason, the scheduler might not have scheduled the remote process etc.)

Going back to your question, a way to really know whether the remote application has received your message is to have the remote application tell you. This means you have to restructure your protocol to:

1. Send stuff from the server
2. Wait for a message from the application telling you it received your stuff
3. Send more stuff (because you know from point 2 it's safe to do so)