rcornwell
Kx10: Host-to-IMP interface supporting NCP
I have another cart to put before a horse: doing NCP from the IMP.
I'd like to hear your thoughts on this and discuss the options.
My primary interest is talking NCP directly to other hosts. Much like how we can speak Chaosnet now.
NCP can only talk to 256 hosts, Therefore it will require a mapping table. My thoughts on this are that IMP will package up the NCP packets into a UDP packet and send it to a gateway program. This program will handle ICP and translation to TCP. Also NCP sockets were unidirectional so the NCP daemon will have to de-multiplex the TCP connection.
256 IMPs (or thereabouts, dunno if 0 and/or 255 are special), and each IMP could have multiple hosts.
Host tables only had a single byte for host number so not sure how you could have more then 255 hosts. And several hosts were special for testing.
You're right. It was actually a 6-bit IMP number and a 2-bit host number. For example, MIT-MULTICS was IMP 6, host 0, or in octal 006. MIT-DM was IMP 6, host 1: 106. MIT-AI 206, and MIT-ML 306.
This was reflected in the transition to IP. The addresses became 10.0.0.6, 10.1.0.6, 10.2.0.6, and 10.3.0.6.
I took a look at Bob Armstrong's H316 IMP code in SIMH. If I understand correctly, it should be able to talk to a host through UDP. I emailed Bob asking for clarifications.
Adding a UDP mode for IMP would not be hard to do. IMP could also wrap packets up into UDP packets and send them out itself. All the logic for generating IP packets is in the code now.
Here's what Bob Armstrong says:
The simh IMP version simulates the host interface for the H-316 side, but currently it always pretends that the host is offline (powered down). I thought that someday somebody might want to make it talk to another simulator so I put hooks in there for an eventual connection to a host, but AFAIK you're the first one to actually do that. My assumption was that there would be some kind of TCP or UDP connection between the IMP simh and the host simh, but exactly how that would work is to be determined.
I'll be glad to help you if I can, and I might even be able to write the IMP side of the connection for you, time and schedule permitting.
I got a SIMH patch from @charlesUnixPro to add an IMP host interface to H316. It encapsulates 1822 messages in UDP packets.
CC @markpizz. Summary: at some point, I would like to see ITS hooked up to a simulated ARPANET.
I'm not sure what the functionality that is being implemented here.
As I understand it, Rich's kx10_imp.c imbeds what the simulated system more or less thinks is an connecction to a IMP. Where the IMP is effectively a what we think of today as a router.
As I understood things, the IMPs were implemented on H316 hardware with several point to point connections.
The existing H316 has what seems to be a stub IMP device which I don't understand the point of given the above "understandings", and it has a h316_udp.c module which implements MAXLINKS point to point connection between two systems that can make sense of the data being exchanged. This device actually uses TMXR to deliver UDP packets.
So, I don't understand how any of this has anything to do with Rich's IMP device.
At this point, the exact functionality or implementation is not decided.
kx10_imp.c currently only does TCP/IP through the IMP interface on the PDP-10 end, and Ethernet frames on the host end. The H316 simulator is not involved.
What I'm proposing is to add... something... to support the Arpanet NCP protocols. These also involves IMPs, but in a slightly different way. And of course the NCP protocols are mostly incompatible with TCP/IP.
Since people have already used the H316 simulator to run the IMP software and recreate an ARPA network, it would be possible to build on this. There is also Charle's patch to implement the host interface in H316. kx10_imp.c would have to be updated to talk to this host interface.
Another possibility would be to have kx10_imp.c talk directly to a peer, similar to how Chaosnet is implemented.
The existing logic provides an equivalent point to point device which would allow bot separate 'IMP H316' simulators to talk exchange packets via the h316_udp.c and if a 'Arpanet' capable host wanted to participate in these conversations, the kx10_imp could be slightly enhanced to be able to exchange packets with an H316 IMP via its h316_udp device. The kx10_imp already leverages sim_ether for packet transport and one of the transport options is UDP as a point to point circuit. kx10_imp would have to be enriched to just be a raw packet transport which really means side stepping much of the internal IP magic it currently is somewhat optionally doing.
I still don't get what the IMP device would be in the H316 simulator.
There's not exactly an IMP device in H316. There's HI (h316_hi.c) which is the host interface. It's currently an empty stub, but @charlesUnixPro's patch makes it talk UDP.
It should not be hard to modify the IMP device to just package up whatever the remote gives it and generate a UDP packet out of it. Same as inbound. Simh might already have this built in in the sim_ether device.
There's not exactly an IMP device in H316.
Look at line 104 of H316/h316_imp.c, you'll find a IMP device.
There's HI (h316_hi.c) which is the host interface. It's currently an empty stub, but @charlesUnixPro's patch makes it talk UDP.
The patch supplied is not a patch against the current code in the master branch. The H316 simulator code hasn't seen any changes in 6-7 years so that is surprising. A zip or tarball of the @charlesUnixPro's H316 working directory would be sufficient.
The current code in his patch seems to be trying to manage link speeds. The underlying TMXR layer which h316_udp.c is using should be used for that. This would remove complexity from that code.
In order to support NCP I am going to have to package up what the PDP10 is giving me and send it off to a server. Who would then convert it to TCP request. Problem is the NCP is very different from IP. The IMP managed socket allocation and endpoint management. You basically had a bunch of numbered hosts, 256 or 64k if I remember from the specs. These would have to be mapped into IP address by the NCP server. NCP support is useful for WAITS, since that is currently all the KA version supported. Implementing this with a network of simulators might be interesting.
kx10_imp.c could be configured to either directly encapsulate what it receives form the 10 into a UDP packet and send it out, or it could use read/write requests to send what it gets out. The IMP to host interface was basically a packet based protocol, each packet had a header on it telling the IMP what type of packet this was. When IP support was added, they just sent IP out as a packed. All the IMP device does is put a Ethernet header on the packet and send it out, or remove the Ethernet header when it receives a packet. The rest of the logic is to deal with routing of the IP packet to the correct remote host (i.e. correct MAC), and managing the fact that ITS IP address is fixed at system generation time. This allows the system to be set up on a more modern network with little fuss.
Oh, there's a h316_imp.c. No, I don't know what it does either, but supposedly some hardware the IMP software relies on.
I applied the patch with some manual intervention. I put it on a branch in my SIMH fork:
https://github.com/larsbrinkhoff/simh/commit/518f0e6510237498f514cf6806dd22e76fa45551
The host IMP implementation has been added to the H316 in the github.com/simh/simh master branch along with portability cleanup and an extra readme file which explains the things in the H316/tests directory. I don't know why that readme never made it there before.
The H316 host interface is very much like the Chaosnet implementation. In order for this to make it into the KA/KI/KL, the kx10_imp would have to be extended to have a new functionally different internal modes. This mode would talk the UDP wire protocol that the H316 imp speaks when it uses UDP for a transport. The kx10_imp could indeed leverage the UDP support in sim_ether, but it would have to encapsulate the UDP traffic in a compatible way to how the H316 currently does. The encapsulation includes a sequence number outside of the data to assure proper sequence arrival and duplicate avoidance.
This provides Arpanet between PDP10's, but the PDP10's would either be TCP capable as they are now with the kx10_imp or they could talk to each other across an Arpanet, but not both. If someone could find later versions of the IMP software, maybe some of this would be easier.
Thanks Mark! I wasn't expecting things to happen so quickly. For what it's worth, I talked to Bob Armstrong and he agreed the host interface should do in.
I'm keen on trying the host side, but Rich is busy getting the KL10 simulator into shape for merging. So it's probably best to wait until after that.
According to Bob, no other working IMP software version has been found. I'm not sure the 1973 version will accommodate TCP? I would expect it to have only 1822 short leaders, and I have a vague memory TCP requires long leaders.
I don't know what long or short leaders are. Napoleon was short, and Trump is somewhat tall, but I'm pretty sure this has nothing to do with them.
Can you elaborate about your view of leaders.
Of course. The original message protocol between the IMP and the host had a 32-bit "leader". This leader is just what we call header today. A later update extended this leader/header to 96 bits to accommodate more information.
I would guess that the size of the header is only a small part of the problem of converting protocols. Whatever "conversion" will be done will be invisible to the endpoints, so the headers that traffic starts with really won't matter. I'm sure that we're not dealing with a simple 1<->1 packet translation, but effectively independent conversations that happen to contain more or less the same data.
I'm not sure what conversation you mean. Rich has sometimes hinted he wanted NCP guests be able to talk to TCP hosts. This is why I added "(to IP gateway)" in the issue title. If this is what you mean, then yes, leader size is only a small part of that problem.
For me, this conversation is not important. I mostly want NCP guest operating systems to talk between each other.
@markpizz NCP is more like a TCP layer protocol. Sockets are managed by the IMP along with routing. Also NCP sockets are unidirectional rather then bi-directional. The even end was for sending data, the odd end for receiving. This is why inbound ports on TCP are odd.
What has not been decided is if I will have the IMP code wrap the packets from host into UDP packets and send the UDP packets it receives to the host. Or if I would use tmxr layer to send and receive UDP packets.
Hosts are limited to 256 or 64k hosts. So this implies that there will need to be some sort of mapping between NCP hosts and Internet IP addresses.
Also the IMP acted more like the socket layer in a modern system rather then just a transport layer like later versions of the IMP with just took packets and routed them.
@markpizz NCP is more like a TCP layer protocol. Sockets are managed by the IMP along with routing. Also NCP sockets are unidirectional rather then bi-directional. The even end was for sending data, the odd end for receiving. This is why inbound ports on TCP are odd.
I understood that this was significantly more complicated hence my reference to "converting" I meant "conversation converting".
What has not been decided is if I will have the IMP code wrap the packets from host into UDP packets and send the UDP packets it receives to the host. Or if I would use tmxr layer to send and receive UDP packets.
If all you've got to do is send UDP packets to a specific constant (configured) destination, then sim_ether's existing UDP packet transport could readily be used to talk to the current H316 IMP via its HI (Host Interface) device. All that would be necessary in this case would be to wrap the host provided packets in the UDP wire protocol that's being used in h316_udp.c.
Hosts are limited to 256 or 64k hosts. So this implies that there will need to be some sort of mapping between NCP hosts and Internet IP addresses.
That would absolutely be part of the above mention "conversation conversion".
Also the IMP acted more like the socket layer in a modern system rather then just a transport layer like later versions of the IMP with just took packets and routed them.
Hmm.. This suggests that the host<->imp traffic was "reliable", no? If so, the UDP paradigm isn't a great candidate. However it would be very easy to change the H316 tmxr implementation to just use TCP for its packet transport and thus get the required reliable connectivity. Given that, then kx10_imp would indeed need to use tmxr rather than sim_ether to deliver and receive data.
The link between host and IMP was reliable, I am not sure about the link between IMP's.
The point with kx10_imp.c is that I have a all the code in there to craft packets. So using sim_ether.c to deliver the packets is actually pretty easy. However it might require a second interface to actually do TMXR traffic. Possibly kx10_ncpimp.c or the like. Since it is most likely in this usage that the IMP simulator and the KA simulator would be running on the same host and local IP would probably be the best transport medium.
What I am not clear is how the virtual IMP's talk to each other. We would probably also want to implement a TIP to allow terminal login. This was an IMP with a bunch of terminals hung off it and no local host.