Support multi-threaded multipart downloads

[mrcapture]

FileZilla is really great software, but the feature I am
missing most is the ability to actually download ONE
file using multiple parallel connections. Many FTP
servers (including the one of the company I work for)
limit the bandwidth per connection, very often this limit
is in the 20kB/sec range. I was using LeechFTP before
that supports multi-threaded multi-part download (using
multiple parallel connections) but development has been
discontinued and it does not support any security (SSL).
Whenever you have a high-speed internet connection
and need to download a large file (e.g. CD image) I was
able to cut the download time by over 75% using this
feature.

Would be great if you could consider this for a future
release.

Thanks,

Stephan

[Tim Kosse]

Won't be implemented. The overhead from using multiple
connections reduced overall available bandwidth.
If someone uses multiple connections, all other users have
to pay for this by slower transfer speed

[slacka]

I agree that a without limits, this feature has the ability for abuse. However, a reasonable number like 5 or 10 connections would be a good compromise.

I first used this feature in leech FTP in 1998 and since then nearly all of modern FTP clients have added support for this feature (cuteFTP, ws-ftp, leechftp) in addition to all download accelerators for web browsers like downthemall use it. This has not led to the any major problems, so I see no reason why filezilla cannot keep up with the times.

[Tim Kosse]

See my previous reply.

[slacka]

CodeSquid ,

I have read your previous reply. However, your argument for not supporting this feature “If someone uses multiple connections, all other users have to pay for this by slower transfer speed” is only valid in certain low bandwidth situations. Nearly all proprietary FTP clients support this multi-part downloads. So in these low bandwidth situations, the FTP server administrator can and should easily prevent multi-part download by not support resume or limiting maximum simultaneous connections.

The aggregate bandwidth used by a multipart transfer is identical to a single stream transfer. A user transfering a file in 2 parts, gets the file twice as fast, but also frees up bandwith for other users in ½ the time.

Using Multi-part download is no more demanding of bandwidth than using filezilla’s feature “multiple connections to transfer files”. If mult-part download is really so bad, then shouldn't this feature be removed from filezilla?

[Tim Kosse]

Strictly speaking I'd have to remove the option for multiple simultaneous transfers. (The public outcry would be gigantic though)

At least no bandwidth is wasted with that option. Compare it to multi-threaded downloads. Let's ignore the fact that you'd double the control connection overhead. Even then the largest cause of overhead remains: The FTP protocol has no range command. You can only give an offset at which to start the transfer, but cannot tell the server to only send you that many bytes. The server always prepares to send you the full file starting from the resume offset.
Now assume a file of 1MiB and you want to only get the first half. Resume offset 0. After receiving the 512KiB you've got all the data you want, yet the server is still sending. So you have to forcefully close the connection. Now at that point, the server has already sent you a lot more data you just didn't receive yet. Depending on the network configuration it can be many megabytes which are still in various buffers or on route to the destination. Furthermore, the server or operating system likely has already read-ahead a significant portion of the file, wasting RAM and causing the HDD to wear down.

[Jim]

From a network administrator's perspective, codesquid is technically correct. Implementing this feature would waste a little bandwidth. But practically every other FTP client out there already supports this feature, so I think it should be up to us admin to support this feature or not. Besides for massive files, the bandwidth wasted would be a very small percent of the total bandwidth used.

It's great that FileZilla supports multiple simultaneous transfers. The problem is that these don't help at all if you are transferring only one single large file. For that you need full multi-part transfers. The existing framework in filezilla for pipelined transfers could be used to help implement multi-part transfers. When the top file in the transfer queue is large, you simply split it into several partial transfers, and then use pipelined transfers on those parts as if they were different complete files, filling up the transfer slots as usual. You still have to handle the pre-allocation of the file, and filling in the data into the right place for each part.

Codesquid does raise a good point about the FTP protocol lacking a range command. Couldn’t FileZilla address this deficiency in the FTP protocol with an extension? Initially only FileZilla clients connecting to FileZilla servers would support it, but if it was useful and implemented well, it could be adopted as an official extension to the FTP protocol, like RFC 2228. What do you think?

[rymo]

"...the largest cause of overhead remains: The FTP protocol has no range command...you have to forcefully close the connection"

...not so with SFTP! Regardless, we're only interested in this feature on really big downloads. If you're transferring a single 1GByte file with multiple FTP connections and end up with some overlap at the end, that's pretty minuscule overhead. If you are really that worried about wearing out server HDDs (seriously?!) then only enable multiple connections above a certain filesize threshold.

Parallel downloads need not and should not an on-by-default feature, but it's a vital option for enhancing poor connections just as custom PASV setting tweaks are necessary in poor server/network setups.

We're on a wireless connection here and for various reasons we can't get more than 2Mbps throughput on a single download connection -- yet run 10 or 20 parallel connections on the same server (a server we own, by the way) using axel under linux or Cygwin and we're able to max out our 10Mbps allocation on that single download. Why shouldn't we expect to accomplish the same in our favorite FTP client, FileZilla? Don't dumb down the client for fear of dumb servers.

[Jeff Cook]

This really should be implemented. I use FileZilla as a client almost exclusively on private servers which I own and operate, and I want to use multiple connections per file. Why should I not be able to on my own server?

There are many measures server admins can take to protect themselves from abuse by excessive parallel connections. And as already stated, most other FTP clients support this feature, so FileZilla will not cause a massive influx of new unblockable abuse.

Don't deprive your users, many of whom have very legitimate uses for this, in favor of a smaller number of incompetent admins.

[Pierre]

I agree with the previous comment, I rented a dedicated server oversees and for whatever reason (I'm still awaiting an answer about it from them) they limited the speed at 120Ko/s per download, with all protocols (ftp, sftp, and http) while I still pay for an unlimited 100Mb/s service.

I can for exemple split a file in 10 parts, download the 10 parts simultaneously and get a 1 Mo/s speed.

The problem is not on filezilla's side of course, but if the feature was implemented it would be a relief. The use can be legitimate, and not only for stealing bandwidth as you can see!

[Jagsir]

Replying to codesquid:

See my previous reply.

I have a need to copy files ( a large number between 2 computers) and I want to use filezilla in multi threaded transfer mode.

When I start the transfer I get 1 processor doing 99% and just 5-6% bandwidth usage.

[smk]

This feature should seriously be considered, if you don't want to put it in the main client, have a plugin or something
This is absolutely the *only* reason preventing me from using this otherwise fantastic client

[yener azis]

Hello,
I read the replies above and what I understand is that Filezilla does not support "multi-threaded transfer". Does it or not? I have version 3.5.0. Also is "multi-threaded transfer" the same as "multi-part transfer"?
I ask this because in my job I used for LTE UL throughput test the Filezilla client and got 45 Mbps and with MS-DOS FTP (put command) got only 25 Mbps. And I wonder why the big difference. Would you know why?

[badon]

Replying to codesquid:

Won't be implemented. The overhead from using multiple
connections reduced overall available bandwidth.
If someone uses multiple connections, all other users have
to pay for this by slower transfer speed

I just tested this, and I've learned that you're wrong about it reducing overall available bandwidth, in my test case of a single large file on a single-user system. I experienced a 5X bandwidth increase using 5 connections, instead of only 1 connection.

Since this is a single-user system I tested, that means you're also wrong about other users "paying" for something as a consequence, because there are no other users. As an admin on a multi-user system, I could easily limit simultaneous connections to 5, to ensure that maximum download speeds are achieved without over-doing the number of simultaneous connections.

Correct me if I'm wrong, but I think you're also probably wrong to expand the scope of FileZilla's design to policing a hypothetical admin's users on a hypothetical system that appears to not exist in the real world. Of course, it's good to design software with sensible and friendly usage in mind, but I can't think of any system I've ever witnessed that would benefit from this expansion in FileZilla's scope. All of them that are still operating today will support multiple connections, and FileZilla only stands in the way of using that feature as the admins intended.

It's worth noting that FTP isn't so popular as it used to be, so abuse is a non-issue. That might not have been the case 9 years ago when this feature was requested and rejected.

[badon]

Note that this feature should properly be called "Segmented", not "multipart". See these URL's for explanation:

​https://en.wikipedia.org/wiki/Segmented_file_transfer
​https://whatbox.ca/wiki/Multi-threaded_and_Segmented_FTP

[Alexander Schuch]

They talk about downloading from multiple servers. I just don't get why downloading from the *same* server using 5 parallel connections should be any better. After all, you have 5 TCP connections to maintain, so at least the overhead of 4 TCP connections is wasted.

Assume 100 KiB/s bandwidth. Assume 1% of TCP overhead. So using 100 KiB/s using 1 TCP connection gives you 99 KiB/s actual data bandwidth. Using 100 KiB/s using 5 TCP connections give 95 KiB/s actual data bandwidth.

[badon]

I think you're looking at the problem backward because you're missing the fact that 1 connection does not achieve maximum bandwidth. So, it's not a question of reaching maximum speed with 1 connection, and then dividing it up to 5 connections. Instead, it's a question of NOT reaching anything even close to maximum speed with 1 connection, and then getting closer to the theoretical maximum with more connections.

In the test I did, 1 connection was not achieving maximum speed. 5 connections got closer to achieving maximum speed (6+ connections weren't better). In that case, the question is "why wasn't I able to achieve maximum speed with only 1 connection?". I don't know the answer to that question, but since it was a Filezilla FTP server, I'm probably not the most qualified person around here to answer that question. Barring a server problem, maybe there's some sort of server hardware or network quirk that caused 1 connect to be so very inferior to multiple connections.

I honestly have no idea why multiple connections are better than 1 connection, but it's such a common feature to support for both clients and servers, surely I'm not the first person to experience this phenomenon, and just because no one here has explained it does not mean the phenomenon doesn't exist. The problem has been identified. The solution has been identified. As such, halting progress on this bug until somebody explains why the (industry standard) solution works is an irrelevant red herring.

As has been said already, Filezilla is probably the ONLY major FTP client that DOESN'T support multiple segmented downloading, so instead of asking "why should Filezilla be the same?", it might make more sense to ask "why should Filezilla be different?". What we're saying here is that there is no good reason for Filezilla to be different. Every objection to supporting multiple segmented downloads has been thoroughly shot down during the last 9 years (or dismissed as a red herring). It's time to concede that Filezilla should implement this feature eventually.

[Haxus]

I use FileZilla quite a bit for general use, but at home I bought SmartFTP (and used CuteFTP previously) because of the segmented downloading. I have an FTP server overseas, and there is traffic shaping implemented along the way that often limits a single connection to less than 1MB/sec, while my home connection can do 10MB/sec or more.

Using multi-part/segmented downloads, I can saturate my connection. With FileZilla, my speeds are limited greatly. Segmented FTP downloads are implemented in other FTP programs for good reason. I understand that codesquid doesn't want to implement this for several reasons. Yes, there is some overhead and wasted bandwidth, and yes there are technical hurdles in implementing it, but I believe the performance benefits outweigh these negatives. These are also settings that can be disabled by default, and only apply to files over a target size.

I'll continue to use FileZilla in situations where I don't need segmented downloads, but SmartFTP/CuteFTP can download files over 10 times faster than FileZilla in these cases, so it will never replace them completely unless this is implemented.

[Håkon Struijk Holmen]

Some times, TCP does not reach its maximum speed due to things like packet drops unrelated to congestion, or high latency.

One possible fix is to make TCP itself able to cope with higher latency and random packet drops. But in the meantime, segmented downloads is a widely adopted workaround.

This is very real, as the reason people want segmented downloads nowadays, is working around this type of issue.

There are also many potential users who would adopt FileZilla if this was implemented.

[Pierre]

I really don't get why it's not at least recognised as a valid feature request. It's been 5 years since my last comment and I dropped FileZilla totally as an sftp client for this reason. Heavily using cross-continent transfer, it's a nightmare with Filezilla.

[badon]

Correct me if I'm wrong, but it looks to me like this IS recognized as a valid feature request by virtue of the fact that its status is "reopened", and nobody has reclosed it yet. However, after 10+ years, I think it's wise to assume it's going to continue to be ignored. It should be easy to find an alternative, since anything still around today probably had this feature a decade ago.

[tyler.haske]

Lack of segmented downloads means I cannot use or recommend FileZilla to anyone if they need to download large files. I still occasionally use it since it will at least use multiple connections for multiple files.

TCP wasn't intended for fast downloads, it was intended for accuracy. TCP doesn't handle latency well either. Its windowing algorithm needs to wait for traffic to be received, then send the acknowledgment back. While the server is waiting for the acknowledgement, it sends NOTHING. The windows are limited in size. You can look at a Wireshark capture and see that large portions of time, there just isn't any traffic on the wire as it waits for the ACK packets.

I've attached some analysis with Wireshark using tcptrace.

Please implement this. LFTP doesn't have a pretty graphical interface.

Source: TCP/IP expert.

​https://imgur.com/a/nTyiz

[Tim Kosse]

FileZilla is perfectly capable of saturating even transatlantic gigabit links using a single TCP connection.

This even works when using SFTP (assuming sufficient CPU power for the crypo is provided), which implements another layer of flow control with packet acknowledgement on top of TCP.

@tyler.haske: Since we're both TCP/IP experts, I'm sure you confirmed that the advertised TCP receive window set during the TCP handshake is large enough to accommodate the link's BDP.