campbell@maynard.UUCP (Larry Campbell) (08/12/86)
In article <2943@brl-smoke.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >D.C. Hayes (the modem people) are proposing a new protocol... >Fast is a session-level file transfer protocol designed to run over an >error-free link such as X.25, X.PC or MNP. Since the link is assumed to be >error-free and packetizing is done by the network layer of the underlying >protocol, no error detection/correction mechanisms are necessary. What an irresponsible statement! Sure, the link from modem to modem may be relatively error-free, but what about the links from computer to modem on each end? Who checks them? Doing file transfers without end-to-end error checking is simply a subtle way to play Russian roulette. Responsible software engineers will avoid this protocol like the plague. -- Larry Campbell The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
davids@iscuva.UUCP (David Schmidt) (08/14/86)
In article <330@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >In article <2943@brl-smoke.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >>D.C. Hayes (the modem people) are proposing a new protocol... > >>Fast is a session-level file transfer protocol designed to run over an >>error-free link such as X.25, X.PC or MNP. Since the link is assumed to be >>error-free and packetizing is done by the network layer of the underlying >>protocol, no error detection/correction mechanisms are necessary. > >What an irresponsible statement! Sure, the link from modem to modem >may be relatively error-free, but what about the links from computer to >modem on each end? Who checks them? Doing file transfers without >end-to-end error checking is simply a subtle way to play Russian >roulette. Responsible software engineers will avoid this protocol >like the plague. If you read the documentation carefully you will see that the FAST protocal does include the capability of using a CCITT CRC-16 check on the file sent. If this is uses (I wouldn't use FAST without it!) then you do have an error-free protocal. The only difference between FAST and KERMIT or XMODEM is that the "packet size" is indefinite (the full size of the file) instead of a fixed size. Also it is not clear to me if the file is automatically re-sent or if the recieved file is deleted (with an error message of course). It remains to be seen how often errors will occur. If I only have to re-send one file out of 100 for instance, I can save quite a bit of time overall if each file transfers twice as fast (Telenet and Tymnet transfers are SLOW!). -- +----------------+ ! II CCCCCC ! David Schmidt ! II SSSSCC ! ISC Systems Corp. ! II CC ! Spokane, WA ! IISSSS CC ! UUCP: ihnp4!tektronix!reed!iscuva!davids ! II CCCCCC ! (509)927-5479 +----------------+
tanner@ki4pv.UUCP (Tanner Andrews) (08/15/86)
The idea of doing a \fBsingle\fR CRC check on the whole file reminds me of the link they ran between two computers at school. Ran print-outs through this link. One error test, at end of job, just as proposed. Worked great, except when you transferred at 200-page printer file, and it blew one character somewhere in there. -- <std dsclm, copies upon request> Tanner Andrews
caf@omen.UUCP (Chuck Forsberg WA7KGX) (08/16/86)
In article <247@iscuva.UUCP> davids@iscuva.UUCP (David Schmidt) writes:
:
:If you read the documentation carefully you will see that the FAST
:protocal does include the capability of using a CCITT CRC-16 check
:on the file sent. If this is uses (I wouldn't use FAST without it!)
:then you do have an error-free protocal.
:
The "FAST" protocol does not have any error recovery procedures.
Although "FAST" is only very slightly more efficient than ZMODEM,
"FAST" lacks ZMODEM's error recovery, file management features, and
user interface improvements. "FAST" also lacks ZMODEM's extensibility
for process to process communications and control.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131
Author of Professional-YAM communications Tools for PCDOS and Unix
Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourlycampbell@maynard.UUCP (Larry Campbell) (08/16/86)
In article <247@iscuva.UUCP> davids@iscuva.UUCP (David Schmidt) writes: >If you read the documentation carefully you will see that the FAST >protocal does include the capability of using a CCITT CRC-16 check >on the file sent. If this is uses (I wouldn't use FAST without it!) >then you do have an error-free protocal. But the use of a CRC is optional. I think they should make it mandatory. This is especially important in the PC world, with so many people trustingly toting binaries around without sources. In source code, errors will almost certainly cause the code not to compile or link, and will thus be detected. In binary code, though, the errors will just cause the code to explode in mysterious ways that are nearly impossible to detect. Note also that FAST just has one CRC for the entire file. The longer the packet, the greater the probability that CRC-16 will fail to detect an error. For almost any reasonably large file, CRC-16 is nearly worthless. In any event, why invent yet another protocol? What's wrong with KERMIT with sliding windows? KERMIT is already implemented everywhere, and the sliding windows give reasonable performance. It just irks me no end to see people simultaneously reinventing the wheel and giving up reliability for performance. It doesn't matter how fast you can do it wrong! -- Larry Campbell The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
desj@brahms.BERKELEY.EDU (David desJardins) (08/17/86)
In article <333@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >Note also that FAST just has one CRC for the entire file. The longer >the packet, the greater the probability that CRC-16 will fail to >detect an error. True. >For almost any reasonably large file, CRC-16 is nearly worthless. False. If one or more errors have occurred, a 16-bit CRC will detect them with probability at least 99.9985%, no matter how large the file. If the presumption is that the total error probability is low (as it certainly should be on an error-free channel) this is more than adequate. >In any event, why invent yet another protocol? What's wrong with KERMIT >with sliding windows? KERMIT is already implemented everywhere, and the >sliding windows give reasonable performance. It just irks me no end to >see people simultaneously reinventing the wheel and giving up reliability >for performance. It doesn't matter how fast you can do it wrong! This is just stupid. If performance means nothing and reliability everything you should transmit every message 100 times, just to make sure. Obviously you have to make some sort of performance-reliability tradeoff. Large amounts of redundant error-checking on an error-free channel are simply wasteful. -- David desJardins
bishop@ecsvax.UUCP (Alan Bishop) (08/17/86)
A protocol such as FAST just adds to what the user must know
about the hardware configuration on a machine. A well-designed
protocol should be able to vary packet sizes according to the
type of connection (modem/hardwire, normal/leased line, etc.) so that the
user need not worry about which protocol is needed on a particular
line.
---
Alan Bishop
...!decvax!mcnc!ecsvax!bishop
bishop@ecsvax.{UUCP,BITNET}clewis@spectrix.UUCP (Chris Lewis) (08/19/86)
I have some experience with so-called "error-free" links.
4.3 BSD UUCP contains protocol "f", which is intended for X.25 links
where the underlying network generally guarantees *NO* errors.
Protocol "f" simply blasts the file along the line, only transmitting
a checksum at the end of a file, and if incorrect, retransmits the file.
Sigh....
The one thing not error-free was the network to computer connection
(eg: modem or PAD to computer) - many of the links I used protocol
"f" on had computers on the other end that would drop characters
when talking to their modems even with X-ON/X-OFF flow control (missed
interrupts). We routinely were transmitting files 500K or larger.
Having to retransmit the durn things multiple times is extremely
painful and expensive - especially when most of the time the effective
thruput was around 1200 baud (inspite of 9600 baud or higher links all
the way thru). There were times when we had to abandon attempts to
transmit a large file because, after 3500 miles of error-free transmission,
the link between the modem and the computer (connected by 2 feet of
wire) simply refused to carry our megabyte of data error-free because the
computer missed the occasional interrupt at high baud rates.
PLEASE PLEASE PLEASE: even on *perfect* channels, packetize and retransmit
packets on errors. If the network is reliable, make the packets *big*.
Say 16K or 64K, or better still, make it a parameter. There were
times when 64K packets would have reduced our line charges by an order
of magnitude (no exaggeration - after 40 failures on the same file...).
Think about the poor suckers trying to transmit files so large that the
probability of a cosmic ray particle nailing the data register in the
UART approaches unity. (probably an exaggeration, but you get the idea)
Never assume that anything is ever perfectly error-free - in the real world,
nothing is (and sometimes the "perfect" ones aren't even close) - don't
penalize the people working with imperfect equipment (or software in my case).
--
Chris Lewis
UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis
Phone: (416)-474-1955geoff@desint.UUCP (Geoff Kuenning) (08/24/86)
In article <333@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: > Note also that FAST just has one CRC for the entire file. The longer > the packet, the greater the probability that CRC-16 will fail to > detect an error. For almost any reasonably large file, CRC-16 is > nearly worthless. This is quite simply untrue. CRC-16 will detect *all* error bursts that are less than 16 (17?) bits long, and a remarkably large fraction (e.g., 99.97% or some such) of all longer bursts. The length of the packet is not a factor. (This is similar to statistical sampling, where a sample of about 1200 is sufficient no matter how large the sampled population.) Note that widely-separated errors can be thought of as a very long error burst with most of the bits unchanged. Thus, you can count on CRC-16 picking up 99.97% (or whatever the right number is) of all error patterns, regardless of packet size. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff