Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!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 Message-ID: <6991@drilex.UUCP> Date: 20 Dec 89 14:56:57 GMT References: <8912181942.AA10029@arcturus.mitre.org> Reply-To: dricejb@drilex.UUCP (Craig Jackson drilex1) Organization: DRI/McGraw-Hill, Lexington, MA Lines: 27 In article nelson@clutx.clarkson.edu writes: >In article <8912181942.AA10029@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes: > > There is a different FTP restart scheme by Rick Adams which I have > heard will be in 4.4(?). ... it does not try to handle the more > difficult cases of operation between divergent systems. > >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". Just as "All the world isn't a VAX", "All the world isn't Unix". I would like to suggest that the world is better for that. (Did I say enough to make inews happy?) -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}