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 87131
zben@umcp-cs.UUCP (12/09/83)
. <-- Nigel to the rescue 1. Don't forget to double the DLE DLE also, else if you were to happen to want to send the sequence DLE CTL-S you would be in exactly the same position... :-) 2. Seems to me your terminal would have to do this in hardware or firmware. I don't know of many (any?) that do... 3. Doesn't the BISYNC protocol do the opposite, IE, use DLE to quote the control characters that are *ACTUALLY* to trigger special action? Ben Cranston ...seismo!umcp-cs!zben zben@umd2.ARPA