Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!drilex!dricejb From: dricejb@drilex.UUCP (Craig Jackson drilex1) Newsgroups: comp.protocols.tcp-ip Subject: Re: partial transfer recovery in RFC and OSI protocols Keywords: FTP restart Message-ID: <7106@drilex.UUCP> Date: 28 Dec 89 20:50:09 GMT References: <8912210357.AA06303@gateway.mitre.org> Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1) Organization: DRI/McGraw-Hill, Lexington, MA Lines: 30 Seeing the discussion of receiver-controlled vs sender-controlled restart in the referenced article, I realized that there could be another problem with Rick Adams' restart method (where the receiver tells the sender, "supress the first n bytes of your transmission"). The problem would occur if the receiver was unable (or unwilling) to store a byte-image of the transmitted file, or something transformable back-and-forth to such and image. If a irreversable transformation is necessary to store the received file in the receiver's file system, then the receiver may not be able to compute the proper byte count. For an example, assume a receiver that implemented a record-oriented file system, with fixed-length records. The receiver might have to blank-pad each record received via FTP. (I'm ignoring the issue of long lines.) Such a blank-padding might be innocuous to all uses on the receiver machine, except for the retransmission. I suppose that the way this would be dealt with is for the receiver to store an auxiliary file, with indications of "when I began record m, n bytes had been sent". This file would be periodically updated (every few hundred records) and pushed to the disk. Some care would need to be taken to ensure that the received file and the marker file would be consistent after a crash. I don't mean to say that Rick's method is not useful. I'm just trying to explore the issues. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}