Celelibi wrote: > > 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. Assume that the remote end is single threaded. At any given time, it's either reading or writing. If it's writing, it won't be reading data, and it won't read any data until it has finished writing. If the reader doesn't consume the data (in the sense of ACK'ing it), the writer's send buffer will fill, and the writer will block waiting for the write to complete. While it's blocked, it isn't reading any data sent in the other direction. IOW: sending a RST doesn't require the cooperation of the remote end, sending data does. > > 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. If you want to get by without either side performing a half-close, one side must adhere strictly to the protocol, the other side must perform the initial close. If neither side can be relied upon to follow protocol exactly, you must use a half-close (as mentioned previously, rsh works like this as there isn't any "protocol" to follow; it's just free-form text in each direction). > 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? I wouldn't say it's a "bug" in the documentation. A manual page isn't really the place for a high-level overview of the TCP protocol. And the behaviour in question isn't related to a specific system call. close() isn't specific to sockets, shutdown() isn't specific to TCP sockets, and the same issue arises if the socket is closed implicitly as a result of process termination. What it really boils down to is that "receiving" data on a TCP socket which has been closed for reading will result in a RST; that much is in the RFCs, I believe. The practical consequence of that fact at the application layer is more appropriate in a tutorial or article. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> -- 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
