generally, nodes are connected already if they are both online / accessible network-wise to each other
given their connectedness, a remote call is just a targeted message sent, and reply received. there is a low-level protocol they built called Kitsune which is handling the routing and request/response structures.
at any time, you can find out which agents are currently connected to your node, by calling the admin api FullStateDump.
It can provide a list of connected peers
peers discover each other typically via a live bootstrap server kitsune_p2p_bootstrap - Rust
or they could also discover each other via little broadcast messages on a LAN (via MDNS)
If I understand correctly a conductor opens a port bound to the local network interface for a local UI to connect and an admin port.
Does that mean that there is an additional network port that needs to be publicly accessible.
I would need to control access to that port, do you know if there are any docs on general network configuration for holohchain apps. I have seen some references to firewall configs but not a single source on the topic of networking.
“Does that mean that there is an additional network port that needs to be publicly accessible.”
It depends if you have a network/internet set up where you either
have a static IP address, or
know how to do port forwarding at your router
then you may be able to support direct full P2P connections. That is, allow inbound connections.
If you can’t do either of those things, then connectivity wise you had best use a proxy service, which is just an encrypted passthrough server, configurable by the client and anybody can run one. Holo hosts a couple, but they’re easy to set up and technical folks in support of a community could host them. Peers then route traffic through the proxy.
You can see an example of a network config object, in the Holochain Launcher code here.
There’s a ‘bootstrap service’ that you can optionally set, for node discovery
There’s gossip_tuning_params for configuring how much data to sync with peers (arc size, and other intervals and stuff)
And then there’s the ‘transport config’. This could be one of many things in the future, for example, there’s the “Quic” protocol there right now, but they are working on WebRTC connections, and there could be bluetooth or other ones there as well.
You can see in the transport_config object things which could allow you to bind the networking process to any open (or a specific) port.