9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: geoff@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] datakit
Date: Thu, 19 Aug 2004 19:43:48 -0700	[thread overview]
Message-ID: <4697c901caf1f3aef38bcb285334b6ea@collyer.net> (raw)
In-Reply-To: <20040820115259.12e1c14c@garlic.apnic.net>

My experience with datakit was limited, but from what I understand
(and can remember) the advantages were:

• it provided some protection against snooping and meddling with data
in transit by running connections directly from the network controller
(kept in a locked closet) to the hosts and by not being a broadcast
medium, and by securing the connections between network controllers.

• partly as a consequence, when a call arrived and the datakit
controller said that it was from a particular destination, you could
believe it.

• when you placed a call, you handed a dial string like
`nj/astro/helix!uucp' to the datakit controller and it returned with
either an error message or a live connection.  You could also tell
that controller if you expected to need a lot of bandwidth (e.g.  for
file transfer) or not, and it would try to reserve bandwidth along the
route.  So no need for DHCP, ARP, RARP, BOOTP, sockets, sockaddrs,
inaddrs, etc., etc.

• IP, UDP and TCP were subsumed by a supposedly-simple protocol, URP.
I believe datakit was a reliable network, so you didn't need an extra
layer of protocol such as TCP.

• datakit was available in a variety of speeds and could be run great
distances, including cross-country.

I'm less familiar with the drawbacks, though I have heard some of the
moaning over the years, so I'll give a try:

• datakit hardware, particularly the controllers, was expensive.

• it was a centrally-managed network, arguably less open to ad-hocery
than ethernets built from switches and routers.  Some may see this as
a disadvantage, though it enabled many of the advantages named above.

• some of the host interfaces (e.g., Vax ones) were reputedly
painfully slower than the network itself.

My dislike for one-problem-one-protocol-one-RFC is largely one of
taste and conserving energy for more important things.  Do we really
need over 3,700 RFCs to make our networks work?  I don't have a strong
opinion about the end-to-end principle or various other IETF dogma.
We could certainly have done worse, OSI being the scariest of the
possible disasters (and it's not quite dead yet, it keeps popping up
in places like LDAP!).

Are you sure you don't have Datakit in your central offices or
long-distance equipment?



  reply	other threads:[~2004-08-20  2:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-19 15:11 Steve Simon
2004-08-20  1:35 ` geoff
2004-08-20  1:52   ` George Michaelson
2004-08-20  2:43     ` geoff [this message]
2004-08-20  3:09       ` George Michaelson
2004-08-20  5:46         ` geoff
2004-08-21  0:33           ` ron minnich
2004-08-21  4:51             ` boyd, rounin
2004-08-21 14:22             ` Brantley Coile
2004-08-22  9:50               ` Tim Newsham
2004-08-23  2:50               ` ron minnich
2004-08-20 14:13         ` boyd, rounin
2004-08-20  9:45       ` C H Forsyth
2004-08-20 12:55         ` Long Political Rant. Was: [Re: [9fans] datakit] Dave Lukes
2004-08-20 16:45           ` Jack Johnson
2004-08-20 16:59             ` rog
2004-08-20 13:06         ` [9fans] datakit Wes Kussmaul
2004-08-20 16:51         ` Skip Tavakkolian
2004-08-20 17:07           ` rog
2004-08-22 19:06             ` Jack Johnson
2004-08-20 18:41           ` boyd, rounin
2004-08-21 16:37             ` Boris Maryshev
2004-08-21 17:19             ` Boris Maryshev
2004-08-20  3:30     ` ron minnich
2004-08-20 14:24       ` boyd, rounin
2004-08-23 15:04         ` andrey mirtchovski
2004-08-23 15:27           ` ron minnich
2004-08-20 13:48   ` boyd, rounin
2004-08-20  5:05 dmr
2004-08-20  5:35 ` George Michaelson

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=4697c901caf1f3aef38bcb285334b6ea@collyer.net \
    --to=geoff@collyer.net \
    --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).