Jump to content


Photo

421 Too many connections (8) from this IP


This topic has been archived. This means that you cannot reply to this topic.
4 replies to this topic

#1 Driskell

Driskell
  • Members
  • 1 posts

Posted 26 August 2006 - 03:00 PM

Whenever I use the queue, after a specific period of time I get "421 Too many connections (8) from this IP".

File transfers go as normal, and after a specific time when SmartFTP tries to start a transfer, for some reason the connection breaks or something and the server doesn't reply, then SmartFTP only half closes the connection.

I'd have 4 threads in the Queue all stuck on Waiting to rety. And 8 connections open in the FIN_WAIT_2 state (I ran netstat.)

Why aren't the connections properly closing? I looked up FIN_WAIT_2 and it's as if the socket is waiting the server to close the connection... but the server's already done that cause of timeout.

I'm totally confused and it causing alot of problems because I have to wait at least 30 minutes before I can start connecting again, only to have it stop after 10mins of transfering again. ><

Any way to fix this or is it a bug in the client? Don't think it's bug in server because it works totally fine for my friends who use different clients.

Thanks in advance.

TCP	jasons:2694			server1:ftp  FIN_WAIT_2
TCP	jasons:2695			server1:ftp  FIN_WAIT_2
TCP	jasons:2696			server1:ftp  FIN_WAIT_2
TCP	jasons:2697			server1:ftp  FIN_WAIT_2
TCP	jasons:2699			server1:ftp  FIN_WAIT_2
netstat looks like that

[15:58:44] RETR icon.gif
[15:59:05] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
And that's what starts all the problem :unsure:

#2 Ryan J Williams

Ryan J Williams
  • Members
  • 18 posts

Posted 20 October 2007 - 01:10 AM

I'm suffering from pretty much identical symptoms to these. Looks like a bug that crops up in certain circumstances.

I do my connections, a transfer fails, and somehow it keeps the connection going. The queue system will then seem to somehow forget about this broken connection and try to add another (so if my theoretical worker limit is 5, it'll add a 6th).

After a few cases of this I've gone over my server's limit of 8 connections and I'm screwed. SmartFTP will amusingly then continue to try and add more and more workers, forgetting about the broken ones; this results in my entire 100+ queue trying to retry at once. <_<

There is absolutely no doubt that SmartFTP is the one leaving these connections open; I have nothing else running, let alone interfacing with the server. I've also used cPanel to look at the live FTP sessions and indeed, there're 8 just sat there as 'IDLE'.

This isn't a problem that other FTP clients seem to suffer from, including Windows Explorer itself.

#3 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 20 October 2007 - 08:45 AM

Hello Ryan ...

Do you know what triggers this problem? Can you reproduce it? Does it only happen with some servers?

Regards
Mat

#4 Ryan J Williams

Ryan J Williams
  • Members
  • 18 posts

Posted 23 October 2007 - 03:56 PM

Unfortunately I can't find anything that might be causing it on the server end. All I can tell you is it was on a cPanel-powered server, and I didn't test it exhaustively enough to work out if other servers had the same issue.

I did actually manage to get it working though by using active mode instead of passive, and making stuff time out after a very short amount of time. This seems to keep things flowing, although I've never heard of passive/active problems manifesting in that way before. <_<

#5 mb

mb

    Developer

  • Administrators
  • 11521 posts

Posted 27 October 2007 - 09:29 AM

If you can provide information on how to reproduce it we will be able to fix the problem.

The connections you see are control connections (to port 21). It would be interesting to figure out why the PASV command does trigger the problem and the PORT command doesn't.

Any help you can provide is appreciated.
Thank you.
Regards,
Mat