Kx10: Host-to-IMP interface supporting NCP

[larsbrinkhoff]

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.

[larsbrinkhoff]

My primary interest is talking NCP directly to other hosts. Much like how we can speak Chaosnet now.

[rcornwell]

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.

[larsbrinkhoff]

256 IMPs (or thereabouts, dunno if 0 and/or 255 are special), and each IMP could have multiple hosts.

[rcornwell]

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.

[larsbrinkhoff]

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.

[larsbrinkhoff]

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.

[rcornwell]

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.

[larsbrinkhoff]

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.

[larsbrinkhoff]

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.

[larsbrinkhoff]

Here's the patch. imp_fixes.txt

[larsbrinkhoff]

By the way, I call dibs on IMP number 6!

[markpizz]

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.

[larsbrinkhoff]

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.

[markpizz]

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.

[larsbrinkhoff]

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.

[rcornwell]

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.

[markpizz]

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.

[rcornwell]

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.

[larsbrinkhoff]

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.

[larsbrinkhoff]

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

[larsbrinkhoff]

It compiles, but I didn't try to test it.

[markpizz]

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.

[larsbrinkhoff]

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.

[markpizz]

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.

[larsbrinkhoff]

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.

[markpizz]

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.

[larsbrinkhoff]

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.

[rcornwell]

@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]

@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.

[rcornwell]

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.

[larsbrinkhoff]

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.

If you want an NCP host to talk to an IP host. I'm mostly interested in talking between NCP hosts.

What I am not clear is how the virtual IMP's talk to each other.

Using UDP.

[larsbrinkhoff]

This suggests that the host<->imp traffic was "reliable", no? If so, the UDP paradigm isn't a great candidate.

The rationale to use UDP between IMPs is explained in h316_udp.c, and has to do with timing. I'm not sure if the same goes for the host interface.

[markpizz]

I think I saw somewhere that the IMP to IMP links (using the Modem devices MI) use the h316_udp.c and do indeed worry about timing in the IMP software logic and that logic solves the reliability concerns. I think I saw somewhere that the link speed was 56K. I think I saw in the same place that the host to IMP link speed was either 100K or 1M.

The IMP software specifically handles the fact that the modem links were unreliable and dealt with the various recovery scenarios. I don't think the same burden is on the host links or the software in the host would be more complicated.

Charles used the existing h316_udp for transport of the host links since it was already there and worked for the modems. I'm not sure he actually considered the reliability question. Reliability could easily be achieved with by minor changes to h316_udp to actually use TCP vs UDP as the transport. The invoking code wouldn't need to know that all links were reliable.

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.

Was a TIP a direct wired/dialup-modem connection into an IMP? The first terminal server... Maybe that's what h316_imp.c is an unfinished placeholder for. Maybe Bob Armstrong could explain if the available IMP software actually knows how to do this. The file H316/tests/c-listing-ps.txt is an assembler listing of the available IMP software.

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.

I like the idea of a separate device module which were slightly aware of each other. Slightly aware only to assure that at most one of the devices in kx10_ncpimp.c and kx10_imp.c was enabled at any time. The PDP11 has two completely different devices which behave like this (pdp11_dl and pdp11_td). Both emulate programatic DL11's, but pdp11_dl is a terminal mux and pdp11_td is a TU58 tape controller which was connected to host systems via DL serial ports.

[rcornwell]

If we are doing a separate device I we should also add in the ability for this device to connect via TUN to allow those who operate KA/KL simulator on a system where they do not access to a TAP device to not have to use the complex Slirp interface.

More thought, I am not sure I would want to have IMP wrap packets into TCP, since this requires much more overhead in terms of tracking the packets. UDP I can just send the command and not worry about tracking the position and having to do the re-transmit if I don't receive a ACK in time.

KA10 already has code in it to detect duplicate devices. If a second device with same address of IMP were to be added, you could not start the simulator. At entry to sim_instr, sim_devices is scanned and all devices are added into a table of devices. This means that the I/O instructions don't have to go do a lookup of whether there is a device there or not, or which device should be used.

[markpizz]

More thought, I am not sure I would want to have IMP wrap packets into TCP, since this requires much more overhead in terms of tracking the packets. UDP I can just send the command and not worry about tracking the position and having to do the re-transmit if I don't receive a ACK in time.

There is no need for wrapping or tracking the packets. The device connecting a KL to an H316 IMP simulator's HI device is a point to point device. It is therefore an perfect candidate to leverage the TMXR packet interface. This interface will take the NCP packets and deliver them as packets reliably on the other end of the connection. UDP was added as an option for this type of connection in the TMXR layer because some point to point simulated network devices were fully capable of handling corrupted or missing packets since the higher level network stacks accommodated this. A trivial change (one line) under the covers in h316_udp can change the transport from UDP to TCP. The calling program need know nothing about it. A slightly more complicated change would be to make UDP/TCP an option passed at attach time which could then allow the H316 MI devices to continue to use UDP since they can tolerate packet loss and the H316 HI devices to use TCP for reliability.

We should also add in the ability for this device to connect via TUN to allow those who operate KA/KL simulator on a system where they do not access to a TAP device to not have to use the complex Slirp interface.

We're mixing device types here. Slirp is only an option on an Ethernet connection.

As for providing tun. I admit I dropped the ball a while back when working with Eric Swenson's situation. As you know, my primary environment is Windows, and except for a Mac Mini I've got for testing, I do all my alternate OS (Linux and others) in VMs. I therefore couldn't precisely replicate his environment since the VM's place in the network isn't precisely equivalent to a user's computer. Last night I installed Ubuntu 19.10 on an older PC system, so now I've got something sitting there that can completely replicate a user's experience, I stand behind the basic idea that having a TUN or TAP setup should essentially be no different on the host system side. Any system that has either has both. What we really need is some detailed instructions and possibly some platform specific scripts that can handle/simplify the setup.

I recently joined the PiDP11 discussion group and now appreciate even more the fact that the vast majority of users just want the simulation environment and it's connection to the various pieces of the outside world to "work!" so that they can get on with playing with what is going on within the simulators. Host environment setup is a complete bother to them.

[rcornwell]

Wrapping IMP data into UDP packets and shoving them out the ethernet port is a small change to the current IMP code. Converting IMP code to use TMXR is not a small change, but pretty much a complete rewrite.

I added a small blurb into my KA10/KI/KL docs describing methods of configuring IMP, it might be a good start for documentation. One problem with TUN is that it does not support FTP.

Most of the users of my simulators just want to relive previous usage of a machine, run an old program, or play admin on machine they used before. Also some what to just experiment with older systems. A small number of my users what to actually do development work on a simulator. Even fewer want to bug hunt problems. So the vast majority of users just want to install a simulator, grab a software kit and run it, they do this for a couple days and move on. This is one of the reasons I am providing build packages for my simulators so that users can run the script to generate a working system, it also documents the process of installing the system so that in future people can just look at that to see how it was done.

[markpizz]

Wrapping IMP data into UDP packets and shoving them out the ethernet port is a small change to the current IMP code. Converting IMP code to use TMXR is not a small change, but pretty much a complete rewrite.

You suggested a kx10_ncpimp.c device. It is this device I'm suggesting use TMXR and it should really only be the equivalent of a wire connection between the 10 and a H316 IMP. Yes, this would be a complete rewrite, but it should be no more complicated than @larsbrinkhoff's ChaosNet devices. The interface talking to the 10 can be readily captured from the existing kx10_imp.c and the transport to the H316 IMP exists in h316_udp. All of the other very complicated, very powerful things you have in the kx10_imp should not be part of the problem. I suspect that @larsbrinkhoff might be the man for this job... :-)

I added a small blurb into my KA10/KI/KL docs describing methods of configuring IMP, it might be a good start for documentation.

Sounds good.

One problem with TUN is that it does not support FTP.

That shouldn't be the case. I'd have to understand the particular network topology to understand where/why this doesn't work and address the issue.

Most of the users of my simulators just want to relive previous usage of a machine, run an old program, or play admin on machine they used before.

I'd say that was true of most users of any simh simulator. :-)

Also some what to just experiment with older systems. A small number of my users what to actually do development work on a simulator. Even fewer want to bug hunt problems. So the vast majority of users just want to install a simulator, grab a software kit and run it, they do this for a couple days and move on.

I agree completely. For the older simulators that weren't connected to the outside world with networking, this is much simpler.

This is one of the reasons I am providing build packages for my simulators so that users can run the script to generate a working system, it also documents the process of installing the system so that in future people can just look at that to see how it was done.

I agree the more things that can be automated the better the novice user experience will be.

[rcornwell]

Doing a TMXR IMP device should also be able to got on the local network with TCP. This is what Lars originally intended to do.

TUN does not support FTP because Slirp does not support FTP. For FTP to work you need to detect the PORT command and rewrite it and then redirect a second port. Which means you have to adjust the sequence number since these are based on byte offsets. Check out lines 1073-1131 and 1307-1365 for how to redo the packet and update checksums. Also 1284-1305 deals with inbound sequence numbers.

[markpizz]

Doing a TMXR IMP device should also be able to got on the local network with TCP. This is what Lars originally intended to do.

Actually his second comment in this discussion was:

@larsbrinkhoff >My primary interest is talking NCP directly to other hosts. Much like how we can speak Chaosnet now.

This suggests to me that the various nodes/simulators in the picture happen to transport data internally across the abilities of the local networking environment, but it suggests nothing about the nodes talking to other systems that are not H316-IMP/NCP connected.

TUN does not support FTP because Slirp does not support FTP.

I don't understand what you're referring to. Where does TUN come into the configuration. sim_ether supports TAP.

[rcornwell]

By original I mean Lars's original concept for the IMP device. He wanted it to function similar to the KLH10 network interface. I rejected this idea since it means that ITS is really only addressable at specific ports on the host system. Putting a network stack in the IMP device allows for more flexibility in setup. However with this flexibility comes complexity.

Sim_ether also supports the NAT interface which is basically equivalent to a TUN connection.

[markpizz]

By original I mean Lars's original concept for the IMP device. He wanted it to function similar to the KLH10 network interface.

Well, you solved the IMP in a reasonable way as a gateway to the internet for systems that were only capable of talking TCP through an IMP device.

Meanwhile, separately you've now got the NIA20 essentially done, so that would seem to be the more generic network interface for the KL10. I'm not familiar with other networking facilities that the KLH10 may have provided. What were these?

Sim_ether also supports the NAT interface which is basically equivalent to a TUN connection.

TUN is basically equivalent to TAP. It is only a point-to-point connection, but otherwise equivalent. TUN requires the other end of the TUN connection to actively route traffic if it is destined beyond the specific other end of the connection. Nowhere is any packet translation going on.

NAT is active translation of all traffic that maps ports on one side of the NAT connection to usually different ports on the other side of the connection.

I don't see NAT and TUN/TAP are in any way equivalent.

[rcornwell]

Yes I solved the IMP connection with what I had available.

I am not sure of others, however ITS does not support the NIA20, and Tops10 does not support the IMP, not sure about Tops 20, it might. But finding documents on Tops 20 networking is almost impossible.

I believe KLH sets up a TUN to TUN tunnel on the same host. It requires an IP address for the NIA interface.

You are correct about NAT, however NAT does not map FTP connections! At least to older operating systems. Newer systems support single port FTP which means they would work without a problem.

NAT and TAP are not equivalent, TUN and TAP are not equivalent. TUN sends IP packets between endpoints. TAP presents a virtual network interface to the program. NAT (simh slirp) generates a mini virtual network between the local host and the emulated host.

[larsbrinkhoff]

Doing a TMXR IMP device should also be able to got on the local network with TCP. This is what Lars originally intended to do.

Yes, I was aiming for that with the TCP capable IMP device. But for the NCP protocols, I don't see a great need for them to interact with TCP. I consider them much like the Chaosnet, a network in isolation.

[larsbrinkhoff]

He wanted it to function similar to the KLH10 network interface. I rejected this idea since it means that ITS is really only addressable at specific ports on the host system.

This is not true for KLH10. Using TUN, it has an IP number of its own and a full range of ports. It can use a dedicated network card.

[rcornwell]

@larsbrinkhoff I thought you wanted IMP to work either as a TAP type interface or as a TUN type interface. To the best of my knowledge a TUN is just the end point of a tunnel, I am not sure if it has an IP address or not.

[larsbrinkhoff]

I did, when the goal was to have TCP/IP networking. As far as I understand from using KLH10, TUN does have an IP address.

With NCP networking, I'd rather have another mode of IMP operation that works more like Chaosnet. It would just have to talk to the H316 simulator host interface.

[markpizz]

@rcornwell your IMP device is an oddball case since it embraces all the functionality of a host interface as well as a router and a gateway to the rest of the world. You created the need for it to be a TAP device with this additional functionality.

@larsbrinkhoff I thought you wanted IMP to work either as a TAP type interface or as a TUN type interface.

The kx10_ncpimp.c would only "need" to have a TUN type interface IF the sending system transporting data through it was transporting IP packets and it wanted to talk to other things inside the same host system. If it is used to transport NCP packets only to H316 IMPs, then TMXR works generically. It would seem that the current kx10_imp completely solves the need for IP through an IMP device on a 10 system.

The desire for TUN comes from users who are currently running KLH10 and want the simh simulator to be a drop in replacement for what they're already doing. They've already jumped through the host network configuration hoops (and possible host kernel changes) described in the very good write-up Kenneth L. Harrenstien did which is visible here: https://github.com/PDP-10/klh10/blob/master/doc/install.txt The relevant parts of that write-up are the sections about the NIA20 and the IMP. As I said previously, we need to document all the details needed to get this stuff working on modern systems. Much if Ken's info is relevant (and already stated in simh docs addressing many of the same issues), more is needed. Those asking for TUN would be equally happy with simh's TAP if we have precise documentation and/or scripts to solve what KLH10's IMP did with TUNs.

Everything on an original H316 IMP was the logical equivalent of direct wired connection (possibly across modems). The modem connections between IMP could naturally be tunnels and could use TUN for multiple instances running within a host, or if the host stack, in theory had a "rich" TUN capability that could transport TUN traffic to a distant node, Since I've only seen "rich" tunnel facilities inside non consumer class routers and not on host systems, TCP or UDP is the best transport for those connections.

To the best of my knowledge a TUN is just the end point of a tunnel, I am not sure if it has an IP address or not.

A tunnel is a point to point connection. The router world would potentially provide for separate IP addresses on each end of such a connection so that those managing the routed network could talk to each end of the wires in the network to confirm connectivity independent of users beyond the ends of the wires. If you aren't worried about talking to the ends of the wires, the routing tables actually contain interfaces and info about what addresses are reachable across each interface. The routing table can simply say that one address aa.bb.cc.dd/32 is reachable across a particular interface, so a host across a TUN could use IP address aa.bb.cc.dd. The same should also be true for a single host TAP connection.

@larsbrinkhoff just said:

I did, when the goal was to have TCP/IP networking. As far as I understand from using KLH10, TUN does have an IP address.

It does have an IP address which the configured 10 operating systems is aware of and the host OS is aware of. The device merely passes packets as data.

The current kx10_imp solves the TCP/IP networking now. We just need to describe or provide automation via scripts to achieve the equivalent functionality. My reading of the KLH10 install document now identifies that on many systems it describes specific setup details that are made to the system configuration so that the simulator can leverage the network functionality. The user's may have indeed done this when they first setup things and then forgotten those details which they only needed to think about one time.

With NCP networking, I'd rather have another mode of IMP operation that works more like Chaosnet.

Which is why a separate kx10_ncdimp.c device would solve the problem.

It would just have to talk to the H316 simulator host interface.

Which does that using TMXR.

[rcornwell]

@markpizz I really could not think of any way to do the IMP interface than the way I did it. TUN interface like Lars originally proposed would have only worked for Telnet. Also it would most likely have been just some ports on the local host. KLH10 is not very portable in how it configures the network. We also have the requirement to support windows.

The most accurately simulate the NCP IMP is via a TCP connection, since it was a reliable link between Host and IMP. IMP can talk to other IMP's over UDP or TCP. Also there will be very little logic in the ncpimp interface since it will just pass what it receives over to the IMP and whatever the IMP sends it to the host.

For NIA TAP was the most suitable interface since it is 100% an ethernet device, just like the DEQUNA/DELUNA.

I am all for a separate device, I think it should talk to the H316 simulator over TCP. Chaosnet protocol was by itself unreliable, so ITS/Tops20 has to deal with lost packet. There were no lost packets between host and IMP. While this could be done in the current IMP code it would add a huge amount of overhead that is not really needed.

The KA10 simulator can already support multiple devices at the same address and not allow the simulation to start until the condition is fix.

In terms of schedule, I think priority is to get III display working and do verification of the current merged system and push it to the main simH tree. The NCPIMP driver can be added later.

[eswenson1]

I confess I know very little about networking, but have to dispute the statement, above, regarding TUN only working for TELNET. I’m assuming you meant that FTP wouldn’t work. I regularly use FTP with my ITS running under KLH10 and leveraging a trivial to set up TUN interface. I was never able to get FTP to work with the TAP interface of the SIMH-based KA10 or KL10.

[eswenson1]

In rereading what rcornwell wrote, perhaps he was just referring to the proposed way (by Lars) of implementing the TUN interface...and not making a more general claim about TUN’s only being able to support TELNET.