26 Jun
2022
26 Jun
'22
1:57 a.m.
One of the things we liked about Datakit was that the computer didn't have
to establish the connection before it could reject the call, unlike TCP/IP
where all validation happens after the connection is made. This is also why
sockets and Datakit never worked together; sockets pretty much assume
Ethernet-like connection rules.
I am not a networking expert, but to me in this regard at least Datakit
seemed like a prettier picture. I suppose you can DOS-attack the network,
but not the machines. Datakit had other issues, for sure, like the
expensive racks of hardware, but then that's because, for better and worse,
it was designed by phone engineers rather than.... however you'd
characterize Ethernet and its original "I scream while listening to your
whisper", 5V into 50Ω Schmidt-triggered craziness. Ethernet's come a long
way, but the engineering of the original Radio Shack parts was not favored
by the Bell Labs crowd.
-rob
On Sun, Jun 26, 2022 at 9:09 AM Larry McVoy <lm(a)mcvoy.com> wrote:
Nice. Any chance you want to do a TCP/XTP
comparison?
On Sun, Jun 26, 2022 at 01:01:07AM +0200, Paul Ruizendaal wrote:
Wanted to post my notes as plain text, but the
bullets / sub-bullets get
lost.
Here is a 2 page PDF with my notes on Research Datakit:
https://www.jslite.net/notes/rdk.pdf
The main takeaway is that connection build-up and tear-down is
considerably more
expensive than with TCP. The first cost is in the
network, which builds up a dedicated path for each connection. Bandwidth is
not allocated/reserved, but a path is and routing information is set up at
each hop. The other cost is in the relatively verbose switch-host
communication in this phase. This compares to the 3 packets exchanged at
the hosts??? driver level to set up a TCP connection, with no permanent
resources consumed in the network.
In compensation, the cost to use a connection is considerably lower: the
routing
is known and the host-host link protocol (???URP") can be
light-weight, as the network guarantees in-order delivery without
duplicates but packets may be corrupted or lost (i.e. as if the connection
is a phone line with a modem). No need to deal with packet fragmentation,
stream reassembly and congestion storms as in the TCP of the early 80???s.
Doing UDP traffic to a fixed remote host is easily mapped to using URP
with no
error correction and no flow control. Doing UDP where the remote
host is different all the time is not practical on a Datakit network (i.e.
a virtual circuit would be set up anyway).
A secondary takeaway is that Research Datakit eventually settled on a
three-level
ascii namespace: ???area/trunk/switch???. On each switch, the
hosts would be known by name, and each connection request had a service
name as parameter. In an alternate reality we would maybe have used
???ca/stclara/mtnview!google!www??? to do a search.
--
---
Larry McVoy Retired to fishing
http://www.mcvoy.com/lm/boat