jrallen@devildog.UUCP (Jon Allen) (02/28/90)
I am having trouble understanding how the TCP protocol works when a connection is closed and the same connection is reused soon after closing (same end port numbers). [I am certainly no TCP protocol guru!] The sequence of events is a connection is established from machine A to machine B. This connection is closed and the same connection is opened a short time later, however a RST occurs. I have been told that this happens because the next SYN sequence number is within the 'window'. The following is an actual trace: . . . Packet #: 20 ether: IP machineA -> machineB 64 1007.728 14.233 ip: TCP 8201.0064 -> 8201.003c tcp: 1023 -> CMDSRV FIN ACK tcp: seq: 29252636 ack: 9361313 win: 4096 len: 0 Packet #: 21 ether: IP machineB -> machineA 64 1009.939 2.211 ip: TCP 8201.003c -> 8201.0064 tcp: CMDSRV -> 1023 ACK tcp: seq: 9361313 ack: 29252637 win: 8192 len: 0 # # Connection is closed at this point. The next SYN is an attempt # to open the same connection (same address and port numbers). # . . . Packet #: 24 ether: IP machineA -> machineB 64 2615.763 1588.359 ip: TCP 8201.0064 -> 8201.003c tcp: 1023 -> CMDSRV SYN tcp: seq: 29254401 ack: 0 win: 4096 len: 0 Packet #: 25 ether: IP machineB -> machineA 64 2618.096 2.334 ip: TCP 8201.003c -> 8201.0064 tcp: CMDSRV -> 1023 RST ACK tcp: seq: 9361313 ack: 29252637 win: 8192 len: 0 Packet #: 26 ether: IP machineB -> machineA 64 2619.358 1.262 ip: TCP 8201.003c -> 8201.0064 tcp: CMDSRV -> 1023 RST ACK tcp: seq: 0 ack: 29254402 win: 0 len: 0 . . . The above trace was edited for brevity and only the last part of the connection shutdown sequence is shown. However, it seems to conform to the TCP spec. After reading the TCP RFC several times, I cannot seem to understand how the sequence numbers should come into play on a reused connection. This trace brings up several questions: 1) Why is the RST generated by machineB? I have been told it is because the SYN sequence number is within the ack# plus the window size. 2) But if this is true then wouldn't some flakiness occur? For example, if the window size was small enough that the SYN flagged packet would be outside the window and work, wouldn't raising the window size then cause it to fail (can't window size be adjustable on some machines?)? This doesn't seem right to me. If someone could provide me with some enlightenment, I would appreciate it. -Jon ...!att!acpy01!jrallen attmail!jrallen
dls@mentor.cc.purdue.edu (David L Stevens) (03/01/90)
You get the RST from MachineB because it has to wait 2MSL (TIME_WAIT state in the TCP spec) to make sure that MachineA's idea of that connection has died. If MachineB gets anything else with the same port pair, it assumes it's a retransmission (normally) and ACK's it. Unfortunately, SYN is only allowed when MachineB's end is in LISTEN, but it's in TIME_WAIT. Ooops => RST. You'd get the RST regardless of the sequence numbers, though you'd get one for ACKing more than MachineB sent, if that were the case, too. The window management really isn't related though-- the problem is that MachineB can't be sure that MachineA got his ACK of A's FIN, so it has to wait around to handle retransmissions gracefully. It's doing the right thing and the solution is to have one of them pick a different port each time. -- +-DLS (dls@mentor.cc.purdue.edu)