Xref: utzoo comp.protocols.tcp-ip:10911 comp.unix.xenix:11011
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fernwood!portal!cup.portal.com!thinman
From: thinman@cup.portal.com (Lance C Norskog)
Newsgroups: comp.protocols.tcp-ip,comp.unix.xenix
Subject: Re: Using SLIP with SCO Xenix/Unix
Message-ID: <28771@cup.portal.com>
Date: 10 Apr 90 23:00:29 GMT
References: <685@polygen.UUCP> <260F7FA9.4661@tct.uucp> <285@van-bc.UUCP>
  <261A4BA5.2B28@tct.uucp>
Distribution: na
Organization: The Portal System (TM)
Lines: 25

Streamlined TCP/IP also supports SL/IP under SCO Xenix and SCO Unix.
It's architected as 2 pieces: 1) the slip pushable module processes
network device driver (LLI) messages at the top and a 2-way stream
of bytes at the bottom, and 2) the TTR (TTY Remora module) is a
Streams device driver at the top and a UNIX line discipline at the bottom.
If a multi-port card supports alternate line disciplines (always iffy,
but if you can make the SCO event stuff work with a mouse, the TTR should work.
)
The software can be set up to handle dial-ins via a special accounts 
(one account per client IP address), but does not auto-dial.

This architecture is inefficient, essentially because you can't tell a
standard UNIX serial driver to spool a thousand bytes in a low-level queue
until it sees the SL/IP inter-packet marker; the TTR has to spool
them up instead, incurring software overhead.  Of course, BSD doesn't
handle this either.  The right way to handle this is with a Streams
serial driver which can be told to do the spooling.

The only public-domain SL/IP device driver posted ran all the data out to
a user program.  This has got to be much slower than the above architecture.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909u!