Multiple connections per file transfer does not work.

The previous version (5.9.6) had a option to "Transfer each file individually on background by default." This made WinSCP create a completely separate connection for each file being transferred. The new version (5.11.1) has replaced this with a "Use multiple connections for single transfer" option. The new one sounds like it should be an improvement, since it would allow you to use several connections for each file being transferred. Unfortunately, it neither replicates the previous behavior or performs the stated behavior; it simply creates a single connection for the entire file transfer.

I have a server that has a 100 Mbps connection, but (perhaps due to latency) I can only get 450 kBps connections to it. I can, however, create multiple connections until I've saturated the link between myself and the server. In the old version of WinSCP, I could transfer up to 9 files concurrently, each of which would max out around 450 kBps for a total of about 4 MBps. With the new version, it tosses all the files into one transfer and the total speed is just 450 kBps. If I select one file to transfer at a time, then I can get it to display the previous behavior, where it produces multiple concurrent file transfers. I've experienced this with both the SCP and SFTP protocols on Win10.

Also, I'd really like to see a higher max connection limit.

How long does the transfer that you refer to take?

Please attach a full session log file showing the problem (using the latest version of WinSCP).

I did this test using the latest version (5.11.2) and created 8 files each with 128 MB of random data for a total of 1 GB of stuff to transfer in one batch. I just selected all 8 files, then used drag & drop from the server pane to the local pane to start the transfer. According to the log, it took 42.5 minutes to complete the transfer for an average of 410 KBps.

When preserving timestamps of directories is enabled, multiple connections are never used.
I've documented this (in footnote):
https://winscp.net/eng/docs/ui_pref_background#background_transfers

Ok, that seems reasonable; and yet was completely unexpected. Could I suggest adding some sort of notification to WinSCP when the user tries to enable an incompatible set of options like that? Maybe a warning icon next to the transfer that you can hover over to get an explanation.

I will consider that.

Hi Martin,

First of all thank you for all the work you've been putting on WinSCP.

I thought that the multiple connections functionality was broken until I found this thread. I think that incompatible options should indeed present a warning because the user has no means to know what disabled their multiple connections, especially if they don't see it right away.

However from my point of view there is a problem with the current approach which requires me to enable size calculation to have multiple connections. I use multiple connections to download things fast, but size calculation is always extremely slow, which defeats the purpose of having multiple connections in the first place. When having to download structures with tenths of thousands of files it can take hours to calculate.

I don't see the relation with the "preserve timestamp" option either. I want to have it enabled so that when I download an entire site I can easily upload only changed files. Re-uploading everything in the initial upload is time consuming and ineffective.

So while concurrent connections is a feature I welcomed with a lot of enthusiasm in WinSCP (since I really missed it from FileZilla), those two option restrictions really ruin it for me and finally the feature is mostly unusable in my scenario.

I hope that this makes sense and that it might be considered for the enhancement of this functionality, since for me it's one of the most important things in any FTP client.

Thank you!

acicovic wrote:

I use multiple connections to download things fast, but size calculation is always extremely slow, which defeats the purpose of having multiple connections in the first place. When having to download structures with tenths of thousands of files it can take hours to calculate.

It does not slow the transfer at all. While the operation presents as "size calculation", the ultimate goal is to collect a list of files to transfer, so they can be split among parallel connections. The only difference is that it's collecting all files upfront. While normally, it would list one directory, transfer its files, list another directory, transfer its files, etc. Overall time is the same in both cases. Indeed for a normal non-parallel transfer, the size calculation slows the transfer, as there it really only calculates size and for actual transfer, directories are listed again. But that's not the case for a parallel transfer.
I've documented this:
https://winscp.net/eng/docs/ui_transfer_custom#calculate
Maybe I can change it, that for parallel background transfers, the "size calculation" is forced (even if disabled globally).

I don't see the relation with the "preserve timestamp" option either. I want to have it enabled so that when I download an entire site I can easily upload only changed files. Re-uploading everything in the initial upload is time consuming and ineffective.

It's only preserving timestamps of directories (which is off by default) that disables parallel transfers. Not of files.

Hi Martin,

Thank you for taking the time to reply, I really appreciate it.

Just a suggestion/idea/question : if "size calculation" was done using multiple connections itself, wouldn't that make the process much faster? I don't know if it's technically possible with your current implementation, but I thought of throwing this to the table.

Thank you very much!

Thanks for your suggestion.
Will see if more people ask for this.

martin wrote:

Maybe I can change it, that for parallel background transfers, the "size calculation" is forced (even if disabled globally).

This issue has been added to the tracker:
https://winscp.net/tracker/1691