On Wed, Aug 24, 2011 at 12:50 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > Le mercredi 24 août 2011 à 00:32 +0300, Daniel Baluta a écrit : >> On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > >> > TCP in RFC 1122 section 4.2.2.13: >> > >> > "A host MAY implement a "half-duplex" TCP close sequence, so that an >> > application that has called CLOSE cannot continue to read data from the >> > connection. If such a host issues a CLOSE call while received data is >> > still pending in TCP, or if new data is received after CLOSE is called, >> > its TCP SHOULD send a RST to show that data was lost." >> >> So, this means that server's CLOSE operation is issued while received >> data is still pending? I will analyze ftp's server code, but this is strange >> since P4 [221 Have a nice day!\r\n] it is generated as a response for >> P3 [QUIT\r\n]. So P4 must have been fully received. >> > > tcpdump only shows TCP stack did receive the frame, not that it was > _read_ by application. > > Only strace could eventually say if the input queue was really drained > before the close(). > Maybe server decided to close the connexion before reading the QUIT > command from client. > >> Also, looking at the capture no data is received from the client after >> server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8). > > That doesnt matter. > > If data was received (and ACKnowledged by TCP stack) _before_ close(fd), > but not yet read by application, TCP must send an RST to be RFC > compliant. I see. Thanks a lot for your explanations. I will further use strace to see what's going on. Daniel. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
