2012/4/13, Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>: > Sending outstanding data then sending the RST afterwards is > potentially problematic as the receiver may not be able or willing to > read the data until its own data has been ACK'd, which would result in > deadlock. Could you tell me more about that? I can't see a case which would be problematic. Moreover shutdown(SHUT_WR) can actually send the outstanding data. >> The client send "QUIT;\n", the server read 'Q', 'U', 'I', 'T', ';', >> process "QUIT", send to the client Something that say "Ok, I quit" and >> close() the connection. >> However, a "\n" is still in the receive buffer of the server! That >> makes the server RST the connection ASAP and discard the messages that >> were not sent yet... Namely the "Ok, I quit" message which was delayed >> because of Nagle's algorithm or whatever. >> Annoying isn't it? > > If the server sends a response to the quit command, the client should > read the response then close() the socket. Provided that the server's > response is well-formed, there shouldn't be a problem. The client is ok. As soon as it receive "Ok, I quit" from the server, it close the connection. Although the server should also work with basic clients like netcat or telnet, which won't close the connection by themselves. Then the server just has to send its last message and close the connection. That's the protocol we expect: The server read the command "QUIT;", send its last message saying it's going to close the connection, and close the connection. The client is quite passive in the termination process, it read the response to the "QUIT;" and wait for the connection to be closed (its read should return -1). The problem is on the server side. Because of the unread "\n" (after the "QUIT;"), "Ok, I quit" is never sent. > Alternatively, using SHUT_WR with SO_LINGER allows the sender to > ensure that any data is sent before closing the read side, so even if > the connection does end in a RST, sent data won't be lost. > > However, this may be a moot point, as a connection terminated by RST > may result in close() indicating an error. For some protocols, that > will cause any "transaction" to be aborted; e.g. for POP3, any > messages marked for deletion by the DELE command should only be > deleted if the connection is terminated normally. That's not a problem since that was a student project. (I'm a teaching assistant and wrote a test script for their server.) But that's still worth noticing that the way a connection terminate can be meaningful. BTW, now I understand better what happen and why it happen, don't you think this behavior should be documented somewhere? Should I report a bug for the man 7 tcp? Celelibi -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
