minow@decvax.UUCP (Martin Minow) (11/04/83)
I should like to warn the gentle reader against using any of the RS232 signals (CD, DTR, etc.) for flow control handshaking. There are just too many places where this will not work, including remote modems, port multiplexors (such as Gandalf and Micom), 20 Ma. current loop links, and pretty much anything with an operating system that you can't dig into to "fix" to your requirements. Also, it will not work in the future when local area networks will carry most terminal traffic. The fact that operating systems do not generally understand these signals -- and are not going to in the future -- will cause problems when you attempt to sell your product to a wider audience. While the XOFF/XON protocol isn't perfect, it does work reasonably well in a variety of environments and is not too difficult to implement. A contributor suggested that buffer limitations are a factor in rejecting XOFF/XON. This does not seem to be the case in my work. We watched large amounts of data passed into a DECtalk text to speech terminal over a 9600 Baud terminal line and seldom saw more than one or two characters transmitted from the host after DECtalk sent an XOFF. (DECtalk's effective data rate is around 300 Baud, so it sent XOFF's often.) By the way, our input buffer size is (I think) around 512 characters, and we send XOFF if there are more than 256 characters pending. This gives the host 250 msec. (at 9600 Baud) to stop. We send XON when the buffer is 3/4 empty. This works well. RAM chips are cheap. An historical note: XOFF and XON were originally used to control the paper tape reader reader run relay on ASR 33 teletypes. XON turned the relay on; XOFF turned it off. Martin Minow decvax!minow
laura@utcsstat.UUCP (Laura Creighton) (11/07/83)
Arrrgh, Martin, We *know* that XON/XOFF works in all sorts of environments! But it is a *bad thing*. 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. 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 an endless variety of these. 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. 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. ^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! 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. Laura Creighton utzoo!utcsstat!laura
mason@utcsrgv.UUCP (Dave Mason) (11/07/83)
As a student assignment I had the class calculate the number of characters
required in a buffer for a 1 way sattelite, 1 way terrestrial link.
It only works out to <180 characters at 4800 baud. This means a 1k buffer
that x-offs at 3/4 full will work up to 4800 via sattelite. 1/2 full will
work up to 9600. (This assume interrupt handler recognition of X-OFF).
If you are going through any datacom gear at all, you will need a buffer;
All that handshake signals buy you (over X-OFF/X-ON) is 8 bytes (the UART
delays) which isn't going to make or break most designs.
-- Dave Mason, U. Toronto CSRG,
{cornell,watmath,ihnp4,floyd,allegra,utzoo,uw-beaver}!utcsrgv!mason
or {decvax,linus,research}!utzoo!utcsrgv!mason (UUCP)padpowell@wateng.UUCP (PAD Powell [Admin]) (11/08/83)
I have run into the same set of problems with "smart" terminals, which is why I have strongly suggested that users always have the :dumbest: terminal available around for debugging purposes. This terminal should run at 9600 (at least). As an additional extra, it should print out "control characters" in a readable form. Much to my amazement, I could not find a new terminal with these features. Some of them had the "display control" feature, but a escape sequence TURNED IT OFF!!! Most could not run at 9600. Finally I rescued an antique Volker Craig 303A, serial number 100 which must be the first one they sold. This thing is so antique that I dread the day when it fails, as I think that some of the parts are not available. If there are some terminals around that have these features, I would sure be glad to buy one. Patrick Powell, U. Waterloo
guy@rlgvax.UUCP (Guy Harris) (11/09/83)
***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!guymark@cbosgd.UUCP (11/10/83)
^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!
Sorry, but this is false. There is no such character as control-S or
control-Q. Look in your ANSI standard. There ARE characters DC3 and DC1,
which happen to have the binary representation we are all thinking of.
In the interests of being able to generate all characters from all
keyboards, terminal manufacturers have arranged that the keystroke
control-S produces DC3, and control-Q produces DC1. This does not
alter the fact that characters 00-1F are specifically set aside for
control functions. The fact that many systems do not make use of all
of these "control characters" has allowed people to write software that
uses them as "just characters". (EMACS is an example.) This does not
mean that someone who implements XON/XOFF handshaking (the defined
semantics of DC3/DC1, or at least one of them) are wrong, it means
the people who used the control characters for their editors are the
ones who violated the standard. (vi is guilty too, although to a
lesser extent: it uses, for example, control-G as a command. It does
not use ^S or ^Q.)
The MIT point of view (very vocally defended by RMS, the author of
the original EMACS) is that delays should be done with padding, or
with packet switched networks. Ideally, terminals should be used
that do not require padding (there are a few out there) even at 9600
baud. Otherwise, you pad or do something transparent. But they very
strongly feel that xon/xoff should not be used by terminals. They do
have some valid points - xon/xoff does not always work well over a
network, and it does break EMACS, which has ^S and ^Q commands.
However, the other side of the coin is that many terminals run much
better using xon/xoff than with padding, since the padding has to be
worst-case, and if the terminal has a buffer it can often do a lot
better than worst case. While one might claim that, since some
terminals do not need any padding, all terminals should be designed
to not need padding, the facts remain that (a) there are a LOT of
terminals out there that do need some padding, although usually very
little (the HP 2621 and Ann Arbor Ambassador are two good examples),
and of course there are lots of vt100's; (b) there are some features
that require flow control to implement, e.g. smooth scrolling ("ooze
mode", as we call it), and (c) some kinds of terminals cannot be
implemented without flow control - in particular, bitmapped terminals
scroll slowly and so need flow control.
In the ideal world, all terminals will support a packet switched network
which does flow control in a totally transparent way. I'm not holding
my breath.
Markjhh@ihldt.UUCP (John Haller) (11/10/83)
Scratch HP2621 from the list of terminals that don't need padding. When tabs are used extensively (such as when a heavily indented listing is viewed), or a lot of characters are output while the terminal is in insert mode, the line transmission rate is higher than the rate that the HP2621 removes characters from the buffer. And the performance of the HP2621P with the printer on, or the HP2621B is even worse. John Haller
phil@amd70.UUCP (Phil Ngai) (11/14/83)
The adds regent and viewpoint can be put into a mode where they print
control characters, and you can only change it from the keyboard.
I think control characters are underlined but otherwise uninterpreted,
i.e. CR or LF don't work.
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!phil