rbraun@spdcc.COM (Rich Braun) (04/12/91)
There has been some discussion of CTS/RTS in comp.unix.sysv386, and I'm in the midst of specifying a SLIP interface for a product under development. One of the requirements is the ability to communicate with SLIP running on virtually any Unix system. SCO's TCP product includes a caveat that SLIP won't work faster than 2400 baud for Unix 3.2.0 or earlier; presumably they've made some fixes to the serial port driver so it will handle faster data rates without flow control. The engineering veep here shudders at the thought of hardware flow control. I'm claiming one should support CTS/RTS in the interest of providing better performance. But he does have a point: I've spent many an hour tearing out my hair making RS-232 interfaces work against odd flavors of equipment, and we don't want our customers to go bald too. So, I pose the question to the net. When designing a new product which supports SLIP, what kind of performance can I expect without flow control against various flavors of Unix? Will I have to get into the business of writing device drivers and/or OEMing "smart" serial cards? Am I crazy to consider developing an interface without RTS/CTS? Is the half-duplex hardware flow control supported by SCO widespread enough that I need to worry about supporting it? Finally, PPP (Point to Point Protocol) seems to address many inadequacies in SLIP. For example, it's possible to use XON/XOFF flow control with PPP, because it remaps control characters out of the range 01-1F. Is PPP catching on quickly, and is it generally expected that new products supporting serial-line IP should also support PPP? (And, can I get a public-domain C implementation?) -rich