Opened 9 months ago

Closed 9 months ago

Last modified 9 months ago

#12398 closed Bug report (rejected)

too many connections (several dozens up to some hundreds) with settings max connections = 1

Reported by: Axel Owned by:
Priority: normal Component: FileZilla Client
Keywords: max connections Cc:
Component version: 3.53.0 Operating system type: OS X
Operating system version: 10.13.6

Description (last modified by Axel)

FileZilla Client 3.53.0 (macOS 10.13.6) cable internet (200 MBit/s)

Settings -> Transfers:

  • max simultaneous transfers: 1
  • limit for concurrent downloads: 1
  • limit for concurrent uploads: 1

Site Manager -> Transfer Settings:

  • maximum number of connections: 1

With these settings (see screenshots attached) I would expect, that only one connection is being used. Other than that (depending on how much files I transfer, lets say 1000) FileZilla creates during the FTPS transfer several dozens (up to some hundreds) connections to the server until I got blocked by the servers firewall.

Is this a bug or a feature? ;-)

Settings
Site Manager

Attachments (2)

FileZilla1.png (109.7 KB ) - added by Axel 9 months ago.
Settings
FileZilla3.png (27.3 KB ) - added by Axel 9 months ago.
Site Manager

Download all attachments as: .zip

Change History (7)

by Axel, 9 months ago

Attachment: FileZilla1.png added

Settings

by Axel, 9 months ago

Attachment: FileZilla3.png added

Site Manager

comment:1 by Axel, 9 months ago

Description: modified (diff)

comment:2 by Tim Kosse, 9 months ago

Resolution: rejected
Status: newclosed

With these settings there is only a single FTP connection. Note that an FTP connection actually consists out of multiple TCP connections: A long-lived control connection and a separate data connection for each individual transfer, one at a time.

FileZilla is perfectly capable of transferring thousands of files per minute given a fast enough network.

Please contact your server administrator so that the server's firewall can be fixed.

comment:3 by Axel, 9 months ago

When I use Cyberduck or NetBeans for the same task, no problems occur, these apps use only the number of connections as set (hundreds or thousands of files using only one connection, no disconnect from the server due to "too many connections"). I thought FileZilla is capable the same way, otherwise I have no clue what the settings as mentioned before are good for. Maybe some clarification of the effects of setting "max conn = 1" (while FileZilla uses multiple connections anyways regardless of these settings) could help to understand this problem. If I can use Cyberduck or NetBeans to transfer hundreds or thousands of files using only one connection without any problems and FileZilla gets blocked due to "too many connections" with default settings "no limits", it is obvious for me to change the settings from "no limits" to "only one" connection. Since this has no effect, I thought this is a bug. I'm a big proponent of FileZilla, even though I get my daily dues primarily done by IDEs, it has served me very well for many years on many platforms simultaneously :)
Maybe these "separate data connections for each individual transfer" doesn't get closed by FileZilla, so the timeout of the server has to kick in to get rid of that no longer needed but nevertheless existing connections?
I'm just wondering, cuz CD & NB get its job done with one connection, while FZ needs a lot ... my suspicion is CD & NB close their data connections when done, FZ does not (and let the server handle this, which leads to the mentioned problem)?

comment:4 by Tim Kosse, 9 months ago

FileZilla definitely closes the data connection. Closing the data connection is how the sender indicates the end of transfer.

Perhaps some firewall or NAT is dropping the connection without informing both peers. Is there anything unusual in the message log?

comment:5 by Axel, 9 months ago

No Firewall, no NAT, no dropping, no special messages. When I watch the simultaneous connections on the server (with something like "netstat -anplut | grep 'tcp\|udp' | grep -v '0.0.0.0\|127.0.0.1\|::' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr"), I can see the numbers growing up to many hundreds when FileZilla begins to transmit, which shouldn't happen with the settings max=1, as described in the initial post. These countless connections from FileZilla are getting only terminated by a certain timeout, but definitely not immediately at the end of each transfer (when the transmission is finished I can watch the connections die the same way as they grew). If FileZilla would terminate them immediately at the end of each transfer, they wouldn't grow limitless as they do. Cyberduck and Netbeans obviously terminate their connections immediately at the end of each transfer (and not after some timeout), because both of them use only one connection at the time. That is exactly what I expect from FileZilla when I set max=1 in the settings (as described in the initial post).

The Server accepts only a certain amount of simultaneous connections from one IP-Address at the time, otherwise the firewall blocks that host completely. A friend of mine (on Windows 10) and myself (on macOS 10.13.6) were testing several thousands transmissions, both of us with the newest versions of FileZilla, Cyberduck and Netbeans. Cyberduck and Netbeans use only one connection (as expected), therefore no problems at all. FileZilla is ignoring the setting max=1 (as described in the initial post) and uses as many connections as it wants until the firewall says „too much connections: bye bye“.

So, if you still think everything is alright with FileZilla, may it be, don't bother. I have always recommended FileZilla for many years, but unfortunately I can no longer do it (because max=1 doesn't work as expected). It would be nice if the problem could be fixed, but until then me and my customers won't have any problems with Cyberduck and Netbeans, we can recommend both programs with a clear conscience. I can't change the policies of some remote servers, but I can change the tools that I use to those that work as expected.

Note: See TracTickets for help on using tickets.