Difference between instance_control_port and shared_instance_port

[deavmi]

What is the difference? I am under the impression that shared_instance_port is what tools, like rnstatus as a basic example, use to communicate with the RNS daemon.

However, what is the control port then? Is it akin to I2P with SAM (or is it Bob?) where one port is to open a channel and then the other port is where you send that channel-encoded data.

[markqvist]

Sorry it took me a while to get back to this on @deavmi! Should have explained it in more detail earlier.

First of all, let's look at how RNS works when started on a given system:

• The first RNS instance that is brought up on a running system, whether by simply starting an application that needs Reticulum access, or by launching a system-wide RNS daemon like rnsd, Reticulum will initialise in local master mode.
• This means that this local master instance will initialise all required hardware and virtual interfaces, open serial ports, acquire network hardware devices, etc., etc. It will also handle the most of the actual transport/routing work on the system.
• Now, when another application or utility launches, that also need Reticulum connectivity, it is going to detect that a local master instance is already running on the system, and hence it will not try to open hardware resources such as serial ports and network cards. This would of course not work.
• So instead it detects that an already running RNS instance is available on shared_instance_port, and will just connect to that using the RNS-internal LocalInterface, as if it was any other Reticulum interface.
• It's important to note here, that each individual application actually runs it's own instance of Reticulum, and that they therefore do not have access to each others encryption keys, destination details and so on: The system-local, intra-application and master-to-application communication is itself running over Reticulum. There is no difference in practice to any other Reticulum communication; it is simply using the "hidden" LocalInterface to communicate over.
• Ideally, I hand wanted to implement this interface using UNIX domain sockets or shared memory, to completely avoid the need for TCP for the LocalInterface module, but since support for domain sockets is missing on some operating systems, and shared memory support is different on all, I opted for the universal method of simply using TCP sockets as the underlying carrier for intra-system communications. It may be carried by TCP, but it's still Reticulum all the way down ;)

Now, with all of that in mind, you can probably see, that the local interface was never meant for communicating across system borders. In fact, to do that, it's just as efficient, and much easier to simply use one of the other non-local interface modules. In your case of wanting to connect different Linux containers together, the easiest way is probably to just have the primary RNS Transport Instance running in one container offer a TCPServerInterface, that all the application-hosting containers can connect to. Setting that up in docker or similar should be very simple, since local port forwarding and such is easy to configure at container startup. In fact, I use this approach quite a bit myself.

As for monitoring connectivity status on each individual instance, you can just use the remote management capabilities of rnstatus and rnpath.

Which brings us to the final part of the question, the instance_control_port: This one is used as a mechanism to pass RPC calls between local client instances, and the master instance. For example for getting interface status, or dropping path table entries. Since only the actual master instance has access to the underlying hardware, any other running instances will need to ask the master instance for information about stuff like what interfaces are up or down. This is what the instance_control_port is used for.

You asked elsewhere about using the shared_instance_port for connecting different RNS instances running on separate systems (or separate containers, which by definition might not be a physically separate system, but separate enough to be deemed so in terms of Reticulum), and as you can probably see by now, this is not a good idea. They are actually running from different Reticulum config directories, and do not have access to the same file-system resources needed (transport identities, RPC keys, path tables, etc.) for this to function correctly. I'm sure you could get it set up to actually work with a lot of FS sync magic and stuff, but that would kind of defeat the purpose of putting them in separate containers anyways ;)

So the short story is, it's much better to just let them run separate instances, that are all connected to one "container exit node" providing connectivity out of the containerised environment. Or even add multiple different types of "exit nodes", that would work too, off course, and add redundancy. The possibilities are endless :)