[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Download recovery for lynx?

From: David Woolley
Subject: Re: LYNX-DEV Download recovery for lynx?
Date: Tue, 12 Aug 1997 22:43:36 +0100 (BST)

> HUH?  Until this discussion, I was 99% positive that resuming an ftp
> transfer was just an official extention to FTP.  Now I am having a hard
> time tracking down a document to substantiate my claim. 

Restart (and the protocol command is REST, not REGET, which is a user
level command, and not in the standard) is part of the FTP standard, but
it requires check point markers to be sent in the data stream (and I think
corresponding messages on the control stream).  All the FTP servers I've
ever come across don't support the structured data streams needed to 
support checkpoints.  One side informs the other of an opaque value which
can be used to specify the restart point (the obvious intention is that
it should be the starting offset in the file, which in general is not
the position in the FTP data stream).

However, there is a strong trend, for binary transfers, to act as though
there were a checkpoint after every byte, and as though the opaque restart
point was the byte offset.  This works because Unix (and MS-DOS) store
files as simple byte streams, with no record control blocks etc.

> Anyhow, REGET is an extended FTP command (legal or not) that needs to be
> covered by the server and client.  The client sends a reget command with

REST command

> the bytecount of where the transmition got stopped and the server resumes

with the code identifying the checkpoint.

REGET, as commonly implemented, is a combination of fetching the current
length of the file, sending REST with that value, sending RETR for the
file, and then appending the returned stream to the local file.

REST in the standard actually works in both put and get directions.
I seem to remember that clients which use the implied checkpoint approach
treat a user level REST command as a request to position in the file at
both ends, not just the remote end.

The FTP standard hasn't been updated for a very long time.  It's a
bit like NNTP, I'm not sure if any of the new features have yet been
integrated into an RFC.
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]