The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] TCP/IP networking in 8th edition unix
@ 2017-11-21 23:41 Paul Ruizendaal
  2017-11-24 23:52 ` Paul Ruizendaal
  0 siblings, 1 reply; 6+ messages in thread
From: Paul Ruizendaal @ 2017-11-21 23:41 UTC (permalink / raw)



I'm trying to figure out how tcp/ip networking worked in 8th edition Unix.

I'm starting from dmr's paper about streams (http://cm.bell-labs.co/who/dmr/st.html), the V8 man pages (http://man.cat-v.org/unix_8th/3/) and browsing the source code (tarball here http://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/).

In the below I use 'socket' to mean a file descriptor bound to a network connection. My current understanding is like this:

- The hardware interface is exposed as a character device; for tcp/ip only ethernet is supported. Directly accessing this device reads/writes ethernet frames.

- One can push an 'ip' module (only) onto an ethernet device; this module also handles ARP. Once this is done IP messages are queued to the virtual ip devices, /dev/ipXX. The device minor number XX equals the protocol number, i.e. the ip packets are demultiplexed into separate virtual devices. IP packets from multiple ethernet cards all end up on the same virtual ip devices. I'm not sure if one can still read/write to the ethernet device after pushing the ip module, but I think you can, creating a raw IP interface so to say.

- On /dev/ip6 one can push a TCP module. The TCP module handles the TCP protocol and demultiplexes incoming traffic to the virtual /dev/tcpXX devices. On /dev/ip17 one can push a UDP module. The UDP module handles the UDP protocol and demultiplexes incoming traffic to the virtual /dev/udpXX devices. Not sure wether the ip6 and ip17 devices can still be read/written after pushing these disciplines.

- There are 100 udp devices, /dev/updXX. To open a UPD socket, one opens an unused udp device (through linear search). This socket accepts binary commands ('struct upduser') through the read()/write() system calls. There is a command to set the local port (effectively 'bind') and a comment to also set the foreign address and port (effectively 'bind+connect'). As long as the socket is not connected actual datagrams are preceded by a command header with the address/port information (effectively 'sendto'/'recvfrom'). Once the socket is connected, it is no longer possible to send further commands, but each write/read is a datagram. For udp sockets it is not possible to specify the local address: it is chosen by the system to match with the given foreign address.

- There are 100 tcp devices /dev/tcpXX. Initial connection is always over an odd numbered device. To open a TCP socket, one opens an unused tcp device (through linear search). This socket accepts binary commands ('struct tcpuser') through the read()/write() system calls. There is a command to actively connect (effectively 'connect' with optional 'bind'), and a command to passively listen (effectively 'bind'+'listen'). If the connect command is sent, one can read one more response block and then the socket becomes a regular tcp socket. If the listen command is sent, one can read multiple response blocks, one for each new client (effectively 'accept'). Those response blocks contain a device number for the new client connection, i.e. one has to subsequently open device /dev/tcpXY to talk to the client. This number is always even, i.e. locally initiated tcp connections are over odd numbered tcp devices, and remotely initiated connections are over even numbered tcp devices - not sure what the significance of this is.

- The above seems to be modeled on the Datakit setup, where the network is exposed as 520 virtual devices, one for each channel, as /dev/dk/dkXXX. These channels than also seem to accept binary command blocks through the read()/write() interface, with a 'connect' type command changing the connection into a data only channel.


Anybody on the list with 8th edition experience who can confirm that the above understanding is about correct?

Paul





^ permalink raw reply	[flat|nested] 6+ messages in thread
* [TUHS] TCP/IP networking in 8th edition unix
@ 2017-11-26 21:28 Paul Ruizendaal
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Ruizendaal @ 2017-11-26 21:28 UTC (permalink / raw)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

Thanks for explaining that. I think it may be for 10th edition though.

I searched for ipcopen() and 'gated' in the 8th edition source and could
not find them. In that search I did find a few bits that strongly suggest that
IP over Datakit was what was used in late '85 (when dmr posted about this).

In /usr/src/cmd/inet/READ_ME there is an example configuration that seems
to match with dmr's example. In that file an IP over a Datakit channel
appears to be configured.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6d09b05c7f06a2cc?ln=119-120)

The program 'dkipconfig' sets up a circuit and pushes the IP discipline on
the stream, both on the local end and on the remote end. It sets fixed local
and remote addresses, much the same as with a 'slip' line.
(see http://chiselapp.com/user/pnr/repository/v8unix/artifact/6c5f3267b58721a6?ln=78,91)
 
On Sat, Nov 25, 2017 at 4:50 PM, William Cheswick <ches at cheswick.com> wrote:
>
> Nope, not IP over Datakit, as I recall.  It was quite interesting to work at
> a site (Bell Labs) where there were two distinct network technologies.
>
> [--snip--]
>
> This library was socks about seven years before socks, originally written by
> Presotto and Howard Trickey.  The relay program was originally called
> “gated”, but that wouldn’t do after a while.  I renamed it “proxyd”, and
> that is the first use of “proxy" in this context that I am aware of.
>
>  If you were on AT&T’s intranet and wanted to connect externally, you ripped
> out the entire socket dance and replaced it with an ipcopen call.  I also
> distributed common modified clients, like ptelnet, pftp, pfinger, etc.
>
> I still have all this code, and I suppose it ought to go in an archival
> repository.  I can’t imagine that AT&T/Lucent/Alcatel/Nokia would care at
> this point. Anyone want it?
>


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-26 21:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-21 23:41 [TUHS] TCP/IP networking in 8th edition unix Paul Ruizendaal
2017-11-24 23:52 ` Paul Ruizendaal
2017-11-25 21:50   ` William Cheswick
2017-11-25 23:21     ` Gregg Levine
2017-11-26  0:24     ` Brad Spencer
2017-11-26 21:28 Paul Ruizendaal

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).