I found these, which were very informative:
http://www.port80software.com/200ok/arc ... 7/205.aspx
http://www.port80software.com/200ok/arc ... 3/212.aspx
The first shows what TIME_WAIT means, and the second explains why a web server accumulates many of these. Basically, after connection close the computer that initiated the close waits a certain amount of time (240 seconds or 4 minutes, as stated above) then frees the connection. During this time, the other computer is already disconnected.
So in my case, all those TIME_WAIT connections on my client should be disconnected from the server and waiting 240 seconds before closing. However, this would not explain why the FTP server eventually complains "Too many connections (8) for this IP" when I have no transfers active, and only 1 or 2 connections from Filezilla to the server.
FTP Client FTP Server
(Initiate close)
Send FIN
FIN_WAIT_1
-------------- FIN -------------->
Receive FIN
Send ACK
CLOSE_WAIT
(waiting for application to close)
<------------- ACK ---------------
Receive ACK
FIN_WAIT_2
Application has closed, send FIN
Connection is closed.
<------------- FIN ---------------
Receive FIN
Send ACK
TIME_WAIT
-------------- ACK ------------->
(I've switched the client and server from the original, since the TIME_WAIT's are on the client in my case).
So in that diagram, consider that the FTP client initiates a close by sending FIN. We go through the process till the FTP Server sends its FIN, at which point the FTP Client enters TIME_WAIT. At this point, if the router were stupid enough to prevent the last ACK from taking place, maybe the connections would end up TIME_WAIT on the client side, but the server would be stuck waiting for the last ACK to come through before releasing the connection.
This would only happen when the FTP client initiates the close, which (might be) what's happening when Filezilla tries to connect and gets a "421: Too many connections from this IP" error. Filezilla initiates close, the router screws it up, and we have an extra connection sitting around on the server side waiting to time out.
This would not happen during normal file transfer, since (if I remember correctly) the FTP server closes a data connection to signify the end of the data stream. If the router did not screw this one up, then the server would have a TIME_WAIT connection, but it would have been properly closed on the client side (and therefore no problems).
That's a crazy but seemingly plausible solution. I'm using a Buffalo G125 router with DD-WRT v24 Beta (08/15/07) std.
Here's another screenshot:
Shows about 4-5 minutes after transfers stopped. I purposefully set the simultaneous transfers high, to simulate the too many connections. However, then I stopped everything, waited a while, and then tried to transfer files again. It's been 10 minutes, still can't transfer anything. Right now Filezilla is closed, no connections at all. I open filezilla, it connects and lists the directory fine. I go to transfer, and get the "Too many connections" error and some more TIME_WAIT system process connections. This is pretty crazy, can't figure out what's causing it.
I did have one idea though... when I set "Max transfers" to 4, that doesn't include the data connection for the directory listing, does it? My server only allows 8 connections (including control & data connections, not sure if that's true), so I set max connections to 8. Then I set max transfers to 4. I go to transfer a folder, and filezilla starts listing folders recursively while transferring files. However, it's doing 4 transfers while listing a folder; 1 control & data to list folders, 4 control & data to transfer 4 files... 10 connections total? Does filezilla ignore the first control & data connection pair when enforcing the connection limit?
