Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!rick
From: rick@uunet.UU.NET (Rick Adams)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: partial transfer recovery in RFC and OSI protocols
Summary: think it all the way out
Message-ID: <74106@uunet.UU.NET>
Date: 20 Dec 89 23:33:29 GMT
References: <8912181942.AA10029@arcturus.mitre.org> <6991@drilex.UUCP>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 50

> >That is not the case.  His FTP restart scheme relies on the fact that
> >your file is eventually expressed as a stream of octets over the TCP
> >connection.  His RESTart command simply says to suppress the first N
> >octets.  It is brilliantly simple.
> 
> I think what barns was saying is while that it may be "simple" just to read
> through 100 Megabytes of a file, using a possibly CPU-intensive transformation
> to turn in into a Unix-compatible file, just to transmit the last Megabyte,
> it can't be considered friendly to non-Unix systems.  Especially systems
> that otherwise have no problem saying "move to record 200000 of that 201000
> record text file, and transmit the rest".


We all agree it's a win if you can seek to an arbitrary record, right?

Now, lets take your non-vax/non-unix system.

You start to transfer a file, and the transmition fails half way
through.  Without "my" restart method, your alternative is to read the
entire file again and transmit the entire file again. With my restart
method, you still read the file again but only transmit the new part.

The cpu time to read the file is identical in eaither case. Since it
doesnt have to spend cpu time sending the first half of the file again,
it MUST use less total time. How is that not a win? On systems that
don't have to do the transformation (i.e. the overwhelming majority)
its a HUGE win. On systems that do have to do the transformation, is a
minor win. In no case is it worse that retransmitting the entire file
(which is the alternative)

Also, note that we're talking about the official "ascii" and "image"
types. There's nothing Unix specific about this. It is specific to the
stream and image types (but then the official restart method is
specific to record mode, which is the main reason it sucks).

There are two approaches. Mine is to presume that the majority of
transfers will be done in ascii or image mode and that the majority
of transfers will succeed. Therefore, you want to make the normal
case "expensive" to restart in exchange for no overhead on normal
connections.

The other "official" approach, seems to presume that block mode is
normal (I dont even know if there are ANY implementations that support
block mode) and that failures are normal. So, you clutter up the
data stream with lots of markers, etc and make it cheap to
restart. However, you make it expensive to successfully transfer a file.

I know which approach makes more sense to me...

---rick