On Fri, 31 Jan 2020 14:00:27 +0000 David Laight <David.Laight@xxxxxxxxxx> wrote: > From: sjpark@xxxxxxxxxx > > Sent: 31 January 2020 12:24 > ... > > The acks in lines 6 and 8 are the acks. If the line 8 packet is > > processed before the line 6 packet, it will be just ignored as it is not > > a expected packet, and the later process of the line 6 packet will > > change the status of Process A to FIN_WAIT_2, but as it has already > > handled line 8 packet, it will not go to TIME_WAIT and thus will not > > send the line 10 packet to Process B. Thus, Process B will left in > > CLOSE_WAIT status, as below. > > > > 00 (Process A) (Process B) > > 01 ESTABLISHED ESTABLISHED > > 02 close() > > 03 FIN_WAIT_1 > > 04 ---FIN--> > > 05 CLOSE_WAIT > > 06 (<--ACK---) > > 07 (<--FIN/ACK---) > > 08 (fired in right order) > > 09 <--FIN/ACK--- > > 10 <--ACK--- > > 11 (processed in reverse order) > > 12 FIN_WAIT_2 > > Why doesn't A treat the FIN/ACK (09) as valid (as if > the ACK had got lost) and then ignore the ACK (10) because > it refers to a closed socket? Because the TCP protocol (RFC 793) doesn't have such speculation. TCP is stateful protocol. Thus, packets arrived in unexpected state are not required to be respected, AFAIU. > > I presume that B sends two ACKs (06 and 07) because it can > sit in an intermediate state and the first ACK stops the FIN > being resent? I think there is no such presume in the protocol, either. > > I've implemented lots of protocols in my time, but not TCP. If you find anything I'm misunderstanding, please don't hesitate to yell at me. Hope the previous discussion[1] regarding this issue to be helpful. Thanks, SeongJae Park [1] https://lore.kernel.org/bpf/20200129171403.3926-1-sjpark@xxxxxxxxxx/ > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales)
