tags:

views:

461

answers:

3

I know that TCP is very reliable, and what ever is sent is guaranteed to get to its destination. But what happens if after a packet is sent, but before it arrives at the server, the server goes down? Is the acknowledgment that the packet is successfully sent triggered on the server's existence when the packet is initially sent, or when the packet successfully arrives at the server?

Basically what I'm asking is - if the server goes down in between the sending and the receiving of a packet, would the client know?

+5  A: 

It really doesn't matter, but here's some finer details:

You need to distinguish between the Server-Machine going down and the Server-Process going down.

If the Server-Machine has crashed, then, clearly, there is nothing to receive the packet. The sending client will get no retry-requests, and no acknowledgment of success or failure. After having not received any feedback at all, the client will eventually receive a timeout, and consider the connection dropped. This is pretty much identical to the cable being physically cut unexpectedly.

If, however, the Server-Machine remains functioning, but the Server-Process crashes due to a programming bug, then the receiving TCP stack, which is a function of the OS, not of the process, will likely ACK the packet, and any others that arrive. This will continue until the OS notifies the TCP stack that the process is no longer active. The TCP stack will likely send a RST (reset) notice to the client, or may drop the connection (as described above)

abelenky
+1. Just to clarify, though: tcp does not provide guaranteed delivery, it only provides reliable delivery.The ACK comes from the receiver's TCP stack, so there will be no response if the server machine goes down, as abelenky says.
Don Branson
Also: the client may only be notified of the connection being dropped (or a reset) if it reads on the socket after sending the data (unless the client's send buffer fills up before it sends all the data).
Miles
If the client needs to know if the data was sent successfully, best practice is for the application protocol to have the server send an acknowledgement when the transfer is complete (rather than relying on network protocol open/close handshaking, which violates OSI layer separation).
Miles
I think I need to emphasize: the sending-client doesn't know if the final packet got there or not, because it never received an ACK. Therefore, it must ASSUME that the packet did not arrive at its destination.
abelenky
+2  A: 

This is basically what happens. The full reality is hard to describe without getting tied up in unnecessary detail.

TCP manages connections which are defined as a 4-tuple (source-ip, source-port, dest-ip, dest-port).

When the server closes the connection, the connection is placed into a TIME_WAIT2 state where it cannot be re-used for a certain time. That time is double the maximum time-to-live value of the packets. Any packets that arrive during that time are discarded by TCP itself.

So, when the connection becomes available for re-use, all packets have been destroyed (anywhere on the network) either by:

  • being received at the destination and thrown away due to TIME_WAIT2 state; or
  • being destroyed by packet forwarders on the net due to expired lifetime.
paxdiablo
A: 

When you send a packet to the network there is never a grantee it will get safely to the other side. The reliability of TCP is achieved exactly as you suggest using acknowledgment packets.

shoosh