> >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 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 ?
CLOSE_WAITs are essential for the whole TCP scheme. It lets you keep a half-open connection where you can still send data. However, if for some reason you don't want half-open connections, you should handle this in your code. What I was saying earlier was that for example, read() returns 0 when a FIN is received (i.e: moving to the CLOSE_WAIT state). What you should basically try to do is to find out where in your code read() receives 0. If you have a wrapper function for it, that's trivial. Breaking when it returns 0 with gdb and looking at the backtrace, one method I can think of... If you'd like, maybe you can post some code if it's alright with others.... It's most likely NOT a kernel bug since other servers seem to work just fine. What platform are you developing on ? I can tell you that a server I wrote under RH 6.2 works just fine, and has an uptime of more than a year. Anyways, if you'd like to verify that read() receives 0, check out Unix network programming on page 774: "Recall with a TCP socket that the receipt of a FIN causes read to return 0..." >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 ? Guess ? no. You might be able to insert a RST if you know the sequence numbers (which you can find with tcpdump), but then you'll have to stop other packets and insert your own. It's quite a hassle and difficult to manage I believe. Regards, Eli "There's so many different worlds So many different suns And we have just one world But we live in different ones.." - Dire Straits ================================================================= 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]
