🚀 go-pugleaf

    However, it seems that everyone I ask about SLIP seems to speak ill of
    it, and curiously mostly "heard that it's bad" not "used it and it was
    bad."  I hear comments about it being slow, but is it SLIP, or merely
    the serial line?  E.g., what does one expect off a 9.6k line?  I did
    hear one concrete complaint; that SLIP does not do error correcting
    efficiently (or at all?)- is this true?

SLIP does no error correcting.  This is not a problem - IP doesn't do
and error correcting either.  The big problem is that it doesn't do any
error detection either (whereas HDLC and Ethernet have 16 and 32 bit
CRCs).  Now, IP does have a HEADER checksum, and both UDP and TCP are
SUPPOSED to checksum the data portion of the packets, there are cases
(NFS comes to mind) where this is not necessarily true.  Furthermore the
IP/UCD/TCP checksum algorithm is not designed to detect the sorts of
errors that can occur over async data paths.  This is not just an
accademic problem - real data has been corrupted over cnonections where
it looks like everthing was going fine.


    I have used SLIP, but from a user standpoint a couple of years ago.  It
    wasn't the fastest when running RFS over it, but it was cheaper than
    buying an ether- net board.

    So in summary, is SLIP all that bad?  Are there other relatively
    standard methods of running TCP without sizable investments in hardware?

Slip isn't that bad, especially if you use the headercompressing, CRCing
CSLIP.  It is not esthetically pleasing.  Have you priced ethernet boards
recently?  I see them advertised all the time for less than $150 (for PCs).

BillW
-------