Applications /

Yet more FTPing

By Mark Gibbs
Network World, 08/06/01

Week 3 of FTPing and, boy, is this getting exciting! We've opened connections to FTP servers, given commands to set up data transfers, sent other commands to find out what files the servers have and issued commands to navigate around the server's directory structure. We can hardly contain ourselves!

Anyway, now we should look at transferring files. To this end, we need to set up the transfer mode.

FTP servers can - at least according to the standards - transfer data in three ways: stream, block transfer and compressed transfer.

Stream mode involves the server sending or receiving a sequence of bytes without any kind of verification that the data is intact or even received.

Worse still, the recipient assumes the transfer is complete when the stream ends, which means that a lost connection can't be distinguished from completed transmission and even if the file is really complete, we can't be certain without additional validation that the file is uncorrupted. But the advantage is that stream mode is fast.

When we want to transfer a file, we open a socket on the sending machine and another on the receiving machine and shove data down it until we run out of bytes. Then we close the channel. Unlike the other transfer modes, we need to open a new connection for each file we send.

The alternatives to stream mode are uncompressed or compressed block transfers. And, as you might guess, block transfers have more overhead than stream transfers, and compressed transfers are the most laborious of all.

Unlike the stream transfer mode, the other modes can send multiple files over a single connection.

The overhead is the work required to check the packets or blocks of data as they are sent and as they arrive. Plus, there's the overhead in terms of bytes of data required to control and validate the blocks. Of course the compressed version regains a few bytes, but the cost is extra processing for decoding the compressed data.

Which mode should you use? The first issue to consider is whether the FTP server supports anything other than stream mode. It turns out that many vendors only implement stream mode, so check your server first.

How can you check what the server supports? You could pick up the manual (yeah, we agree, who needs manuals?), or you could ask a knowledgeable user (no, no, stop yourself) or find the system administrator, but it would be easier to simply ask the server.

All you need to do is telnet to an FTP server (don't forget to connect to port 21) and enter the command "mode" with an argument of S for stream, B for block or C for compressed. Thus, if it responds with a 200 the mode is supported. If it responds with a 502 the mode is not supported. You will see responses like "200 MODE S OK" or "502 Unimplemented MODE type."

If other modes are supported, choose stream mode for raw speed (but be ready to integrity check files), block mode for general-purpose use and compressed mode for ASCII files (alphanumeric content compresses wonderfully).

Darn, still haven't managed to send or receive any data yet . . . oh, well, there's always next week.

Transfer your thoughts to gearhead@gibbs.com.