9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Client/server program sample code request..
Date: Sat, 23 Sep 2000 00:27:41 -0400	[thread overview]
Message-ID: <20000923042745.629E319A02@mail> (raw)

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Depends on what code you're taking about.  The datakit code in research
Unix was a fraction of the size of our IP stacks.  The code
that ran on the datakits themselves was larger but still a tiny
fraction of the size of CISCO's IOS or, the equivalent at that time,
a Unix machine being used as a router.

If you're comparing Datakit to Ethernet, then you're right.
I, however, tend to compare Datakit to IP.  Both ran on a number
of media and provided transport level protocols with defined
services.

Our datakit nodes were definitely not the worlds most reliable
LAN's.  If you compare against IP running on an Ethernet, then
a coax is certainly a lot more reliable than a Datakit node with
an interface for each host.  However, as a WAN, our network was
a lot more reliable than our equivalent IP networks whose
nodes were usually BSD Unix boxes with multiple interfaces
plugged in.  The latter had a bad habit of eating all their
MBUF's or crashing for a strangely large number of other reasons.

The host interface boards for both networks were similar in
reliability, i.e., crappy.   We lived with both Ethernet(carrying IP)
and Datakit plugged into the same machines for a long
time.  Having both networks definitely improved connectivity
over either one by leaps and bounds.  One of the reasons for
a general dial() routine was to try first one then the other.

As datakit development died off, its reliability fell way
behind that of IP, largely because routers got a lot more
reliable while datakit stayed the same.

Datakit died for a lot of good reasons; slow machine interfaces,
central control at a time autonomy was being exploited,
proprietary hardware and protocols, support by few
computer manufacturers, static routing, ...  I don't
believe that reliability was one of them.

[-- Attachment #2: Type: message/rfc822, Size: 1697 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Client/server program sample code request..
Date: Sat, 23 Sep 2000 04:51:03 +0200
Message-ID: <024a01c02509$1d40e720$89c584c3@cybercable.fr>

datakit:

    not known to work reliably at any speed, but the code is huge

:-)



             reply	other threads:[~2000-09-23  4:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-23  4:27 presotto [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-09-23  2:38 presotto
2000-09-23  2:51 ` Boyd Roberts
2000-09-23  8:17 ` Dennis Ritchie
2000-09-22 18:21 Russ Cox
2000-09-28 21:17 ` Dan Cross
2000-09-28 21:31   ` Boyd Roberts
2000-09-22  7:48 Stephen Parker
2000-09-21 23:21 forsyth
2000-09-21 23:34 ` Boyd Roberts
2000-09-22  5:40   ` Steve Kilbane
     [not found]     ` <steve@whitecrow.demon.co.uk>
2000-09-22 17:18       ` Tom Duff
2000-09-21 16:27 rog
2000-09-21 15:43 Ish Rattan
2000-09-21 15:56 ` andrey mirtchovski
2000-09-21 16:02   ` andrey mirtchovski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000923042745.629E319A02@mail \
    --to=presotto@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).