Chrono79 Posted October 27, 2005 Report Share Posted October 27, 2005 Well, another post about this, I've searched and tried the suggestions in the other posts but none worked for me.XP + sp2 (lvlord patch allowing 500 connections)No router, XP firewall allowing utorrent to connectADSL 256/128utorrent 18.104.22.168utorrent settings:-Maximum global connections: 200-Maximum number of clients per torrent: 40-Maximum number of upload slots per torrent: 3-Maximum global upload rate set at 8kB/sOnly downloading 1 torrent.I've noticed using "netstat -a" a lot (more than 80!) of "CLOSE_WAIT" from the same IP (but from different ports). The IP was from one peer from a torrent. Right now I'm not connected to that peer and the "CLOSE_WAIT" are still there. Is there anything I can do to solve this? (I mean if it's related to my problem: I can't browse because of the time outs, images not loading, etc.) The only way to get rid of the "CLOSE_WAIT" was to disconnect and reconnect to internet (closin utorrent didn't work)I've found this, here:Sometime sockets are in CLOSE_WAIT state, this state conducts when a client doesn't answer back anymore with the last ack N+1. A client crashing while they had a connection is occurring may times as a result the socket isn't closed properly, but much more occurring bad programming is the issue why sockets are closed inappropriate. Most socket developers forget to give a explicit call for shutdown() before the close()/ socketclose(). The shutdown(RDWR) flushes the socket send and receive buffers and tells the other side to stop sending data and that it don't have to expect data anymore. As a close()/ socketclose() is called upon the chance on a CLOSE_WAIT state is out of the question at the side of the software. According to the TCP specifications the server has to stay in CLOSE_WAIT state to be sure that all data (TCP guarantees data transmission) is transmitted. Lot of OS developers saw this problem in the TCP specifications and added a (friendly) timeout to the CLOSE_WAIT that in most cases is adjustable. Windows NT and 2000 doesn't foresee in a CLOSE_WAIT timeout parameter, the only way to free those resources is restarting. When there are structural CLOSE _WAIT(s) on a certain service, the best way is to contact the reseller of the service or client(s) to solve this problem because this is a clear software problem with the service, client(s) or both. Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.