Underlying communications for a remote call

Technical Discussion Concepts & Architecture
#1

I am trying to understand what communication takes place when a remote call is made from one node to another.

If I understand correctly the web socket exposed by the conductor is bound to the local network interface so is only accessible from the same local host for UI/client app.

I can’t find any documentation describing how a remote call is routed to the remote client and how a response is returned.

1 Like
#2

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)

1 Like
#3

Thanks for the info

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.

1 Like
#4

I see I see.

“Does that mean that there is an additional network port that needs to be publicly accessible.”

It depends :slight_smile: if you have a network/internet set up where you either

  1. have a static IP address, or
  2. 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.

Would love to see better docs about this myself!

1 Like
#5

Thanks for all the references, I should be able to figure out what I need to do from there.

2 Likes
#6

Thanks @Connoropolous this was useful!

2 Likes