Bug 180965 - [performance][ftp] FTP should allow multiple concurrent uploads and downloads
Summary: [performance][ftp] FTP should allow multiple concurrent uploads and downloads
Status: NEW
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 enhancement with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Javier Montalvo Orús CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 205261 295167 203306
  Show dependency tree
 
Reported: 2007-04-04 10:51 EDT by Javier Montalvo Orús CLA
Modified: 2011-04-04 08:09 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Javier Montalvo Orús CLA 2007-04-04 10:51:23 EDT
The FTP protocol uploads and downloads files using different channels, so uploading and downloading files concurrently should be supported.
At the moment files are uploaded and downloaded sequentially but they could be transferred concurrently for better performance.
Comment 1 Martin Oberhuber CLA 2007-04-04 10:57:01 EDT
Assigning RC1 since it's a good enhancement request but won't change any UI.
Comment 2 Javier Montalvo Orús CLA 2007-05-23 07:08:22 EDT
Taking a look at the FTP protocol, although file data is transferred in separate data sockets, it requires the result code of the data transfer to be returned through the command socket, which can't be used in a concurrent way, as it confuses the ftp server.
Having checked it in the Filezilla FTP client, even though it allows to select multiple files and folders to be sent/retrieved, the transfer is done in a sequence instead of concurrently.

Any thoughts about it ? 
Comment 3 Martin Oberhuber CLA 2007-05-23 07:39:14 EDT
Looking at FTP Clients like SmartFTP, I've got the impression that such clients typically open a configurable number of streams to the remote side in order to do downloads in parallel. Perhaps they open multiple command channels as well, I'm not sure.

On a side note, here is a comparison of Java-based FTP clients, including Apache commons net: 
http://www.javaworld.com/javaworld/jw-04-2003/jw-0404-ftp.html?page=1

Here is the follow-up article regarding Performance of those libraries:
http://www.javaworld.com/javaworld/jw-03-2006/jw-0306-ftp.html

And here is a comparison of FTP clients on Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_FTP_clients

Since it looks like the enhancement is not trivial, I'd like to defer this to the future. 

What's important to check now, though, is that when a user selects a large file for download and then tries downloading another one on the same connection, the downloads are serialized (i.e. Mutex must wait long enough). But this has been adressed already, I think.
Comment 4 Javier Montalvo Orús CLA 2007-08-10 08:56:37 EDT
This improvement should consider comment 9 of bug 199243, using openInputStream() / openOutputStream() methods for upload and download operations.