gandrews@netcom.COM (Greg Andrews) (04/06/91)
In article <D7Q_!R@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <1991Apr2.044623.299@intacc.uucp>, > mann@intacc.uucp (Jeff Mann) writes: >< 4. Therefore, if you are using a Telebit, you can't use auto baud rate >< adjusting on incoming uucp calls. You must set S50=0 and use the normal >< method of sending breaks to cycle getty until the proper speed is >< attained. >< >??? Why? > >UUCP defaults to using the g protocol. That protocol defaults to requiring >less than 256 unacknowledged bytes; both the modem and the A/UX buffers are >quite capable of storing that many unprocessed characters, therefore there >can't be any soft overruns, therefore no flow control is necessary. > Why? Because the modem can be used for interactive sessions - not just uucp. You're right that uucp doesn't need any flow control because the modem's buffer is large (over 2.5K), and three packets worth of data can be dumped into it without losing anything (assuming the standard packet size of 64 data bytes). Using the Mac's handshake signals for DTR and DCD won't hurt uucp because a lack of flow control won't cause trouble. However, interactive work is a completely different story. If you lock the interface at a high speed and don't have flow control, you run the risk of losing data from buffer overruns. Just dial in at a slower speed like 2400 or 1200 bps, ls a large directory, and watch the bytes fall on the floor. XON/XOFF flow control in the modem can cause trouble for uucp, so that's not a viable option. You can disable XON/XOFF for uucp in a chat script, but that doesn't help with incoming uucp calls. Hardware handshaking would take away the ability for the Mac to detect a disconnected session, causing security problems. About the only thing left is to unlock the modem's speed so interactive callers don't need to have overrun trouble and the system can detect an unexpected hangup. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'
urlichs@smurf.sub.org (Matthias Urlichs) (04/07/91)
In comp.unix.aux, article <1991Apr6.060922.10236@netcom.COM>, gandrews@netcom.COM (Greg Andrews) writes: < In article <D7Q_!R@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < >In comp.unix.aux, article <1991Apr2.044623.299@intacc.uucp>, < > mann@intacc.uucp (Jeff Mann) writes: < >< 4. Therefore, if you are using a Telebit, you can't use auto baud rate < >< adjusting on incoming uucp calls. You must set S50=0 and use the normal ^^^^ < >< method of sending breaks to cycle getty until the proper speed is < >< attained. < >??? Why? < > < Why? Because the modem can be used for interactive sessions - not ^^^^^^^^^^^ < just uucp. < No comment. (Sometimes people tend to overlook things...) < < However, interactive work is a completely different story. A solution would be for uucico to send a BREAK/ATS58=0/ATO to the modem whenever an 8-bit protocol is required. (Assuming a Telebit here, though with most others something like this would probably work, too. I'll hack it into my uucico one of these days.) Myself, I'm using another "fix": Don't allow interactive access. My resources are limited, and UUCP access is far more cost-effective. < XON/XOFF flow control in the modem can cause trouble for uucp, so < that's not a viable option. You can disable XON/XOFF for uucp in < a chat script, but that doesn't help with incoming uucp calls. < If you never have "slow" UUCP g calls, you can also leave XON/XOFF turned on; both uucico an the Trailblazer will turn it off automatically. < Hardware handshaking would take away the ability for the Mac to detect < a disconnected session, causing security problems. < As I said, if A/UX would only be able to access that second input pin on the serial ports (and treat that pin like DCD)... Hanging up via a long break is trivial if the modem supports it; most intelligent modems do. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49-721-621127(0700-2330) \o)/
gandrews@netcom.COM (Greg Andrews) (04/07/91)
In article <JVS_Z1N@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.unix.aux, article <1991Apr6.060922.10236@netcom.COM>, > gandrews@netcom.COM (Greg Andrews) writes: >< In article <D7Q_!R@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >< >In comp.unix.aux, article <1991Apr2.044623.299@intacc.uucp>, >< > mann@intacc.uucp (Jeff Mann) writes: >< >< 4. Therefore, if you are using a Telebit, you can't use auto baud rate >< >< adjusting on incoming uucp calls. You must set S50=0 and use the normal > ^^^^ >< >< method of sending breaks to cycle getty until the proper speed is >< >< attained. >< >??? Why? >< > >< Why? Because the modem can be used for interactive sessions - not > ^^^^^^^^^^^ >< just uucp. >< >No comment. (Sometimes people tend to overlook things...) > It's still a consideration. Just because Jeff said "uucp calls" doesn't mean he was talking about ONLY uucp calls. > >Myself, I'm using another "fix": Don't allow interactive access. > >If you never have "slow" UUCP g calls, you can also leave XON/XOFF >turned on; both uucico an the Trailblazer will turn it off automatically. > Sure, if you limit your callers to PEP uucp only, the modem and computer configuration is extremely simple. That doesn't mean other people can do it that way. You asked "Why?" in your posting. I responded with the answers. They may not apply to your system, but they probably do apply to Jeff's and to others. -- .------------------------------------------------------------------------. | Greg Andrews | UUCP: {apple,amdahl,claris}!netcom!gandrews | | | Internet: gandrews@netcom.COM | `------------------------------------------------------------------------'