Aucbvax.2562 fa.info-terms utzoo!decvax!ucbvax!info-terms Fri Aug 7 19:57:43 1981 Re: New Concept-100/104 Software >From Craig.Everhart@CMU-10A Fri Aug 7 15:29:14 1981 I, too, would like to cast a vote for CRC processing, which implies packetizing at least one direction of transmission. Using all eight bits of the data path makes this even more important than usual. But I'll argue for a more elaborate protocol than just the "Line Noise" error message: the terminal's response to a CRC failure should be to somehow induce the host into retransmitting the garbled packet. This puts the discussion into arguments about protocols for error detection and correction, e.g. ACK-vs.-NAK, flow control, receiving data out of order, and all that; but I believe that the protocols are necessary for acceptable reliability. Particularly with eight bits of data and crummy dial-up lines. Of course, with the obvious error-correction scheme, the terminal will have to receive at least one entire checksummed packet before acting on anything in it, which means that intensively interactive sessions (say, ordinary character insertion into a screen editor) will have to content itself with mostly small packets, potentially chewing up line bandwidth in the encapsulation. But that shouldn't really be a problem; one can package all of an interaction-with-human into a single packet without having the bandwidth loss get in the way. Particularly if, when the transmission gets behind, the backed-up characters awaiting transmission get coalesced into bigger packets. Craig Everhart ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.