> The people working on TCP/IP did know of the Spider work (like they knew of
> the Cambridge ring work), but it didn't really have any impact; it was a
> totally different direction than the one we were going in.
I'm aware of that, and I think it was the same the other way around. My
interest is tracing how the networking API of Unix developed in the very
early days, and that's were there is a link.
When I asked a few months back why Bell Labs did not jump onto the work
done at UoI, Doug observed that the lab's focus was on Datakit and that
triggered my interest.
>>>> it turns out that the TIU driver was in Warren's repo all along:
>
> V4?! Wow. I'd have never guessed it went that far back.
My current understanding is that Spider development began in 1969 and
that it was first operational in 1972. By '73/'74 it connected a dozen
computers at Murray Hill and Unix had gained basic network programs.
From Sandy Fraser's "Origins of ATM" video lecture I understand that the
Spider learnings included that using a mini to simulate a switch/router
was too slow and too costly, and that doing flow control inside the network
induced avoidable complexity (I guess Fraser/Cerf/Pouzin all learned that
lesson around the same time). The follow-on, custom designed Datakit switch
was to correct these issues.
Work started in 1974 and I guess that prototypes may have been available
around 1978 (when Spider was apparently switched off at Murray Hill).
By 1981 a multi-site Datakit network connected various Bell labs and by
1983 Datakit was introduced as a commercial service.
As to the Spider network API, it currently seems that it was relatively
simple: it exposed the switch as a group of character mode devices, with
the user program responsible for doing all protocol work. Interestingly,
Spider used a high speed DMA based I/O board (DR11-B), whereas the
Datakit switch was apparently connected to a low speed polled I/O board
(DR11-C).
I did not find the Datakit device driver(s) in the V7 source tree (only a
few references in tty.h), so it is hard to be sure of anything. However,
it seems that in V7 the Datakit switch was used as "a fancy modem" so to
speak, supporting the uucp software stack.
There is source for a Datakit driver in the V8 tree, but I currently
have no time to study that (and perhaps it is beyond my scope anyway).
All input and corrections much appreciated.
> From: Paul Ruizendaal
>>> The report I have is: "SPIDER-a data communication experiment"
>>> ...
>>> I think it can be public now, but doing some checks.
OK, that would be great to have online. I _think_ the hardcopy I have
(somewhere! :-) is that report, but my memory should not be trusted.
The people working on TCP/IP did know of the Spider work (like they knew of
the Cambridge ring work), but it didn't really have any impact; it was a
totally different direction than the one we were going in.
>>> it turns out that the TIU driver was in Warren's repo all along:
V4?! Wow. I'd have never guessed it went that far back.
>>> The code calls snstat()
>> The object code for snstat() is in libc.a in the dmr's V5 image.
>> Reconstructed, the source code is here:
>> ...
>> In short, snstat() is a modified stty call
Yes, I looked and found the original source, appended below.
>>> Could that be the tiu sys call (#45) in the sysent.c table for V4-V6?
I wonder if we'll ever be able to find a copy of the kernel code for that
tiu() system call. And I wonder what it did?
> [1] Oldest alarm() code I can find is in PWB1
> ...
> Either alarm existed in V5 and V6 .. or is was added after V6 was
> released, perhaps soon after. In the latter case the 'nfs' code that we
> have must be later than 1974
Remember, that source came from the MIT system, which is a modified PWB1.
So it's not surprising it's using PWB1 system calls.
Noel
--------
/ C interface to spider status call
.globl _snstat
.globl cerror
_snstat:
mov r5,-(sp)
mov sp,r5
mov 4(r5),r0
mov 6(r5),0f
mov 8(r5),0f+2
sys stty; 0f
bec 1f
jmp cerror
1:
clr r0
mov (sp)+,r5
rts pc
.data
0: .=.+6
Below what I've been able to find about alarm():
[1] Oldest alarm() code I can find is in PWB1, dated July 1977:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.chttp://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/clock.c
Either alarm existed in V5 and V6, and was removed from distributions
(which seems unlikely to me), or is was added after V6 was released,
perhaps soon after. In the latter case the 'nfs' code that we have must
be later than 1974 (even though the man page is dated that way).
It could be from the 2nd half of 1975.
[2] Interestingly, the idea to implement sleep() in terms of alarm()
seems to originate in UoI network unix:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c -- sslep()
This occurs in Oct 1977. In V7 this idea is taken to user space and
sleep() is no longer a system call.
[3] The UoI code has an instance of alarm() being used to break out of
a potentially stalled network call, so that usage seems to have
established itself early on.
Progressed a little further:
[1] The 'ufs' command was a variation on the 'nfs' command. The man page
that Noel provided for nfs includes the paragraph:
"There is a command /usr/usg/tom/ufs which transfers files to
the USG Unix systems. The option letter 7 for the 11/70 or
4 for the 11/45 should be used. Otherwise 'ufs' is similar to
'nfs'."
This means there must have been a Unix based File Store (server).
Does anybody have a suggestion who 'tom' at USG might have been?
[2] The V5 man pages in the archive have a man page for 'npr',
in section VI. It says:
NAME
npr - print file on Spider line-printer
SYNOPSIS
npr file …
DESCRIPTION
Npr prints files on the line, printer in the Spider room,
sending them over the Spider loop. If there are no arguments,
the standard input is read and submitted. Thus npr may be used
as a filter.
FILES
/dev/tiu/d2 tiu to loop
It suggests that the printer was hooked up to the Spider switch and that
channel 2 was hardcoded to it.
[3] Upon closer inspection, the tiu.c driver is a character mode device,
the use of disk buffers and a strategy() routine had me confused.
It is just a reflection of the fact that it uses DMA hardware.
The code for tiu.c in NSYS/V4 is rather different from the code in
the SRI-NOSC tree: thinking on how to select channels seems to have
changed in between these two versions.
[4] Also I found the below post that mentions the snstat() call:
http://minnie.tuhs.org/pipermail/tuhs/2015-December/006286.html
The object code for snstat() is in libc.a in the dmr's V5 image.
Reconstructed, the source code is here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/a93175746bd9f94f
In short, snstat() is a modified stty call, an evolution in the direction of
the later ioctl() system call.
No progress as yet on the early history of 'alarm()'.
Paul
>> It is a paper copy, but I can make a scan for you.
>
> That makes it sounds like it might not be possible to put it online?
> What's the exact title, so I can look and see if it's already online?
> I'm pretty sure I've got a hardcopy of some Spider thing, but it would
> probably take me a while to find it... ;-)
The report I have is:
"SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974.
I did not find it online, but it may be out there somewhere.
I think it can be public now, but doing some checks.
> OK, the only one I have is 'nfs'. Here's the source, and man page:
>
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a
> http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6
Many thanks! There is some puzzling stuff in there that I'd like to
figure out, but that is easier to discuss once the report is online.
Also, it turns out that the TIU driver was in Warren's repo all along:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.chttp://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man4/tiu.4
It's fun to read that the V4 man page says "The precise nature of the
UNIX interface has not been defined yet." and Noel's version says:
"The precise nature of the UNIX interface is defined elsewhere." (yet
the dates are the same!).
Some things are surprising (to me, at least):
First of all, opening a connection to the File Store is a single open on
data channel 1:
http://chiselapp.com/user/pnr/repository/Spider/artifact/854a591c0e7a3a54?l…
I would expected the code to first have sent a connection request to the
switch on control channel 1. Perhaps the File Store was an integral part
of the switch/router (a Tempo minicomputer
ftp://bitsavers.informatik.uni-stuttgart.de/pdf/tempoComputers/TEMPO-1_ad_Nov69.pdf)
with channel 1 functionality hardwired.
Next, the code has a hackish form of non-blocking I/O:
http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l…
I'm puzzled about the alarm() sys call. That did not exist in 1973 -- or did it
only exist in Bell Labs private builds?
The code calls snstat(), for instance here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l…
That seems to be a sys call to here:
http://chiselapp.com/user/pnr/repository/Spider/artifact/2c7d65073a7cb0a5?l…
Could that be the tiu sys call (#45) in the sysent.c table for V4-V6?
Ok, I just did an experiment with the rm command and the results surprised me.
On Unix v5 logged in as root I created a small test file then did
chmod 444 on it. Unfortunately it appears that mere users can still rm
the file and also directories are not safe from the rmdir command
(even directories set to mode 444).
This seems to be the case for v6 and v7 as well.
To be fair rm will prompt the user with: test1: 0100444 mode
but the user only has to type y and hit enter and the file is toast.
Is there no way to completely protect files from being deleted?
Mark
> From: Paul Ruizendaal
>>> the 1974 report on Spider
>> Is that online? If not, any chances you can make it so?
> It is a paper copy, but I can make a scan for you.
That makes it sounds like it might not be possible to put it online?
What's the exact title, so I can look and see if it's already online?
I'm pretty sure I've got a hardcopy of some Spider thing, but it would
probably take me a while to find it... ;-)
> I think that in the lifespan of Spider (1972-1978) there were 3 main
> network programs (basing myself on McIlroy's Unix Reader):
> - 'nfs' an FTP-like program ...
> - 'ufs' not sure what it was, but I think a telnet-like facility
> - 'npr' a network printing program
OK, the only one I have is 'nfs'. Here's the source, and man page:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.ahttp://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6
Noel
>
>> I'm looking into the history of Spider and early Datakit. Sandy Fraser
>> was kind enough to send me the 1974 report on Spider
>
> Is that online? If not, any chances you can make it so?
It is a paper copy, but I can make a scan for you.
> which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
> are part of it?
I think tiu.c might be all. The TIU ("terminal access unit") was the network card,
so to speak (actually some 5 boards in a rack) and did a lot of the heavy lifting.
From the tiu.c file I understand that a DR11-B parallel I/O card was used on
the PDP side to connect to the TIU, and that access was structured as a block
device driver.
> I'm not at all clear how this stuff got there - someone at Bell must have just
> dumped the contents of the 'dmr' directory, and sent it all off?
Looks like it.
> The PWB1-based MIT systems also have a lot of the Spider software (although it
> was never used). It's a slightly different version than the one above: 'diff'
> shows that 'tiu.c' is almost identical, but mpx.c has more significant
> differences.
>
> It also contains man pages, and sources for some (?) user programs; I have the
> source and manpage for 'nfs'. What other names should I be looking for? (The
> man page for 'nfs' doesn't list any other commands.) I'll put them up
> momentarily.
I think that in the lifespan of Spider (1972-1978) there were 3 main network
programs (basing myself on McIlroy's Unix Reader):
- 'nfs' an FTP-like program to copy files to/from a central File Store.
I'm not sure whether the File Store was a Unix machine or something else.
- 'ufs' not sure what it was, but I think a telnet-like facility
- 'npr' a network printing program
A little surprising, but no reference to a Spider mail program in that document.
> In the meantime, I'll append the 'tiu' man page.
Thanks! It is from October 1973, which sounds right for Spider. I guess this
code is the first networking on Unix, predating the UoI work by about 18 months.
> From: Paul Ruizendaal
> I'm looking into the history of Spider and early Datakit. Sandy Fraser
> was kind enough to send me the 1974 report on Spider
Is that online? If not, any chances you can make it so?
> Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g.
> the 'tiu' device driver, the 'nfs' file transfer package, etc.)?
You're in luck.
To start with, check out:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/oldstuff
which contains the drivers tiu.c, mpx.c - I'm not sure what other files there
are part of it?
I'm not at all clear how this stuff got there - someone at Bell must have just
dumped the contents of the 'dmr' directory, and sent it all off?
The PWB1-based MIT systems also have a lot of the Spider software (although it
was never used). It's a slightly different version than the one above: 'diff'
shows that 'tiu.c' is almost identical, but mpx.c has more significant
differences.
It also contains man pages, and sources for some (?) user programs; I have the
source and manpage for 'nfs'. What other names should I be looking for? (The
man page for 'nfs' doesn't list any other commands.) I'll put them up
momentarily.
In the meantime, I'll append the 'tiu' man page. There isn't one for mpx,
alas.
Noel
--------
.th TIU IV 10/28/73
.sh NAME
tiu \*- Spider interface
.sh DESCRIPTION
Spider
is a fast digital switching network.
.it Tiu
is a directory which contains
files each referring to a Spider control
or data channel.
The file /dev/tiu/d\fIn\fR refers to data channel \fIn;\fR
likewise /dev/tiu/c\fIn\fR refers to control channel \fIn\fR.
.s3
The precise nature of the UNIX interface
is specified elsewhere.
.sh FILES
/dev/tiu/d?, /dev/tiu/c?
.sh BUGS
>> There are two other routes to TCP/IP on a PDP11 without split I/D:
>> ...
>> DCEC's adaptation of the Wingfield TCP/IP library, designed to work
>> with V6. It is mostly a user space daemon, but requires some kernel
>> enhancements.
>
> I wonder what the performance would be like, since the TCP is in a user
> process (a different one from the application), i.e. there's a process switch
> every time the application goes to send or receive data. This wouldn't have
> been such an issue when the code was written, since ARPANet-type networks
> were not very fast, but with a better network, it would have been limiting.
IEN98 (http://www.rfc-editor.org/rfc/ien/ien98.txt, page 2) has the answer: about 10kb/s.
The DCEC version used shared memory instead of rand ports and was claimed to be
a bit more performant, but I have no number. I'd be surprised if it was twice as fast,
so perhaps 15kb/s.
Paul
