rts/cts on 3b2 tty ports (flow control)

[Robert Viduya]

> > Comments about there ought to be an escape mechanism to allow
> > transfer of entire character set (re: Ungermann/Bass tty net)
> 
> In fact, ^P (ASCII DLE) does 'escape' the special chars on the
> U/B net exactly as you had hoped. On the other hand, you are correct,
> no tty driver support exists to effect this automatically although
> we have considered it here. We live with the XON/XOFF flow control,
> it's not nearly as painful as people make it sound, you change a
> few key-bindings in EMACS and make sure things are CBREAK and
> everything starts to work (except things like XMODEM and UUCP which
> should really be fixed in my opinion, KERMIT works fine.)
> 

Actually, it's pretty painful when you want to UUCP over the network.
I don't know the protocol definition for UUCP, but I've played around
with looking at the data it sends with a line monitor and it seems that
an UUCP uses an ^P as some kind of 'start of packet' character.  Naturally,
the U/B eats them.  We don't have the source to UUCP, so we can't modify
it.

Anyway, fixing UUCP to handle it is, in my opinion, is a kludge.  There
are reasons why flow control should not be implemented as part of the data
path of a transmission link, the main being that it preempts certain bit
sequences from being sent without special casing them (kludge).  I have
yet to hear of a good reason for not implementing flow control via hardware
lines (other than it not being the accepted standard).  If I had my way,
everything would use hardware flow control and each terminal would have
one more key that would toggle start/stop control to give humans access
to flow control.  Unfortunately, this isn't the case.

				robert
-- 
Robert Viduya
Georgia Institute of Technology

...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert