The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Subject: [TUHS] Early Internet work (Was: History of select(2))
Date: Sun, 15 Jan 2017 20:01:01 -0500 (EST)	[thread overview]
Message-ID: <20170116010101.8DF6F18C083@mercury.lcs.mit.edu> (raw)

    > From: Paul Ruizendaal

    > I guess by April 1981 (RFC777) we reach a point where things are
    > specified to a level where implementations would interoperate with
    > today's implementations.

Yes and no. Earlier boxes would interoperate, _if addresses on each end were
chosen properly_. Modern handling of addresses on hosts (for the 'is this
destination on my physical network' step of the packet-sending algorithm) did
not come in until RFC-1122 (October 1989); prior to that, lots of host code
probably tried to figure out if the destination was class A, B or C, etc, etc.

Also, until RFC-826 (ARP, November 1982) pretty much all the network
interfaces (and thus the code to turn the 'destination IP address' into an
attached physical network address, for the first hop) were things like ARPANet
that no longer exist, so you could't _actually_ fire up one of them unless you
do something like the 'ARPANet emulation' that the various PDP-10 simulators
use to allow old OS's running on them to talk to the current Internet.


    > only if one accepts IEN54/55 as 'TCP/IP'

What are they, if not TCP/IP?

Not the modern variant, of course, but then again, nothing before the early
90's is truly 'modern TCP/IP'.

    > IEN98 mentions a TCP3 stack done for Network Unix ...  in 1978 by DTI /
    > Gary Grossman.

I read this, BITD, but don't recall much about it. I was not impressed by the
coding style.

    > at the same time it also uses old-style assignments ('=+' instead of
    > '+='). Could this be "typesetter C"?

I don't know. IIRC, that compiler supported both styles. It had to have been a
later compiler than the one that came with V6, that didn't support longs.  But
I don't recall any bug with long support in the typetter C compiler we had at
MIT.

    > From the above I would support the moniker "first TCP/IP in C on Unix"

No. That clearly belongs to the DTI one. (The difference between V3 and V4,
while significant, aren't enough to make the DTI not 'TCP/IP in C for Unix'.)

If you want to say 'first V4TCP/IP in C for Unix', maybe; I'd have to look for
dates on the one done at MIT for V6, that may be earlier, but I don't think
so. (Check the minutes in the IEN's, that's probably the best source of data
on progress of the various implementations.)


    > One thing that I'm unclear about is why all this Arpanet work was not
    > filtering more into the versions of Unix done at Bell Labs.   

Here's my _guess_ - ask someone from Bell for a sure answer.

You're using 20/20 hindsight. At that point in time, it was not at all obvious
that TCP/IP was going to take over the world.

There were a couple of alternatives for moving data around that Bell used -
Datakit, and UUCP - and they worked pretty well, and there was no reason to
pick up on this TCP/IP thing.

I suspect that it wasn't until LAN's became popular than TCP/IP looked like a
good thing to have - it fits very well with the capabilities most LANs had (in
term of the service provided to things attached to them). Datakit was its own
thing, and for UUCP you'd have to provide a reliable stream, and TCP/IP 'just
did that'.

     Noel


             reply	other threads:[~2017-01-16  1:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16  1:01 Noel Chiappa [this message]
2017-01-16 10:31 ` Paul Ruizendaal
2017-01-16 12:07 ` Tony Finch
  -- strict thread matches above, loose matches on Subject: below --
2017-01-30 16:15 Noel Chiappa
2017-01-30 16:41 ` Clem Cole
2017-01-30 16:44 ` Clem Cole
2017-01-30 15:34 Noel Chiappa
2017-01-30 21:20 ` Paul Ruizendaal
2017-01-30  2:50 Noel Chiappa
2017-01-30  3:33 ` Nick Downing
2017-01-30  3:38   ` Ron Natalie
2017-02-08  3:58   ` Dave Horsfall
2017-01-30  8:26 ` Paul Ruizendaal
2017-01-30  1:44 Noel Chiappa
2017-01-29 18:35 Noel Chiappa
2017-01-29 17:41 Noel Chiappa
2017-01-29 20:28 ` Paul Ruizendaal
2017-01-30  1:34 ` Nick Downing
2017-01-30  2:19   ` Clem Cole
2017-01-30  2:30     ` Larry McVoy
2017-01-30  2:43       ` Ron Natalie
2017-01-30  2:43       ` Clem Cole
2017-01-30  2:32     ` Larry McVoy
2017-01-30  2:39       ` Clem Cole
2017-01-30 13:13     ` Dave Horsfall
2017-01-30 13:37       ` Larry McVoy
2017-01-16 15:17 Noel Chiappa
2017-01-16 14:42 Noel Chiappa
     [not found] <mailman.1.1484532001.2693.tuhs@minnie.tuhs.org>
2017-01-16 10:21 ` Johnny Billquist
2017-01-16  1:47 Noel Chiappa
2017-01-16 10:06 ` Paul Ruizendaal
2017-01-15  2:30 Noel Chiappa
2017-01-13 13:19 Noel Chiappa
2017-01-09  2:35 [TUHS] History of select(2) Warren Toomey
2017-01-09 10:36 ` Paul Ruizendaal
2017-01-12  3:54   ` Clem Cole
2017-01-13  9:13     ` Paul Ruizendaal
     [not found]       ` <20170114164102.GA31665@yeono.kjorling.se>
2017-01-16  0:13         ` [TUHS] Early Internet work (Was: History of select(2)) Paul Ruizendaal

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=20170116010101.8DF6F18C083@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.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).