Actually, the wording of my answer to the UploadBufferLength question was not entirely correct.

The UploadBufferLength property simply controls how much data Rebex FTP passes to the TCP stack in a single request. Although passing 64KB chunks instead of 4KB chunks can make a big difference, the application doesn't in fact have much control over the underlying transport layers.

The TCP protocol runs over the IP protocol. Most Ethernet LANs use MTU (Maximum Transfer Unit) of 1500 bytes. The size of an IP packet header is 20 bytes and the size of a TCPv4 packet header is 20 bytes as well. This means that 1460 is the maximum segment size that can be transferred in a single TCP packet over Ethernet II networks. (Protocols like PPPoE can reduce this further.)

When receiving data from the FTP server, we simply supply a 64KB buffer to TCP and ask it to fill it with all the data it has at the moment. If you are observing 1460-byte blocks received by Rebex FTP, it means that we are receiving and processing data as fast as we can. However, some of the FileZilla-like tricks (like larger TCP window size) might make the TCP connection a bit faster (by reducing the need to send ACK packets too often for example). We will include the UseLargeBuffers option in the next release of Rebex FTP as well, it looks like people are interested in this :-)

Using GetDownloadStream instead of GetFile is unlikely to be much faster, but if you still decide to give it a try and your results differ, please let us know!