Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.dcom Subject: Re: In defense of XOFF/XON flow control Message-ID: <1377@rlgvax.UUCP> Date: Tue, 8-Nov-83 23:17:40 EST Article-I.D.: rlgvax.1377 Posted: Tue Nov 8 23:17:40 1983 Date-Received: Thu, 10-Nov-83 11:35:45 EST References: <257@decvax.UUCP> <1388@utcsstat.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 114 ***Please don't damage this article, oh sites who haven't fixed the "news" bug yet!*** Arrrgh, Martin, We *know* that XON/XOFF works in all sorts of environments! But it is a *bad thing*. XON/XOFF flow control may be a bad thing, but it's better than no flow control. I find smooth scroll on my VT100 much superior to jump scroll (it's a matter of taste, so any claims that XXX is better than smooth scrolling are false), and smooth scroll requires flow control. Not all multiplexers support RTS/CTS handshaking (putting the question of whether it's a valid use of RTS/CTS aside) - the DZ11 is one. The only way to avoid something like XON/XOFF is to: 1) not use any terminals or terminal features that require flow control - as mentioned, for me (and, I'm sure, a lot of other people) this is unacceptable, or 2) a) not buy any multiplexers that have no facility for such "out-of-band" signalling b) not buy any terminals that have no facility for such "out-of-band" signalling c) not buy any operating systems that have no such facility etc. which is probably not always possible. In the Best of All Possible Worlds we wouldn't need XON/XOFF. However, this is an imperfect world and sometimes an imperfect solution is, overall, better than the alternatives. It *is* a de facto standard and has some merit due to that, which can outweigh some of its demerits. The fact that is works in a lot of environments is another point in its favor; if you are in an environment where it works and something else doesn't it's rather clear that bad though it may be in that environment, it's a lot better than the alternatives. I print a binary file by mistake and this terminal which thinks it is in VT100 emulation mode gets too many ^s/^qs for its little microprocessor to handle. It goes into infinite reset-screeching- there-is-something-terribly-broken mode. Yes, the terminal in question is terribly broken. This is not an argument against ^S/^Q, it's an argument that the terminal in question needs fixing. My VT100 occasionally glitches in that way too (although I'm not sure whether it's the VT100's fault or UNIX's fault) but I still love it. This leads to terminal wars. Who can send all the other users packing first by writing obnoxious files all over their terminal. Stage two -- who can find the shortest file that will do the same. Stage three (either only played by super-users, or on people with writable .profiles) -- who can insert 'cat obnoxious' onto the end of everyone's .profile... There are a lot of terminal features and misfeatures that fall under this heading, so again it's not an argument against ^S/^Q. Anything that gives a user power can be misused. On a totally dumb terminal you can send users packing by just scribbling over their screen. This is best solved by restricting terminal permissions. As for twiddling somebody's .profile, the example you give says 1) the super-user in question, if they do this sort of thing maliciously (as opposed to just teasing friends), is a twit and 2) the person whose .profile is writable is asking for it (if they don't know what a writable .profile can do, the person who gave them their account has been derelict in their duty). Then there are hardware manufacturers who think that 3 chars is plenty of time for one to stop when it sends a ^s. Stick one of those off a 9600 baud line, and watch yourself lose *whole* *paragraphs* of text. Exactly what you want on a hard copy printer. Again, an argument that the hardware manufacturer goofed, not that ^S/^Q is wrong. Now you get other terminals that treat ^s unconditionally as magic. I write a communications package that runs in raw mode. To watch and see if the handshaking is going okay, I have what is going on echoed onto my terminal. Whoops, there is a ^s in the input. The terminal, which handles other control characters just fine, goes into amnesia mode and has to be powered off before it will stop beeping at me. And i have to find a new way to debug it which involves the LINEPRINTER. Yuck. Why not write a line monitor program which decodes the control characters? It'll probably yield more information than just dumping them to the screen. ^s and ^q are just characters. Making them magic was an awful kludge. The way hardware manufacturers implemented it was worse than a kludge, in many cases it was gross incompetence. Let's put this one to rest, now, huh? Surely we can come up with a better way to do handshaking! Can we come up with one that won't require us all to throw away our terminals, our computers, and our operating systems? I don't know of many people who can afford to do that. The ones that can, fine, their problem is solved. But since ^S/^Q hasn't caused any problems here we can hardly justify buying new equipment just because it does flow control better. Negative acknowledgement is a *bad idea*. You don't really want your devices screaming STOP STOP at you -- what you want is for them to say "go ahead" if they are going to have trouble with arbitrary amounts of data. Perhaps this was not obvious when the protocol was developed, or perhaps there was no way to do it. But this is no reason to perpetuate a mistake. Why is negative acknowledgment a bad idea? You've said it, but haven't given any real hard examples. Besides, there sometimes *are* reasons for perpetuating mistakes. It may be more cost-effective to do so, even if it's not esthetically attractive. FORTRAN is going to be with us for quite a while, because declaring it dead tomorrow and blowing up all FORTRAN compilers will cost us more than we'd save by going to this week's fashionable language. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy