Little known features of FTP 7.0 and FTP 7.5 (Part 1).
FTP 7 includes few features that are not commonly known or used. One of them is a support for block mode transfers.
Block mode transfers
One of the deficiencies of FTP protocol is the need to maintain secondary TCP connection (data channel). Most FTP clients will create one for each directory listing, each file uploaded, and each file downloaded.
The most commonly used transfer mode is one called “Stream mode” (MODE S is the FTP protocol language). It requires the data channel to be closed to communicate to the receiving party the end of data transfer. Majority of FTP clients (almost all of them) only support this mode.
RFC 959 defines an alternative that allows the data channel to be reused across multiple transfers. It is called “Block mode” (MODE B). Each block of data sent over data channel includes 3 byte header that contains information about the size of the block and few flags. This header allows sender to communicate the end of the data without closing the data connection.
FTP7 implements full support for such mode. The only client stack I could find supporting such mode as of today is Rebex FTP. If there are others I would certainly like to know about them.
You may ask why the “MODE B” matters. Here are my 3 reasons.
1) Transferring large number of small files over FTP may hit limitations of TCP protocol. I will not elaborate on them much. It is a really confusing topic. Here is a very trivialized description of the problem.
TCP is rock solid when a single client makes a few connections to a server. But if the number of connections between single client and server reaches thousands in few minutes, there is a chance that same (Client IP, Client Port, Server IP, Server Port) happens to be chosen for the connection within a short period of time. It may cause unexpected connection problems.
2) Data channel negotiation is quite complex. Confused FTP client may try to connect to an assigned data channel port with delay, causing another unsuspecting FTP client that happens to be assigned the same data channel port, causing both clients to fail the data channel negotiation.
3) Performance is the last of my reasons. In the stream mode there is a cost of 4 extra network round trips to happen (2 roundtrips to establish TCP connection, 1 roundtrip for the FTP command to establish the data channel – PASV, PORT, EPSV or EPRT, and 1 roundtrip for closing the TCP connection). If network latency is significant, those extra roundtrips will affect the overall transfer performance, especially when many small files are transferred.
---------------
“MODE B” makes it possible for client to connect the data channel only once and keep using it for the duration of the FTP session. Reusing data channels addresses the above issues. It improves the reliability and potentially the speed of your FTP data transfers.
If you a developer of an FTP client stack, you may want to consider supporting “MODE B” for servers that advertise such mode.