HECnet

"Robert Armstrong" <bob at jfcl.com> wrote: And it's fun to interconnect different OSes and architectures. Since this question now has popped up, I thought I'd go through a few points of interest for those who want to know or join. First of all, yes, HECnet exists, works and have done so for a couple of years. But the interest have been very limited. I don't know why. Maybe because I don't frequent the right group of people. Same reason people tend to forget the ftp archive I have of PDP-11 software, which (in my eyes) is the better place to find atleast RSX stuff. :-) To begin with: HECnet is DECnet Phase IV, and nothing else. Anyway. HECnet started out as point-to-point connections using asynch serial DDCMP. This was because it was the easiest and most obvious way to solve this. Tunneling normal serial interface traffic is very easy. It was, however, limited by both by which OSes actually supported this (RSX and VMS afaik), the fact that you needed physical asynch interface on the machine, and the fact that this limited the network speed to 9600 bps. The next step was to tunnel ethernet instead. I wrote a small program running under Unix which does exactly that. It uses the berkley packet filter to get packets, and to send them as well. This means that an independent machine on the same ethernet segment is needed to do the tunneling. At the time I was doing this, I couldn't find any ready solution for this. I did look at GRE, but figured it cannot be used, since it requires the OS to atleast understand the packet in order to figure out that it should go on the GRE tunnel. DECnet is not understood by most Unix versions. Now, if I'm wrong, I'm all ears to implementing it. There also sometimes exist a bridge interface, which might be useful, but once again I haven't exactly been sure, so I've skipped it for now. My current bridge program have some flaws that are related to DECnet. First of all it don't learn where different MAC addresses are, to limit transmits. Second, you can decide which machines packets that are sent out on a bridge, but since it appears as one single ethernet segment, things can get wrong when one machine in one area wants to talk with a machine in another area, and wants to use the other areas router directly (since they have contact). This means that if you run an area router, you actually need to allow all machines to send traffic to anywhere. Some of these things are easy to improve, and I should probably address them. But since interest have been so low, the need hasn't exactly been acute. But maybe if this picks up. If you want to join HECnet, there are a few things we need to fix. First of all, we need the connection established. My machines are sitting at a site where I have very large bw, and no problems running 24/7. I have an area router, and another machine that acts as the bridge. So what you need is a machine to act as your endpoint of that bridge. It can either be a Unix machine, or something else, if we just get the connection going to some other host on HECnet. The requirements for my bridge software is really a machine that can send ethernet packets with anything as the source mac address, since that need to be faked. Most modern PCs can fake that, but I don't think SUN machines can. If you'd prefer to run something else than Unix, I'd be happy to help porting my bridge program. If you have a machine that actually can route DECnet over IP, it's in a way a better solution, but I can't deal with it right now. We'll have to start working on it. Let me know and we can talk. Second, since DECnet have addresses as well, this address database needs to be organized and allocated. For HECnet, I need to administer this. What I do is either allocate an area for someone who wants it, and then that area can be managed locally, or I can assign addresses from area 1, which I use myself. At the moment, only areas 1 and 11 have been spoken for. The node namespace in DECnet is flat, and while it's also local to every machine, it's nice to try to keep it uniform, so I prefer to keep track of node names, and have a master list locally, which people can copy names. The area router for area 1 is an RSX-11M-PLUS machine. There are actually several area routers on area 1. MAGICA:: is a real PDP-11/70 running RSX-11M-PLUS. MIM:: is an emulated PDP-11, running RSX-11M-PLUS. ERNIE:: is a real PDP-11/84 running RSX-11M-PLUS. PONDUS:: is a real PDP-11/83 running RSX-11M-PLUS. ERNIE and PONDUS are at my home, and since my ISP left me stranded I don't have any permanent connection to my home right now, so they are mostly offline. MAGICA is normally not on at the moment, because of budget problems. This leaves MIM. MIM is normally online and running. I have been experimenting (together with John Wilson, the author of E11) with MIM lately in some interesting new features, which unfortunately have left MIM without a working ethernet at times. However, if we're serious about this, I can always keep MIM running a bit more safe. There are about 20 machines in area 1, and about the same number in area 11, which is managed by Saku Setala in Finland. The machine running the bridge is normally always on as well, so even with MIM out of the loop, everything should work fine. If you have any questions, just write me. If you want to join, write me as well. We'll start by figuring out how to hook you up, and we'll also allocate nodes, or an area for you. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol