0

Regarding TCP connections using NetGui (and wireshark for analyzing):

I set a TCP connection between two PCs using the command nc -p 11111 etc... for the server, and the corresponding one for the client, so that they were indeed able to send and read (in pc2 (server)) messages.

After that, I pressed Ctrl Z in pc2 (server should be suspended) and sent some messages with pc1 (client). By using netstat -tna command I'm able to see the messages waiting in the buffer. Before bringing the server back to foreground I stop the tcpdump capture in the router between these two pcs and realize that these messages had been sent (as expected) but also ACKed by the server.

Now, if the server ACKs messages as they leave the buffer (i.e. as they are processed and moved up to another layer), were these messages really 'grabbed' from the buffer by the server? If so, what is the meaning of being suspended?

If, however, messages are ACKed before being processed, then wouldn't pc1 think these messages have been processed and so, the buffer is free and keep sending messages until the window gets zero value? If so, what is the meaning of the following formula?

rwnd = ReceiveBuffer - (LastByteReceived – LastByteReadByApplication)

Where am I wrong?

0

TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.

The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.

  • Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct? – Paul Jan 14 at 20:08
  • The server process (netcat/nc in your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes like nc. So when nc is suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely. – Spiff Jan 14 at 21:01
  • Understood. Great job and muchas gracias, Spiff – Paul Jan 14 at 22:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.