chris@umcp-cs.UUCP (11/07/83)
I can show how XON/XOFF flow control doesn't work over a network.
Assume the terminal has a 32 character input FIFO. Now, the host
writes a long escape sequence or whatever. Terminal sends an XOFF
at 16 characters in FIFO. XOFF has to go over effective <x> baud
net connection, while terminal<->net connection is at least 2<x>
baud. Unfortunately, the XOFF must have a packet constructed for
it. This packet has a 40 byte header. Meanwhile, the next string
written at the host is still coming across the connection (ie maybe
20 of those 40 header bytes have got through already with a large
(20 character) text stream in the packet. By the time the host
receives the XOFF, the entire 20 character packet has already gone
through the net connection, and overflowed the FIFO.
Of course, this problem goes away if you do the handshaking at
the local net connection instead of the remote. (If only the
flow control weren't on the "S"earch for and "Q"uote keys....
How about a new standard with untypeable flow control codes?)
Chris
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaysdyer@bbncca.ARPA (Steve Dyer) (11/07/83)
"If only the flow control weren't on the (S)earch and (Q)uote keys..." I'm more inclined to strangle the original programmers of these editors who usurped keys which had an already well-known function. /Steve Dyer decvax!bbncca!sdyer
minow@decvax.UUCP (Martin Minow) (11/08/83)
Newsgroups: net.dcom Subject: Re: XON/XOFF as flow control? References: <3636@umcp-cs.UUCP> Chris Torek makes several valid points regarding XOFF/XON as flow control characters: 1. On a network, the terminal input buffer may be too small to allow the XOFF stop to take effect. The only solution to this is to design a fairly large communications line buffer. The device I'm working on can absorb about 250 characters AFTER it sends XOFF before it loses data. 2. Some applications programs assume that the control characters may be used for program-specific tasks. The major offender is EMACS. The principal EMACS designer claims that EMACS is correct and the terminals are desinged incorrectly. (This is a summary of a long-running and acrinomious discussion that has been going on for many years and which I hope does not start again.) The Ansi standard, as interpreted by terminal manufacturers, reserves the C0 control characters (Hex 00 through 1F and 7F) for device control. Their use by an applications program is at the pleasure and convenience of the manufacturer. The next generation of terminals, such as the DEC VT200 series and the DEC Professional, also use the C1 control characters (Hex 80 through 9F and FF) and the GR graphics set (Hex A0 through FE). You would thus be well advised to be careful when using "bit 8" as a text position marker. Martin Minow decvax!minow
phil@amd70.UUCP (11/08/83)
I once tried using a VT-100 at 9600 baud in emacs, and found it kept
trying to search for things. The kludge I used to make it work was
to turn off XON/XOFF and use padding. Isn't that disgusting?
--
Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!phildmmartindale@watcgl.UUCP (Dave Martindale) (11/10/83)
I can show how XON/XOFF flow control doesn't work over a network. Assume the terminal has a 32 character input FIFO. Now, the host writes a long escape sequence or whatever. Terminal sends an XOFF at 16 characters in FIFO. XOFF has to go over effective <x> baud net connection, while terminal<->net connection is at least 2<x> baud. Unfortunately, the XOFF must have a packet constructed for it. This packet has a 40 byte header. Meanwhile, the next string written at the host is still coming across the connection (ie maybe 20 of those 40 header bytes have got through already with a large (20 character) text stream in the packet. By the time the host receives the XOFF, the entire 20 character packet has already gone through the net connection, and overflowed the FIFO. Of course, this problem goes away if you do the handshaking at the local net connection instead of the remote. Two comments: Of course you have to do the handshaking at the local connection to the net. Handshaking between the terminal and the host just doesn't work, since you can have arbitrarily long delays between one and the other (if the network is very busy, if the packet has to physically travel through several networks and gateways, etc.) 32 characters is an absurdly small input buffer, completely ridiculous. Even a basic, dumb 24x80 terminal needs 1920 bytes of screen memory. 100 chars of input buffer will not affect costs appreciably.
smith@umn-cs.UUCP (11/11/83)
#R:umcp-cs:-363600:umn-cs:1600004:000:971 umn-cs!smith Nov 10 09:53:00 1983 The problem about network processing of Xon/Xoff exists primarily in poorly designed network frontends. A proper design (i.e. the Arpa TIP's handling of Xon/Xoff) intercepts Xon/Xoff locally and converts them into network level flow control actions. It is wrong to let the host's application software or 'terminal emulator' handle that kind of flow control. If we COULD change the Xon/Xoff characters to something else then we could change it from a troublesome 'stop/go' protocol into a more effective (and easier to handle) 'go ahead' protocol as laura pointed out. But I wouldn't hold my breath -- as recently as last year I was using a 'state of the art' timesharing system supported by a 'major manufacturer' which had NO terminal flow control support at all. As an Emacs afficinado I can only cringe at the ^S problem since it routinely afflicts me with two mutually exclusive 'standards'. Rick. [smith.umn-cs@Rand-Relay] [...ihnp4!umn-cs!smith]
chris@umcp-cs.UUCP (11/12/83)
* <- anti-netnews-bu
"32 characters is a ridiculously small input buffer"
Isn't that what DEC has been putting on VT100s all this time??
(I agree, though; there's really no excuse for less than 256
characters nowadays, and I think it should really be a couple
tens of K, allocatable at need.... There *are* terminals that
do this! Unfortunately all the ones that come to mind are
pretty lousy otherwise.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relaythomas@utah-gr.UUCP (Spencer W. Thomas) (11/12/83)
Just as a counter-example to the "do xon/xoff locally, use out of band flow control over the network" scheme, I present the DEC-20. Assume: 1. You have a device such as LocalNet which allows you to do Xon/Xoff flow control at the terminal end, and out-of-band flow control at the other end. 2. You have a DH or equivalent (e.g. Able's) which supports o-o-b flow control on your DEC-20. Now, you are "fooling" the DEC-20 into thinking that it is never flow controlled since the flow control is happening in the DH (the right place). However, the DEC-20 has built into its terminal handler a "reasonableness" check on how long it takes to output a string. If it takes "too long" (twice as long seems to be ok, at least), the CPU assumes something is wrong and the front-end crashes. Oops. (on the other hand, when you send the ^S through the net to the DEC-20, it takes another line or so to stop, usually.) Oh, in response to the person who wondered how you do delays if you throw away nulls - I think you misunderstood the original statement. The nulls are thrown away by the TERMINAL as they are received, not by the CPU. Therefore they still perform their padding function. =Spencer
smith@umn-cs.UUCP (Richard Smith) (11/14/83)
#R:umcp-cs:-363600:umn-cs:1600005:000:831 umn-cs!smith Nov 13 10:09:00 1983 Re: 32 character input buffer. Yes, it IS an incredibly small amount. Again, the old Arpanet TIPs had terminal buffers of about that size. This was never a problem except with IBM terminals (i.e. 2741's) since REAL terminals used to all work a character at a time. The small buffers worked adequately because of (1) appropriate network-level flow control and (2) fairly fast transmission even across multiple network nodes. Troubles started to appear when people started hanging micros and bubble-terminals off of TIPs. The 'solution' was to implement local Xon/Xoff. Why were the buffers so small? Well, you had to fit too much into 32kb of memory and if you had 63 terminals on your TIP, there just wasn't enough memory to give everyone their own 1k buffer. Rick. [smith.umn-cs@CSNet-Relay] [...ihnp4!umn-cs!smith]
dmmartindale@watcgl.UUCP (Dave Martindale) (11/14/83)
Re the DEC-20 "reasonableness check" interacting with Able hardware flow control: This is simply an example of the assumptions of your tty driver (characters are always transmitted continuously) conflicting with the assumptions of the person who installed your Able boards (hardware flow control is transparent to the host so let's use it). The solution is simply to fix the driver or not use hardware flow control. This has nothing to do with the desirableness of XON/XOFF flow control. In the case of your LocalNet, why not have your terminal do XON/XOFF handshaking with your localnet box, the network do its own out-of-band flow control, and the host's localnet interface to XON/XOFF flow control with the host? There is no need to do terminal-to-host flow control. This should eliminate the long delay between sending XOFF and the cessation of characters being received.
smith@umn-cs.UUCP (Richard Smith) (11/15/83)
#R:umcp-cs:-363600:umn-cs:1600006:000:266 umn-cs!smith Nov 14 08:13:00 1983 Concerning out-of-band flow control on DEC-20s: The moral of your story is "IF you want to connect a network to a DEC-20, THEN don't try to fool it that way". Working network server software IS availible for the 20s; I spent a couple of years using it. Rick.