Tcp socket read always blocks

Question

I have a client TCP socket that writes a few bytes every five seconds, the server echoes the bytes right back.

Connect() and write() work just fine, and I have a callback at the IP layer that notifies me of the server's echo. This reliably happens between sends.

But I'm having trouble reading the echo from the socket.

I tried using select() to notify me of the incoming echo. Strangely, my callback wasn't invoked until I closed the socket, at which point it was called continuously. For each of these calls, however, read() returned -1/WOULD_BLOCK.

My second approach calls read() asynchronously when the IP layer notifies me of the incoming data. Similarly, read() only returns -1/WOULD_BLOCK. I realize the read() could beat the data to the socket layer, but hopefully it would just mean more to read after the next write.

I'm inclined to think I'm somehow misusing the API since I'm an IP/sockets noob and the select approach behaved so strangely.

It's unlikely a dumb bug since the nearly identical code path works perfectly for UDP mode. The only differences: for UDP I use DATAGRAM mode, sendto(), and recvfrom(). For TCP I use STREAM mode, write(), and read().

Answer 1

It appears the server was in a state where the TCP echo application had crashed, but UDP echo was fine and the TCP layer was still capable of handling traffic.

So my app would get notification from IP of incoming TCP and believe there was an echo to be read, but find no data at the socket layer. I expected this meant a problem with my use of the API or the layers between IP and sockets. Nope, the notification was for the server ACK rather than the echo, and since that is handled at the TCP layer, it never made it to the socket.