2012/4/12, Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>: > IIUC, he close()s a socket which has unread data. Whether the data had > already been received when close() was called or whether it arrived > afterwards doesn't matter. Right. > > Normal behaviour is simply not to use close() or shutdown(SHUT_RD) if > you expect to receive more data, e.g. wait until you have seen EOF > (i.e. read(), recv() etc return a zero count) before closing the read > side of the socket. I don't care about these data. I don't want to read them. If there are too much data after the client sent a QUIT command, it have to receive a RST. > AFAIK, there is no way to make close() or shutdown(SHUT_RD) silently > discard subsequent inbound data. And that's ok because that's not what I want. :) > Alternatives include: > > 1. ACK and discard the data. But then there would be no way for the > sender to identify that it's writing to a closed socket. Right. > > 2. Do nothing. The receive buffer will fill, the window will close, > and the sender will block until someone kills it (it won't time out > because probes will still be met with an ACK of the last byte which > fitted into the buffer). > > If the OP wants to send outstanding data, but doesn't want to wait for > EOF from the sender, the solution is to use SO_LINGER with a long > timeout and shutdown(SHUT_WR). The shutdown() won't return until the > FIN (and everything before it) has been ACK'd. At that point, he can > just close() the socket; presumably it won't matter if subsequent data > results in a RST (if it does matter, there is no alternative to > reading until EOF). > Actually, shutdown(SHUT_RDWR) do the trick since shutdown(SHUT_WR) forces the unsent data to be actually sent with a FIN flag. And since shutdown(SHUT_RDWR) send the outstanding data, why don't close() do the same? I don't get it. And of course, calling close() after shutdown() send a RST because of the unread data. 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
