What occurs if the line goes off ?!

Recently, with the developement of the technology of computer network, the packet loss can mainly be attributed to the network congestion. If a packet is lost, the packet will be retransmitted. In this section, I would like to observe how the retransmission is observed by tcpdump. However, how can it be realized by our current topology? ... it is quite easy actually. Two Unix machines are connected to the same HUB in the current configuration. If we disconnect the line physically, the packet cannot be sent and it will be retransmitted. The following Server side program and Client side program are used.

Server side program
Client side program
Header file

Case 1: When the line is disconnected before TCP connection is established:
11:55:05.422719 130.69.250.34.1336 > 130.69.250.35.6998: S 2884660628:2884660628(0) win 16384  (DF)
11:55:07.980272 130.69.250.34.1336 > 130.69.250.35.6998: S 2884660628:2884660628(0) win 16384  (DF)
11:55:13.980273 130.69.250.34.1336 > 130.69.250.35.6998: S 2884660628:2884660628(0) win 16384  (DF)
11:55:25.980289 130.69.250.34.1336 > 130.69.250.35.6998: S 2884660628:2884660628(0) win 16384  (DF)
11:55:49.980294 130.69.250.34.1336 > 130.69.250.35.6998: S 2884660628:2884660628(0) win 16384  (DF)
... then this message was shown in the client side:

taka@kaynet(129)> client jordan
connect: Operation timed out
taka@kaynet(130)>

The connection could not be established and the program has been terminated.

The interval of Retransmission was: 2.5, 6.0, 12.0 and 24.0 seconds.

Case 2: The line goes off after TCP connection is established:
12:06:38.200340 130.69.250.34.1349 > 130.69.250.35.6998: S 3018240136:3018240136(0) win 16384  (DF)
12:06:38.200479 130.69.250.35.6998 > 130.69.250.34.1349: S 381603821:381603821(0) ack 3018240137 win 32736 
12:06:38.200522 130.69.250.34.1349 > 130.69.250.35.6998: . ack 1 win 17520 (DF)
========== Line was disconnected ============
12:06:48.210345 130.69.250.34.1349 > 130.69.250.35.6998: P 1:1001(1000) ack 1 win 17520 (DF)
12:06:49.480276 130.69.250.34.1349 > 130.69.250.35.6998: P 1:1001(1000) ack 1 win 17520 (DF)
12:06:51.480270 130.69.250.34.1349 > 130.69.250.35.6998: P 1:1001(1000) ack 1 win 17520 (DF)
12:06:55.480277 130.69.250.34.1349 > 130.69.250.35.6998: P 1:1001(1000) ack 1 win 17520 (DF)
12:06:58.220323 130.69.250.34.1349 > 130.69.250.35.6998: F 1001:1001(0) ack 1 win 17520 (DF)
========== Client program has been terminated ==========
12:07:03.480297 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:07:19.480299 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:07:51.480294 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:08:55.480300 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:09:59.480302 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:11:03.480298 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:12:07.480291 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:13:11.480290 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:14:15.480286 130.69.250.34.1349 > 130.69.250.35.6998: FP 1:1001(1000) ack 1 win 17520 (DF)
12:15:19.480285 130.69.250.34.1349 > 130.69.250.35.6998: R 1002:1002(0) ack 1 win 17520 (DF)
Retransmissions occur with the interval 1.2, 2,and 4 seconds. After 4 trials, client program has been terminated. Strangely, TCP retransmission occurs after then. The retransmission occured 10 times, the first one occured 5 seconds after the client program has been terminated. With the interval 16, 32, 64, 64, 64, 64, 64, 64 and 64 seconds, the retransmission occured. What is tremendous is, I think, that retransmission occurs after the program is ended. This is, probably, the reason why TCP is called "Reliable transmission" ...:p

Case 3: The line goes off just before TCP connection is finished:

nobu@icnet.ne.jp