TUHS January 2017

tuhs@tuhs.org

77 participants
95 discussions

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Something I've been meaning to ask for a while: why Unix and octal on > the PDP-11? Because of the DEC documentation? Yeah, DEC did it all in octal. > I understand why other DEC architectures (e.g. PDP-7) were octal: 18b > is a multiple of 3. But PDP-11 is 16b, multiple of 4. Look at PDP-11 machine code. Two-op instructions look like this (bit-wise): oooossssssdddddd where 'ssssss' and 'dddddd' (source and destination) have the same format: mmmrrr where 'mmm' is the mode (things like R, @Rn, etc) and 'rrr' is the register number. All on octal boundaries. So if you see '010011' in a dump (or when looking at memory through the front console switches :-), you know immediately that means: MOV R0, @R1 Much harder in hex... :-) Noel

7 years, 3 months

Article on 'not meant to understand this'

by Warren Toomey

http://thenewstack.io/not-expected-understand-explainer/ in case you haven't seen it yet. Cheers, Warren

7 years, 3 months

Re: [TUHS] Article on 'not meant to understand this'

by jnc＠mercury.lcs.mit.edu

> From: Angelo Papenhoff > The problem is that the function which did the savu was not necessarily > the same as the function that does the retu, so after retu the function > could have the call stack of a different function. As dmr explained, > this worked with the PDP-11 compiler but not with the interdata > compiler. To put it slightly differently, in PDP-11 C all stack frames look identical, but this is not true of other machines/compilers. So if routine A called savu(), and routine B called aretu(), when the call to aretu() returned, procedure B is still running, but on procedure A's stack frame. So on machines where A's stack frame looks different from B's, hilarity ensues. (Note that aretu() was significantly different from retu() - the latter switched to a different process/stack, whereas aretu() did a 'non-local goto' [technically, switched to a different stack frame on the current stack] in the current process.) > Note that Lions doesn't explain this either, he assumed that the > difficulty was with with u_rsav and u_ssav .. (he probably wasn't that > wrong though, it really is confusing, but it's just not what the comment > refers to) Right. There are actually _three_ sets of saved stack info: int u_rsav[2]; /* save r5,r6 when exchanging stacks */ int u_qsav[2]; /* label variable for quits and interrupts */ int u_ssav[2]; /* label variable for swapping */ and it was the interaction among the three of them that I found very hard to understand - hence my (incorrect) memory that the 'you are not' comment actually referred to that, not the savu/aretu stuff! Calls to retu(), the primitive to switch stacks/processes, _always_ use rsav. The others are for 'non-local gotos' inside a process. Think of qsav as a poor man's exception handler for process software interrupts. When a process is sleeping on some event, when it is interrupted, rather than the sleep() call returning, it wakes up returning from the procedure that did the savu(qsav). (That last is because sleep() - which is the procedure that's running when the call to aretu(qsav) returns - does a return immediately after restoring the stack to the frame saved in qsav.) And I've forgotten exactly how ssav worked - IIRC it was something to do with how when a process is swapped out, since that can happen in a number of ways/places, the stack can contains calls to various things like expand(), etc; when it's swapped back in, the simplest thing to do is to just throw that all away and have it go back to where it was just before it was decided to swap it out. Noel

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch This is getting a bit far afield from Unix, so my apologies to the list for that. But to avoid dumping it in the Internet-History list abruptly, let me answer here _briefly_ (believe it or not, the below _is_ brief). > AIUI there were two major revisions to the IPv4 addressing architecture: Not quite (see below). First, one needs to understand that there are two different timelines for changes to addressing: in the hosts, and in the routers (called 'gateways' originally). To start with, they were tied together, but as of RFC-1122, they were formally separated: hosts no longer fully understood the syntax/semantics of addresses, just (mostly) treated them as opaque 32-bit quantities. > subnetting (RFC 917, October 1994 ... RFC 950, August 1985), and > classless routing (RFC 1519, September 1993) Originally, network numbers were 8 bits, and the 'rest' (local) part was 24. Mapping from IP addresses to physical network addresses was some with direct mapping - ARP did not exist - the actual local address (e.g. IMP/Port) was contained in the 'rest' field - each network had a document which specified the mapping. (Which is part of the interoperability issue with old implementations.) As some point early on, it was realized that 8 bits of network number were not enough, and the awful A/B/C kludge was added (it was dropped on the community, not discussed before-hand). Subnetting was indeed the next change. Then the host/router split happened. Classless routing (which effectively extended addesses, for path-computation purposes, to 32+N bits - since you couldn't look at a 32-bit IP address and immediately tell which was the 'network' part any more, you _had_ to have the mask as well, to tell you how many bits of any given address were the network number) was more of a process than a single change - the inter-AS routing (BGP) had to change, but so did IGP's (OSPF, IS-IS), etc, etc. > originally called supernetting (RFC 1338, June 1992). There was this effort called ROAD which produced RFC-1338 and 1519, and IIRC there was an intermediate, involving blocks of network numbers (1338), and that slowly evolved into arbitrary blocks (1519). One should also note that the term "super-netting" comes from a proposal by Carl-Hubert ("Roki") Rokitansky which did not, alas, make it to RFC. (His purpose was different, but it used the same mechanism.) Alas, the authors of 1338/1519 failed to properly acknowledge his earlier work. Noel

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist >> everyone working on TCP/IP heard about Version 4 shortly after the >> June, 1978 meeting. > Over a year before any documents said anything about it. Incorrect. It's documented in IEN-44, June 1978 (written shortly after the meeting, in the same month). > I'm sure people were doing networking protocols and stuff earlier, but > it wasn't the TCP/IP we know and talk about today People were working on Unix in 1977, but it's not the same Unix we know and talk about today. Does that mean it's not Unix they were working on? >> there were working implementations (as in, they could exchange data with >> other implementations) of TCP/IPv4 by January 1979 - see IEN 77. ^^ > But not TCP4 then. I just specified that it was v4 (see above). > thus, not interoperable with an implementation today No, with properly-chosen addresses (because of the changes in address handling), they probably would be. Noel

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> 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

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by Johnny Billquist

On 2017-01-16 03:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > Like I pointed out, RFC760 lacks ICMP. > > So? TCP will work without ICMP. True. However, IP and UDP will have issues. > > Which also makes one question how anyone would have known about IPv4 in > > 1978. > > Well, I can assure you that _I_ knew about it in 1978! (The decision on the v4 > packet formats was taken in the 5th floor conference room at 545 Tech Sq, > about 10 doors down from my office!) > > But everyone working on TCP/IP heard about Version 4 shortly after the June, > 1978 meeting. Over a year before any documents said anything about it. This is where I have problems. :-) > > Also, first definition of TCP shows up in RFC 761 > > If you're speaking of TCPv4 (one needs to be precise - there were also of > course TCP's 1, 2, 2.5 and 3, going back to 1974), please see IEN-44. (Ignore > IEN's -40 and -41; those were proposals for v4 that got left by the wayside.) That is a very good point. I've been talking v4 all the time (both for IP and TCP). Like I said, I'm sure people were doing networking protocols and stuff earlier, but it wasn't the TCP/IP we know and talk about today, and you just reaffirmed this. And yes, the TCP/IP we know today did not come out of a blue sky. Of course it is based on earlier work. (Just do you don't have to go on about that again.) > > So yes, I still have problems with claims that they had it all running > > in 1978. > > I never said we had it "all" running in 1978 - and I explicitly referenced > areas (congestion, addressing/routing) we were still working on over 10 years > later. > > But there were working implementations (as in, they could exchange data with > other implementations) of TCP/IPv4 by January 1979 - see IEN 77. But not TCP4 then. And thus, not interoperable with an implementation today, and interoperable in general being a rather floating and moving target, as you had several imvompatible TCP versions, using different protocol numbers, and several incompatible IP versions. > (I'll never forget that weekend - we were in at ISI on Saturday, when it was > normally closed, and IIRC we couldn't figure out how to turn the hallway > lights on, so people were going from office to office in the gloom...) Fun times, I bet. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> (Check the minutes in the IEN's, that's probably the best source of data > on progress of the various implementations.) Another place to look is Internet Monthly Reports and TCP-IP Digests (oh, I see you've seen those, I see a reference to one). I have this distinct memory of Dave Clark mentioning the Liza Martin TCP/IP for Unix in one of the meeting report publihed as IENs, but a quick look didn't find it. Noel

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by Paul Ruizendaal

On 14 Jan 2017, at 17:41 , Michael Kjörling wrote: > On 13 Jan 2017 10:13 +0100, from pnr(a)planet.nl (Paul Ruizendaal): >> over on the internet history mailing list. > > Interesting. Care to give me a pointer toward it? That mailing list is here: http://mailman.postel.org/mailman/listinfo/internet-history On 14 Jan 2017, at 23:02 , Johnny Billquist wrote: > IMPs did not talk IP, just for the record. Yes, this is true of course. The software of the IMP was resurrected from printouts some time ago: http://walden-family.com/impcode/ > The problem is that all the RFCs are available, and they are later than this. The ARPAnet existed in 1979, but it was not using TCP/IP. If you look at the early drafts of TCP/IP, from around 1980-1981, you will also see that there are significant differences compared to the TCP/IP we know today. There was no ICMP, for example. Error handling and passing around looked different. Once again: yes. When exactly was the TCP/IP specification completed? That is an issue where reasonable people can hold different opinions. What software first implemented this on Unix? Here too reasonable people can hold different opinions. Below my take on this, based on my current understanding (and I keep repeating that I'm learning new things about this stuff almost every day and please advise if I'm missing things). Development of TCP/IP The specification that became TCP/IP apparently finds its roots in 1974, and it is gradually developed over the next years with several trial implementations. By March 1977 we get to TCP2 and more trials. Next it would seem that there was a flurry of activity from January to August 1978, resulting in specifications for TCP4 (IEN54 and IEN55). Then, up to March more implementations follow, as documented in IEN98. With those implementations tested, also for interoperability, more changes to the protocol and implementations follow and 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. This is not where it stops, 'modern' congestion control only goes back to the late 80's (see for instance Craig Partridge http://www.netarch2009.net/slides/Netarch09_Craig_Partridge.pdf, it is an interesting read). Early Unix code bases (1) The Mathis/Haverty stack In 1977 Jim Mathis at SRI writes a "TCP2.5" stack in PDP11 assembler, running on the MOS operating system (for the LSI11). In 1978 Haverty is assigned to take this stack and make it run on V6 Unix. He builds a kernel with ports, await and capac to achieve this. It is a mixed success (see http://mailman.postel.org/pipermail/internet-history/2016-October/004073.ht…), but he maintains it through 1978 and 1979 as a skunkworks project and the code eventually supports TCP4 (as defined in IEN54/55). The source has survived in Jack Haverty's basement as a printout, but it is not online. As far as I know know, this the first TCP/IP on Unix (a tie with the Wingfield implementation, and only if one accepts IEN54/55 as 'TCP/IP'). (2) The Grossman (DTI) stack IEN98 mentions a TCP3 stack done for Network Unix (by then called ENFE/INFE) in 1978 by DTI / Gary Grossman. I don't currently have information about that implementation. As at March 1979 it did not appear to support TCP4. (3) The Wingfield/Cain stack In 1978 BBN / Michael Wingfield, was commissioned by DCEC / Ed Cain to write a TCP4 tack in C for Unix V6. As it stood in March 1979 this code supported IEN54/55 with the AUTODIN II security extensions that heralded back to 1975. It is a partial implementation: it does not support IP fragmentation and it has a simplistic approach to incoming out-of-order packets (drop everything until the right one arrives). However, it worked and kept being maintained by Ed Cain, who by October 1981 has added support for ICMP and GGN (https://www.rfc-editor.org/rfc/museum/tcp-ip-digest/tcp-ip-digest.v1n1.1). He is still supporting it as late as 1985 (https://www.rfc-editor.org/rfc/museum/tcp-ip-implementations.txt.1) As far as I know know, only the March 1979 code survives. I'm currently retyping it, about halfway through. I'm not sure what compiler it was written for: it uses longs, but apparently this is still somewhat broken (with comments in the source amounting to 'this WTF necessary to work around compiler bugs'); at the same time it also uses old-style assignments ('=+' instead of '+='). Could this be "typesetter C"? The code feels like it might be based on earlier work, for instance the BBN BCPL implementation for TENEX a few years earlier, but that is pure speculation. It could also be that Wingfield was new to C and bringing habits from other languages with him. Once all done, I'll ask Michael about it. I'm on thin ice here, but my current guess would be that the 5,000 line code base would need some 500 lines of new code to make it interoperable with today's implementations. From the above I would support the moniker "first TCP/IP in C on Unix" as claimed by UCLA, either for the March 1979 version if one takes the view that '90% modern' is good enough, or for the October 1981 version if support for RFC777 is the benchmark. In the latter view it beats the Gurwitz stack by about a month or two. However, it is not a full implementation of the specifications. (4) The Gurwitz stack Last in the list of candidates is the Rob Gurwitz stack for BSD4.1 (see IEN168), started in January 1981. It is a full implementation of the protocols that looks like it was done from scratch (as confirmed by Gurwitz and Haverty) and consolidates the earlier learnings. In my opinion, it is the first implementation where the source code has a distinct 'early unix smell' (please excuse the phrase), arguably more so that the later Joy code. The first iterations of the code don't support (the as yet non-existent) RFC777. By November 1981 there is a beta distribution tape that does, and this code looks to interoperate with modern TCP/IP implementations as-is. If the benchmark is a full implementation interoperating with today's code, the first TCP/IP on Unix would I think be the Gurwitz stack. Possibly it is the first TCP/IP in that definition on any OS. Note that this is also where TCP/IP and Network Unix join back up [but this view might change as I learn more about the Grossman / DTI version]: the Gurwitz code uses an API closely based on that of UoI's Network Unix and the provided user land programs (Telnet, FTP, MTP, etc.) appear ports from that code base (or perhaps from a BBN development of the UoI work). === In any case, I think it is fair to say that TCP/IP as we know it today did not drop from the sky in 1981. There was a vast amount of prior work done in the second half of the 70's on a variety of hardware and operating systems, experience that all feeded into the well known RFC's. 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. The folks involved were certainly aware of each other and the work that was going on. With universities the cost of 'always on' long distance lines may have been too great, but within Bell Labs that would have been less of an issue and there is a clear link with the core business of the Bell System. Would anybody have some background on that? Paul

7 years, 3 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > Like I pointed out, RFC760 lacks ICMP. So? TCP will work without ICMP. > Which also makes one question how anyone would have known about IPv4 in > 1978. Well, I can assure you that _I_ knew about it in 1978! (The decision on the v4 packet formats was taken in the 5th floor conference room at 545 Tech Sq, about 10 doors down from my office!) But everyone working on TCP/IP heard about Version 4 shortly after the June, 1978 meeting. > Also, first definition of TCP shows up in RFC 761 If you're speaking of TCPv4 (one needs to be precise - there were also of course TCP's 1, 2, 2.5 and 3, going back to 1974), please see IEN-44. (Ignore IEN's -40 and -41; those were proposals for v4 that got left by the wayside.) > So yes, I still have problems with claims that they had it all running > in 1978. I never said we had it "all" running in 1978 - and I explicitly referenced areas (congestion, addressing/routing) we were still working on over 10 years later. But there were working implementations (as in, they could exchange data with other implementations) of TCP/IPv4 by January 1979 - see IEN 77. (I'll never forget that weekend - we were in at ISI on Saturday, when it was normally closed, and IIRC we couldn't figure out how to turn the hallway lights on, so people were going from office to office in the gloom...) Noel

7 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS January 2017