Re: [ftpext] End byte of transfer in FTP

[Tatsuhiro Tsujikawa <[e-mail]>]

Hi,

Thank you for replying!

2010/11/29 John C Klensin <[e-mail]>:
>
>
> --On Monday, November 29, 2010 01:21 +0900 Tatsuhiro Tsujikawa
> <[e-mail]> wrote:
>
>> Hi,
>>
>> In FTP, user can set start byte of transfer by REST command.
>
> This is a misuse of the intent of the command and some
> historical FTP implementations won't permit it.  In particular,
> REST is defined only for Block and Compressed modes (neither of
> which is widely used these days) and starts only from a
> server-specified checkpoint marker.   While I can believe that
> some implementations might construe REST followed by an integer
> in stream mode as a byte offset to be used in a subsequent STOR
> or RETR command, that usage is certainly not guaranteed by
> anything in RFC 959.
>
> Note that design is quite intentional and necessary to reflect a
> wide variety of different file system organizations, including
> files that are not organized sequentially on the remote or local
> host.
>
> As the most trivial example, FTP doesn't even guarantee that the
> bits of a sequential file will be transferred in the order in
> which they appear in their original form.
>

As Richard suggests, REST was extended to STREAM mode in RFC3695.

>> But it seems it lacks the feature to set end byte of transfer,
>> like HTTP's Range request.
>> Does it really lack this feature? Are there any ftp
>> server/client support this?
>
> It seems to me that you are looking for a remote file management
> protocol that supports a much more specific file abstraction
> than is the case with FTP, which is purely and simply a file
> transfer protocol for entire files, not fragments of them.  HTTP
> does assume a particular type of file organization model, which
> is one reason byte-oriented fragment identifiers work.  If that
> model serves your needs, why not just use HTTP?   If you need
> the more general organizational model of FTP, you will need to
> either transfer the entire file and then extract whatever you
> need (using whatever local access method is appropriate to that
> file) or find/ use/ design a file management protocol, rather
> than a file transfer one.
>
>> A example of utilization this feature is Metalink download.
>> In Metalink, it contains several URIs for one file. So we can
>> download it from several sources. From each server, client
>> downloads non-overlapping segment. For example, when
>> downloading 1 file using 2 FTP servers. We can use REST
>> command for second half of the download and it downloads given
>>  point to the end of file. This is fine. The control
>> connection can be reused. For the first half of the download,
>> since we cannot set end byte, we have to close connection
>> entirely after first half of file is downloaded. The control
>> connection cannot be reused this time.
>> We can use ABOR, but it has drawback as I mentioned earlier.
>
> And, again, why not use HTTP?
>

If we can choose protocol, then, yes, we choose HTTP definitely.
But there are existing FTP servers which we cannot make any changes and
we want to include them in Metalink. Especially if the file is only
served in particular
FTP site.

Tatsuhiro Tsujikawa