For example, in a TCP Tahoe connection, if there is a large file transfer happening. Suddenly the receiving process or host is shutdown or suspended, I know that we will have a timeout, at which point the window size will be reset, etc. As I understand it we will resend the packet that was unacknowledged, and then try again, and possibly again?
I am wondering though, after a timeout such as this how many times data will get resent before it is assumed the receiver is no longer there and data will stop being sent. If the process is resumed from a suspended state will it be able to keep receiving data?
I know that data is re-transmitted after a triple duplicate ack or a timeout. However, I cannot find much to read on what happens if there is multiple re-transmissions fail, or if a receiving process is suddenly stops receiving.
If the receiving process exits or is killed, the socket at its end will be shut down. When the sender continues sending packets, they should prompt RST packets, which will cause an error (ECONNRESET) immediately.
If the receiving host is shut down cleanly, it should kill all processes, which will cause the above to occur.
If the receiving host and process are alive, but the process is suspended (e.g. Ctl-z), no problem will be detected at the TCP level. The window will eventually fill up, but the receiving system will continue to acknowledge the zero-window probes. To detect this case, you need an application-layer keepalive mechanism.
If the receiving host crashes, loses power, or its network connection fails, that is when retransmission timeouts become relevant. The number and frequency of retransmissions is implementation dependent, and may also be controlled by system configuration parameters. I don’t know offhand what are typical parameters.
If the receiving system reboots before the timeout occurs, it will resond to the next retransmission with a RST packet, which will cause the ECONNRESET error.