eric@unm-cvax.UUCP (12/06/83)
The problem with XON/XOFF protocol is that nobody seems to do it
correctly. If a character (which can appear in data) is used as flow
control then there needs to be a way of telling when it is being used
for flow control (e.g. to prevent buffer overflows) and when it is
not used as flow control, but appears in the data.
An example of this is to write a C program which outputs across data
communication lines a ^S (DC3) from the computer to a terminal. Most
terminals such as VT100's interpet this as flow control and wait for
the host buffers to free up (which will never happen since the
host REALLY did not send it as that. If the user is on a direct or
modem line, simply resets his terminal and off he goes. This is
violating the convention. Also this will not work with various
LANS and Multiplexors as if you define that this gear uses XON/XOFF
the capture the data and do not pass it down the net. This is
correct as they should protect their buffers as well. If you
run your C program or cat down that file with a Control S in it
with XON/XOFF defined then you wind up hanging a port until you
reset your data communications equiptment.
The way to correctly implement flow control is that whenever
a host notices this character or a user whats to enter the XON/XOFF
character as data is that it should be proceeded with a DLE character
which is the Data Link Escape Character. This character is stripped
off by the data communications equiptment and is treated as data
by the data comm equiptment instead as flow control. This should
be done an is not done by most systems and terminals that use
XON/XOFF. If this is not done and folks cannot implement
flow control correctly then perhaps we should push for another
type of flow control instead such as CTS/RTS via the RS232C standard.
This cannot be done currently as DEC vt100/200 ignore CTS at all
times.
I for one am tired of this problem, as with a LAN in and running
Multiplexed lines I have to run with XON/XOFF disabled in my
LAN and mux's or else I see hung computer ports, and running
with these options disabled can cause the loss of data...
Any comments, suggestions, etc are appreciated.
Eric Engquist - (505) 277-6131
{ucbvax!lbl-csam,purdue,cmcl2}!lanl-a!unm-cvax!eric
Univ. of New Mexico - 2701 Campus Blvd. - Albuquerque, NM 87131lars%acc@sri-unix.UUCP (12/10/83)
e is that it must work! What you are describing is a lot like transparent BiSynC; this is' certainly a workable way to achieve character transparency, but this is a technique normally used in an asynchronous ASCII environment; imposing such a convention on a multitude of equipment at this late time is not feasible. I can suggest a much simpler way out of your problem; stick by the following two rules: 1. When using XON/XOFF for flow control, these two characters are not available as data characters. Since the terminal will not send them unless you hit the keys, what this really means, is that the terminal driver on your system must discard any ^S characters (and preferably also ^Q) sent by a program in cooked mode. 2. In a network environment, all flow control is hop-by-hop. I.e. ^S and ^Q are processed at each hop and not forwarded. An example of this is to write a C program which outputs across data communication lines a ^S (DC3) from the computer to a terminal. Most terminals such as VT100's interpet (sic) this as flow control and wait for the host buffers to free up (which will never happen since the host REALLY did not send it as that. If the user is on a direct or modem line, simply resets his terminal and off he goes. This is violating the convention. Also this will not work with various LANS and Multiplexors as if you define that this gear uses XON/XOFF the capture the data and do not pass it down the net. This is correct as they should protect their buffers as well. If you run your C program or cat down that file with a Control S in it with XON/XOFF defined then you wind up hanging a port until you reset your data communications equiptment. If your equipment is standard, then resetting your terminal (by cycling power or hitting SETUP/RESET on a VT1xx) will cause it to momentarily drop its DTR signal. On a modem link or a virtual circuit of an LAN, this should cause a circuit disconnect; on a direct link, this should cause a forced logout. In either case, it is true, it will also clear the hung line.
gwyn%brl-vld@sri-unix.UUCP (12/11/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> Perhaps the simplest solution would be for the UNIX terminal handler to refuse to transmit STALL/UNSTALL character data (not necessarily DC3/DC1; some terminal handlers let you set them differently) when stalling flow control is enabled.