仅在连接关闭时在端口上侦听TCP数据包才能读取数据

Question

I am creating a TCP server end in GO, which receives TCP packets and sends responses accordingly. I am able to listen to connections, but when the client-end sends TCP packets to the server, the server only receives them when the connection is reset (TCP RST).

This means that when the client sends a packet, the server waits for the next packet to do something with the first. This is the code affecting this part of the problem:

listener, err := net.Listen("tcp", ":25565")

if err != nil {
  fmt.Println(err)
}

for {
  conn, err := listener.Accept()

  if err != nil {
    fmt.Println(err)
  }

  message, _ := ioutil.ReadAll(conn) // Get the bytes from the TCP packet
  fmt.Println("Received connection " + conn.RemoteAddr().String())
  HandlePacket(conn, message) // Do stuff with the data
  conn.Close() // End the connection
}

HandlePacket(...) parses the bytes received in the packet. The thing is, it receives nothing when the client sends the first packet, and then prints the first packet's data when the second is sent.

Answer 1

The big hint is right there in your call to read from the socket:

message, _ := ioutil.ReadAll(conn) // Get the bytes from the TCP packet

ReadAll() won't just return the available data in the socket's buffer. ReadAll() is going to read until there's never going to be any more data to read - until the stream is closed. The stream is closed only when the connection is closed, as you've seen.

You have to ask the TCP socket to read some finite amount of data. Since TCP does not preserve message boundaries, you have to use your own framing scheme to know how much data to read.

One such simple scheme is to make it so that your packets are always some fixed size. This might be useful, for instance, if you're sending streaming updates for, say, a game's netcode; just make each packet 256 bytes and stuff in as many position updates as will fit in 256 bytes; if there's more, just send more packets.

If using a fixed-sized frame doesn't work for you, consider using a packet with a little header. Perhaps the first 4 bytes are an integer telling you how long the message is, followed by the message. Then, every time you want to read a packet, you perform a hard read of 4 bytes to find out the size, and then read that many bytes from the socket.