Separate connection scheduler, dialer and address book

[mycognosist]

In the current iteration of the connection scheduler, the scheduler knows the public key and address of each peer to be dialed and the dialing is initiated from within the scheduler.

With the aim of eventually replacing the scheduler with a generic version that can be shared between projects, it may be best to limit the scheduler's knowledge to just the public key(s) and to execute the dialing from another actor. In this approach, the scheduler would simply emit an event to convey the message: "Please dial XYZ peer now", where XYZ is a public key in the case of solar. The dialer would listen for that message, query the address book to retrieve an address for the peer and execute the outbound dial attempt.

[mycognosist]

Thinking about a simple address book implementation...

I do like the simplicity of the current replication.toml approach. It's easy to edit the file directly, without any complicated formatting (just a key-value pair of "public_key" = "address"). It also has the property of allowing public keys to be added when an address is not known for the peer ("public_key" = ""); this allows replication on inbound connections from known peers with unknown addresses when selective replication is enabled.

For the sake of separating the scheduler, dialer and address book, it would be helpful to be able to retrieve an address for a given public key. The simplest implementation might be:

struct AddressBook(HashMap<PublicKey, Address>);

Eventually, we might want to support multiple addresses per public key (e.g. a hostname, a local IP and a yggdrasil IP). We would then require some logic to select or prioritise one address over another. Or we could simply dial each address in turn until a connection was successful.

Allowing multiple addresses per peer will require a rethinking of replication.toml.

[sandreae]

Hello 👋

Am right thinking peers in solar are always identified by hardcoded addresses? Or is there a discovery mechanism as well?

Eventually, we might want to support multiple addresses per public key (e.g. a hostname, a local IP and a yggdrasil IP). We would then require some logic to select or prioritise one address over another. Or we could simply dial each address in turn until a connection was successful.

This would be a really cool feature to support in the future!

[mycognosist]

@sandreae

Hey! 👋🏻

Am right thinking peers in solar are always identified by hardcoded addresses? Or is there a discovery mechanism as well?

That's correct. For now, addresses have to be provided for peers by the node operator. In the future I'd like to store addresses learned through inbound connections.

Scuttlebutt has historically used a PubAddress message type for nodes with a public IP to advertise their presence. Other nodes would then scan for these messages after / during replication and add the contents to the address book. If your replication distance was set to 2 hops or more, this would provide a means of learning about other accessible nodes via a "friend". I'm holding-off on implementing anything like this until I have a cleared use-case mapped out for solar.