I think you missed my later email stating that my first one was a mistake. I confused "CLOSE_WAIT" and "TIME_WAIT". The later is unavoidable, the former is.
When you ask an application to shut down a socket, it sends a FIN out, and enters "FIN_WAIT1". When that FIN is acknoledged, the socket moves to "FIN_WAIT2". The socket is now "half closed". You are not allowed to send any more data on it, but the other side is. When the other sides decides to shut the socket down as well, it will send a FIN. Your side will acknoledge that, and enter the "TIME_WAIT" state for a period of time. This is necessary in case the ACK was lost on its way back. The other side will retransmit the FIN, and our side needs to remeber what the !#$*(! it is all about, so the ACK can be retransmitted. After a certain amount of time TCP assumes that no retransmits are going to come, and removes the socket altogether. Switching to the other side, the connection is established. When a FIN arrives, the connection is marked "CLOSE_WAIT" and the FIN is acknoledged. When the application on that side chooses to close, TCP sends a FIN and switches to "LAST_ACK". When the FIN is ACKed, the socket is immediatly closed, and is no longer seen (which is, of course, utter bullshit. It is still around for a little while as "CLOSED", but that's not relevant). If you are accomulating "CLOSE_WAIT" sockets, the best bet (as both oded and "lordsoth" already told you) is that the side that sees that the socket has finished sending stuff neglects to shut the socket down properly. As I have said in my previous mail, you can either use "shutdown" and then "close", or immediatly use "close" (the former is better). Michael Sternberg wrote: >Everybody on the Net keeps telling me that they are nessessary. I have a >client/server utility, both sides are at my control. It works for some >two-three weeks and then computer flooded with CLOSE_WAITS, I can not open >more sockets and have to restart application (or reboot computer). I'm using >every recommended techniques from Stevens book - shutdown, linger, SO_REUSEADDR >etc... without any success. Can it be some kernel bug ? > I think the problem is that you are, indeed, using "shutdown", but not closing the socket. Let me venture a wild guess here. You have ~1024 "CLOSE_WAIT"s when the problem happens? The problem has nothing to do with either kernel nor TCP/IP. The problem is that your application has a limit on how many open file descriptors it has. When that limit is reached, no new file descriptors will open, and you will probably get similar symptoms to what you have. Make sure that you call "close" for each socket when you are done with it. > I can never reproduce >this situation manually but it happens quite frequently. And it is very >frustrating. There are plenty Linux Internet applications (Apache for example) >that supposed to work 24/7/365. How do they handle this problem ? > > > > They don't leak resources. > >Can you be more detailed ? You mean, I have to get from 'netstat' port that >socket in CLOSE_WAIT state is listening to, somehow guess TCP sequence numbers >and send ACK+FIN there ? > > I was thinking of a RST, but basically, yes. > > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
