Doesn?t the OSU Webserver work over DECnet? Zane

Hi Peter. Just a quick note regarding your comment on DEC and OSI vs. TCP. It triggered some memories of the distant past. I was at DEC in the early 80?s. I started in the Tops-10 networking group, but wound up being part of the ?DECnet-36? project. I wrote about half of the DECnet stack for Tops-10 and TOPS-20. I left DEC in about 1983 when they cancelled the Jupiter. My recollection around then was OSI was supported by the ITU, all of PTTs around the world and most, if not all, global telecom companies. TCP/IP was seen as a mostly US-originated short term hack by most of them. Brilliant foresight. Most of us thought this OSI stuff was BS, but we had to play along. We were all very familiar with TCP/IP and were big fans and used it daily. I have a map/printout of the ?ARPAnet? in 1978 and it was about 70 nodes, with about 50 nodes being DEC machines. DEC participated along with most of the other major computer vendors in endless OSI standards committee meetings which ultimately got nowhere. Some of them, I had the misfortune of participating in and it was like watching paint dry. It seemed to most vendors (including DEC) up until about 1984 thought that OSI was the future. Some on the DECnet review group (DRG) saw the future as DECnet morphing into the OSI stack. They had some great people on the DRG, and they correctly pointed out the shortcomings with TCP/IP (limited addressing (pre-IP 6, vulnerabliliies, poor routing, etc), but history shows they made the wrong choice and those vulnerabilities were mostly fixed over time. In those early days most other vendors had horrible proprietary networking solutions and DECnet was by fair the best. After I left DEC, the group I managed developed both OSI and TCP stacks at Stratus Computer in the mid-80?s. My recollection is every customer bought TCP, nobody bought OSI. I think we sold one copy of the OSI product to GM for their ?factory of the future? project (OSI/MAP I think it was called). So much for OSI and top down planning! Perhaps the only thing useful that came out of many years of OSI work was the framework and terminology. Cheers, Vern

I will stick my fingers in my ears rather than risk hearing anything bad about Algol 68 :) An extract from a document that I like: REFETY ROWSETY ROWWSETY NONROW slice{860a} : weak REFETY ROWS ROWWSETY NONROW primary{81d}, sub symbol{31e}, ROWS leaving ROWSETY indexer{b,c,d,e}, bus symbol{31e}. -- Such lines cannot be read or written with a straight face. As for OSI, the UK Academic 'community' resisted TCP/IP between campuses in the UK, even keeping us using the dreadful coloured books protocols over X.25, because "OSI was the way!" Keith -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: 08 November 2021 16:08 To: hecnet at Update.UU.SE Subject: Re: [HECnet] "IP protocols on DECnet' If you will look at the saga of the Algol-68 effort, you will see some uncanny parallels. In other words, what we learn from History is that we don't learn from History... On 11/8/21 11:05 AM, Vern Brownell wrote:

Algol68 RS for VAX/VMS - I?ve been trying to find a copy that isn?t the ELLA cut down version and/or ctrans. It was from RSRE, at least the front end was. Someone at Oxford wrote the code generator to translate the streams language into VAX code. There were translators for ICL architectures too. On 8 Nov 2021, at 18:45, Thomas DeBellis <tommytimesharing at gmail.com> wrote: ? I promise not to quote, repeat, rephrase, paraphrase or otherwise imply anything that Hoare and/or Dijkstra said!! One of my best friends in High School and during my undergraduate years (shortly after the invention of electricity) was positively an Algol 68 fanatic. I don't think I ever saw him without that green and white ACM magazine issue with a focus on Algol 68 which he would whip out at a moment's notice. Sometimes it seemed that he thought that a sneeze could best be expressed in Algol 68. And he was one of the most brilliant programmers I knew at the time, so nobody dreamed of considering that he might not be perfectly correct. We kept waiting for a DEC implementation of Algol 68. Even a subset. Sigh... On 11/8/21 11:31 AM, Keith Halewood wrote: I will stick my fingers in my ears rather than risk hearing anything bad about Algol 68 :) An extract from a document that I like: REFETY ROWSETY ROWWSETY NONROW slice{860a} : weak REFETY ROWS ROWWSETY NONROW primary{81d}, sub symbol{31e}, ROWS leaving ROWSETY indexer{b,c,d,e}, bus symbol{31e}. -- Such lines cannot be read or written with a straight face. As for OSI, the UK Academic 'community' resisted TCP/IP between campuses in the UK, even keeping us using the dreadful coloured books protocols over X.25, because "OSI was the way!" Keith -----Original Message----- From: owner-hecnet at Update.UU.SE<mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Thomas DeBellis Sent: 08 November 2021 16:08 To: hecnet at Update.UU.SE<mailto:hecnet at Update.UU.SE> Subject: Re: [HECnet] "IP protocols on DECnet' If you will look at the saga of the Algol-68 effort, you will see some uncanny parallels. In other words, what we learn from History is that we don't learn from History... On 11/8/21 11:05 AM, Vern Brownell wrote: Hi Peter. Just a quick note regarding your comment on DEC and OSI vs. TCP. It triggered some memories of the distant past. I was at DEC in the early 80?s. I started in the Tops-10 networking group, but wound up being part of the ?DECnet-36? project. I wrote about half of the DECnet stack for Tops-10 and TOPS-20. I left DEC in about 1983 when they cancelled the Jupiter. My recollection around then was OSI was supported by the ITU, all of PTTs around the world and most, if not all, global telecom companies. TCP/IP was seen as a mostly US-originated short term hack by most of them. Brilliant foresight. Most of us thought this OSI stuff was BS, but we had to play along. We were all very familiar with TCP/IP and were big fans and used it daily. I have a map/printout of the ?ARPAnet? in 1978 and it was about 70 nodes, with about 50 nodes being DEC machines. DEC participated along with most of the other major computer vendors in endless OSI standards committee meetings which ultimately got nowhere. Some of them, I had the misfortune of participating in and it was like watching paint dry. It seemed to most vendors (including DEC) up until about 1984 thought that OSI was the future. Some on the DECnet review group (DRG) saw the future as DECnet morphing into the OSI stack. They had some great people on the DRG, and they correctly pointed out the shortcomings with TCP/IP (limited addressing (pre-IP 6, vulnerabliliies, poor routing, etc), but history shows they made the wrong choice and those vulnerabilities were mostly fixed over time. In those early days most other vendors had horrible proprietary networking solutions and DECnet was by fair the best. After I left DEC, the group I managed developed both OSI and TCP stacks at Stratus Computer in the mid-80?s. My recollection is every customer bought TCP, nobody bought OSI. I think we sold one copy of the OSI product to GM for their ?factory of the future? project (OSI/MAP I think it was called). So much for OSI and top down planning! Perhaps the only thing useful that came out of many years of OSI work was the framework and terminology. Cheers, Vern On Nov 8, 2021, at 9:55 AM, Peter Lothberg <roll at stupi.com><mailto:roll at stupi.com> wrote: Another protocol that might make sense is a DECnet adopted variant of RFC-953, where sri-nic is replaced by MIM::... Can anyone explain why DEC decided to go down the OSI track, instead of putting Phase-4 services on top of ip (TCP). By the time the "OSI vs IP" protocol was over in reality over? -P For anyone that has minutes to spare, here is Geoff Huston's talk at Ripe about the "history".. http://www.lothberg.org/Video/Geoff_Huston-How_the_Internet_Changed-2 0140513-163958.mp4

Indeed, one wonders about the focus on Call by Name and all that thunky stuff.? I can't remember off hand where I needed Jensen's Device, although everybody did agree it was a cool think.? On the other hand, the thunk could get expensive. At the time, there was far focus on control flow than data structures.? So programming Algol 60 (on the 10) is not that much different from C in many, many respects, except: 1. More consistency and verbs to avoid using a goto (like a return statement) 2. Non-atomic data structures or records (struct's) The ALGOL STAR game had to do some gymnastics to pick data into ints into order to track players which would have been completely unnecessary had C been used. But this was 1974 on Long Island; nobody had heard of C or Unix. I'm not sure if it was out of the lab in any significant way by then. On 11/8/21 1:59 PM, Dave McGuire wrote:

Algol 60 and Algol 68 are very different languages. Algol 60 is very simple, and was implemented quite widely. There is a PDP-11 version that apparently was derived from a PDP-8 implementation. And the first Algol 60 compiler -- a FULL language implementation -- ran in just 4k 27-bit words (1961, Electrologica X1, by Dijkstra and Zonneveld). Algol-68 adds structures (but not methods), and a bunch of other stuff. It's a much harder language. Lots of people did subset implementations; I know of a PDP-11 compiler (done by Carnegie-Mellon, no sign that it has been preserved). A few were pretty complete; CDC actually had one as a commercial product for the 6000 mainframes, implemented by their Dutch office, most likely at the urging of CWI in Amsterdam. It has been said that C++ was inspired by Algol-68. If so, the lessons didn't come across well, no more than the Algol-60 lessons came across to the C designers. And I wonder if it helped inspire Python. Algol 68 does not have call by name. But if you really want the equivalent you can pass a function as an argument. paul

Oh no, real stylish diehards sneeze exclusively in assembler, Sir! Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: Monday, 08 November, 2021 20:00 To: hecnet at Update.UU.SE Subject: Re: [HECnet] "IP protocols on DECnet' On 11/8/21 1:45 PM, Thomas DeBellis wrote: Nah...really, you need C for that. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Why, am I suddenly remembering GMAP, which has nothing to do with DEC? Zane

Oh ye, young in years and still so modern: 6809 was already a reincarnation. Real assembler was Pdp8, you could even die in it: Hlt ... :( Reindert -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: Tuesday, 09 November, 2021 00:33 To: hecnet at Update.UU.SE Subject: Re: [HECnet] "IP protocols on DECnet' Yes, PDP-11 of course, but sometimes they do it for the 6809! B-) -Dave On 11/8/21 5:53 PM, R. Voorhorst wrote: -- Dave McGuire, AK4HZ New Kensington, PA

Not really. Stream based protocols are protocols that do not rely on message boundaries -- more precisely, do not rely on boundaries being marked by lower layers. If you have a transport that does report message boundaries, and you want to carry a stream protocol, the simple answer is to ignore those boundaries. The reason I'm interested in how Ultrix did streaming sockets is because of the question "when do you send the message". That's actually a question with TCP as well, which is why it has a "no delay" option. The trivial answer is "for each send() call to the socket, send that data as a complete NSP message". That would obviously work; the only question is whether something fancier is a useful optimization. Actually, there might be one other question. Consider HTTP: if the server wants to send a file (say, a .jpg image) can it send the entire file as a single NSP message? From the DECnet architecture point of view, sure. Do DECnet implementations put some limit on the length of an NSP message? I don't know, except for RSTS which doesn't simply because it leaves segmentation and reassembly to the application. The mismatch that's harder to deal with is an application that needs message boundaries, running over a transport that doesn't have these. The TCP/IP world is full of these, and in every instance the application protocol concocts an ad-hoc solution to this issue. Consider iSCSI and NFS as two examples, with different solutions (or multiple solutions, if you take the "markers" hack in iSCSI seriously). paul

well... You know about the Nagle algorithm, right? Bob

Yes, that's what I was talking about. As for OSI not producing anything, that's not entirely true. OSPF is clearly derived from at early draft of IS-IS, however much its authors may want to hide that fact. The people in the DECnet architecture group (I was one, though junior) certainly went through a whole lot of hindsight review over the OSI vs. TCP history. It's always easy to say the right answer was obvious when you look back a decade or three later after everything was settled. At the time, it wasn't quite so obvious. The US centric vs. international thing is clearly a piece of the puzzle. Another piece is that, other than for academic and military use, the ARPAnet wasn't really available. Once it opened up for commercial use the matter was settled, but that didn't happen until later (around the time of the invention of the world wide web). So at the time Phase V was being created, the world had lots of small islands -- individual company in-house networks -- with very little interconnectivity among them. And in much of the world, what cross-company connectivity existed was, often by law, provided by phone companies. Those were very much invested in X.25 andd its various spawns. OSI was early on a generalization of X.25. The fact that it came to support datagram service, such as the TP-4 transport and connectionless network layer protocols like ISO 9542 (?) is in large part due to DEC pushing for it to be not quite so much "X.25 on steroids". That also tells us that DEC decided on a "help the Telcos make OSI not be so broken" rather than "ignore the telcos and do it some other way" which would have been hard to pull off outside the USA where it's telcos or nothing. (I remember a DEC Ethernet bridge with a Swedish telco approval sticker. It turned out that at the time in Sweden you could not run your own wiring between floors in your own office building: such cross-floor connectivity was the monopoly of the government telco.) Last but not least, Phase V was a long running effort. A few bits of it are visible in Phase IV (the weird stuff in the "long data header"). By the time I joined the DNA group in 1984 it was already well underway, but products didn't actually ship for several years afterwards. The landscape in 1983 was rather different from that of 1990. Data links had some of the same sort of stories. We now know that Ethernet beat everything else, but early on that wasn't so clear. The effort to defeat IBM token ring (802.5) took a long time. I helped write a long DEC document (40-60 pages?), the DEC-3Com reply to IBM Document xyz-nnn, a pile of FUD and baloney about the "superiority" of the IBM token ring. There was also 802.4, a GM contraption created because of the notion that Ethernet wasn't "real time" enough. 802.4 does have bounded latency that (half duplex) Ethernet doesn't, but the bounds are so high that it doesn't actuallly buy you anything. The only merit of 802.4 is that it is the foundation of FDDI. (No, FDDI has *nothing* to do with 802.5, other than the words "token" and "ring".) I still remember when we at DEC were busy building FDDI products and one of my colleagues (most likely the manager, Bill Hawe) asked somewhat tongue in cheek "could we just run Ethernet at FDDI speeds?". It didn't take more than a few hours to conclude that the answer is "yes". Even so, when that effort got underway, HP tried to wreck it by a bizarre 100 Mb/s vaguely Ethernet-like protocol. In the end that didn't go anywhere and regular Ethernet took over everywhere. paul

On 2021-11-08 17:09, Robert Armstrong wrote: Sadly nagle would not be possible to implement on a stream over DECnet, since it is interacting with the tcp acknowledgement of data. (Or at least I cannot see how you would do nagle in that environment.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

That?s basically what DECnet-Ultrix did although I seem to remember that if there is data waiting for initial transmiission we would merge the new data in with the old. DECnet-Ultrix was the first network implementation to make use of SOCK_SEQPACKET. There was crash causing bug whenever a read was issued on such a socket - the problem was a zero-day bug in the original BSD socket implementation At the time when DECnet-Ultrix was written, this was indeed the case. Newer versions os SOCK_SEQPACKET (e.g. Linux) include support for MSG_TRUNC and MSG_EOR so that an application can use a small buffer, overflow data will not be discarded and the user will be told that truncation has occurred. John.

On 11/8/21 11:05 AM, Paul Koning wrote: Ok, that's fantastic, how had I not heard of this? I need to find it and fire it up. Wow!! -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Once I got DECnet-Ultrix mostly working, I took the code down to the DEC offices for Project Athena at MIT. They built a version with DECnet support - the screen came up OK but moving the mouse around left pieces of random data on the screen. It became a very useful test tool. John.