Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: notesfiles Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!hp-pcd!hpfcmp!rjn From: rjn@hpfcmp.UUCP (rjn) Newsgroups: net.unix Subject: Re: Orphaned Response Message-ID: <20800001@hpfcmp.UUCP> Date: Sat, 15-Jun-85 19:40:00 EDT Article-I.D.: hpfcmp.20800001 Posted: Sat Jun 15 19:40:00 1985 Date-Received: Sun, 16-Jun-85 00:26:30 EDT References: <5620@utzoo.UUCP> Lines: 26 Nf-ID: #R:utzoo:-562000:hpfcmp:20800001:37777777600:1560 Nf-From: hpfcmp!rjn Jun 7 15:40:00 1985 re: *positive* flow control ("I'm OK for another 347 characters now"). > ETX/ACK comes close to being standard. The sender embeds ETX controls in the > output stream; the receiver returns ACK controls each time it's freed up 80 > bytes in its input buffer (at least; this is the part that's not standard). HP terminals use a similar protocol: ENQ/ACK (although most HP systems seem to be moving to XON/XOFF, also supported by current HP terminals). The difference between ETX/ACK and ENQ/ACK is that the ENQ is sent BEFORE the 80 characters of data, instead of afterwards. Of course, once the stream has started, there's really no difference. An interesting question about these protocols is: "How long do you wait for the ACK (or XON), and what do you do if you don't get it?" HP systems usually wait 5 or 10 seconds for the ACK, and then transmit anyway(!). (This makes it very easy to recognize when the terminal has not been configured for ENQ/ACK - you get a burst of characters every 5 sec.) Our XON/OFF hosts seem to wait forever for the XON, so our XON/XOFF peripherals, such as the LaserJet, are adopting a strategy of sending an XON every 5 seconds or so when no data has been received for 5 sec. This gets the line going again if an XON has been lost for some reason. Regards, Hewlett-Packard Bob Niland 3404 East Harmony Road hplabs!hpfcla!rjn Fort Collins CO 80525