


Reference: threaded multipart FTP download via REST There is one ActiveState Python script I found in the process,īut, have no idea how to get it usable for your purpose. The so-bufsize control on NcFTP might help with point-2 above. I have always found NcFTP to be good for most purposes, and was expecting this support to be available there. Maybe, if others answering here agree to these ideas, they might be able to suggest a suitable reference. I have not been able to locate a command-line (script-able) client that can be told to perform multi-part downloads.

this will help if there is significant round-trip latency to the server.It might be tweaking the TCP Window/buffer size to get a deeper TCP pipe.this would help if the server is limiting rate per connection.It might be doing a multi-part download to have multiple connections download a file.I can think of only two things that could be done to overtake basic FTP performance for large file transfer. You are comparing it with FileZilla performance. Why do you get bad performance from that FTP? The basic FTP.exe is quite stable and the first question to ask is,
