Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip Subject: Re: partial transfer recovery in RFC and OSI protocols Message-ID: Date: 21 Dec 89 04:19:24 GMT References: <8912181942.AA10029@arcturus.mitre.org> <6991@drilex.UUCP> <74106@uunet.UU.NET> Sender: news@sun.soe.clarkson.edu Reply-To: nelson@clutx.clarkson.edu Organization: Clarkson University, Potsdam NY Lines: 56 In-reply-to: rick@uunet.UU.NET's message of 20 Dec 89 23:33:29 GMT In article <74106@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: 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). As I disagreed with Barns, now I must disagree with Adams. Yes, the official restart method *does* require record mode. But there is no reason why a Unix file cannot be considered to have N records of 1024 (say) bytes plus a trailing record of M bytes. 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. You don't seem to recall that I implemented block mode and RESTart in KA9Q's TCP/IP package. I also put it into a local copy of the BSD Tahoe FTP server. That aside, I do agree that there is a tradeoff between sending restart markers in block mode and sending a file in stream mode. If the block size is made large enough, then the tradeoff is minimized. Late breaking news (just got mail from Bill Barns): He points out that explicit markers (as per the RFC) may be more reliable than implicit markers (as per Adams) when your transfer failed. What I did to implement RESTart was to implement block mode (as required). Then, when a file was retrieved in block mode, I would store the markers in a specially-named file. So if you were fetching foo.bar, I would store the markers in foo.$$$. Whenever I received a marker, I would fflush() the data file and the marker file. In addition to keeping the markers, I would also keep the position of the data file at the time of receipt. Then, if the transfer succeeded, I would delete the marker file. If they restarted the transfer, I would check for an existing marker file, and automagically issue a FTP RESTart with the latest marker in the file. The wisdom of doing this automagically is not clear. It *did*, however, work. I know which approach makes more sense to me... On one hand your technique, while sound, is interoperable only with itself. On the other hand, there are very few implementations of the "interoperable" version. If it hasn't been widely implemented, it doesn't really matter whether the protocol is well designed or not. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667 Live up to the light thou hast, and more will be granted thee. A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989. I think killing is value-neutral in and of itself. -- Gary Strand, 8 Nov 1989. Liberals run this country, by and large. -- Clayton Cramer, 20 Nov 1989. Shut up and mind your Canadian business, you meddlesome foreigner. -- TK, 23 N.