kad: Manually setting client or server mode

[dariusc93]

Description

Apart of #3877 was allowing the kad protocol to automatically select client or server mode based on if there is an external address, however there should be a function that would allow the node to override the automatic selection, specifically if the node wish to remain as a client and eventually be able to switch to being a server.

Motivation

Outlined in #3877 (comment), nodes may wish to only be a client and query nodes for records with the option to switch to being a server at a later point.

Another case may be in environments where it wouldnt be suitable to run in server mode (eg mobile or embedded environments, running on network with limited datacap, etc). With the current implementation, they would be forced into server mode unless the protocol itself is disabled, which may not be desirable, especially if the environment can change later on during runtime.

Open questions

1. When reimplementing Kademlia::set_mode, should it override any automatic detection that is done based on external address or should we have a configuration flag where you can use one or the other but not both?

Are you planning to do it yourself in a pull request?

Maybe

[thomaseizinger]

When reimplementing Kademlia::set_mode, should it override any automatic detection that is done based on external address or should we have a configuration flag where you can use one or the other but not both?

We could have set_explicit_mode(Option<Mode>) where None means "do it automatically".

[dariusc93]

When reimplementing Kademlia::set_mode, should it override any automatic detection that is done based on external address or should we have a configuration flag where you can use one or the other but not both?

We could have set_explicit_mode(Option<Mode>) where None means "do it automatically".

I actually like that idea.

[stormshield-pj50]

Maybe you could follow the go implementation that uses 3 modes:

• ModeAuto
• ModeClient
• ModeServer
• ModeAutoServer

[dariusc93]

Maybe you could follow the go implementation that uses 3 modes:

* ModeAuto

* ModeClient

* ModeServer

* ModeAutoServer

If we did follow the go implementation, would we even need ModeAutoServer?

[thomaseizinger]

Maybe you could follow the go implementation that uses 3 modes:

• ModeAuto
• ModeClient
• ModeServer
• ModeAutoServer

Minus ModeAutoServer that is essentially what I am proposing, but with a dedicated enum instead of composing Option.

I think I'd prefer composition because it keeps the ConnectionHandler unaware of how the mode is chosen.

[thomaseizinger]

I think the fact that we arrived at the same solution without looking at what go-libp2p does is a good validation.

[joshuef]

I'm continuing looking into upgrading to 0.52, and I think we're butting up against this. Our local testnets and CI machines, where we normally run ~30 nodes to validate basic functionality are not working as it seems every node is a `Client.

I just wanted to check if there's some other recommend way to setup these test networks so we can force Mode::Server? Or (i suspect) will we need to wait for resolution on this issue?

🙇

[mxinden]

I just wanted to check if there's some other recommend way to setup these test networks so we can force Mode::Server?

@joshuef calling Swarm::add_external_address will make sure your node runs in Mode::Server. See changelog entry.

https://github.com/libp2p/rust-libp2p/blob/master/protocols/kad/CHANGELOG.md#0440

[joshuef]

Awesome, that's got us going 💪 . Thanks very much 🙇

[dariusc93]

I'm continuing looking into upgrading to 0.52, and I think we're butting up against this. Our local testnets and CI machines, where we normally run ~30 nodes to validate basic functionality are not working as it seems every node is a `Client.

What i usually do to get around that would be to add the addresses produced by SwarmEvent::NewListenAddr and remove them with SwarmEvent::ExpiredListenAddr and SwarmEvent::ListenerClosed. Not preferable doing this though but in testing that will work fine

[thomaseizinger]

I'm continuing looking into upgrading to 0.52, and I think we're butting up against this. Our local testnets and CI machines, where we normally run ~30 nodes to validate basic functionality are not working as it seems every node is a `Client.

What i usually do to get around that would be to add the addresses produced by SwarmEvent::NewListenAddr and remove them with SwarmEvent::ExpiredListenAddr and SwarmEvent::ListenerClosed. Not preferable doing this though but in testing that will work fine

That is only correct if your local interface is in a fact routable from your other nodes, i.e. if you are in the same subnet.

Unless you are utilizing something like AutoNAT, it is likely better to just add a configuration option to your binary where users have to specify the public IP of the node and you statically add using Swarm::add_external_address.

[thomaseizinger]

Or (i suspect) will we need to wait for resolution on this issue?

There are no objections against this idea mentioned. Contributions implementing that are most certainly welcomed!

[vladlabs]

We are facing same issue as @joshuef. Kademlia related tests are now failing. BTW we are utilizing memory transport for such tests.

[thomaseizinger]

We are facing same issue as @joshuef. Kademlia related tests are now failing. BTW we are utilizing memory transport for such tests.

And the solution mentioned above does not work?

[vladlabs]

Well it helped. But this is not a good solution considering that in our code Swarm is incapsulated.

I personally do not like any auto configurations by default at all (especially if there is no obvious way to change such behavior).
Also I think that auto configs should be enabled only manually by calling some method like do_autoconfig_magic()

[thomaseizinger]

Well it helped.

Great to hear!

But this is not a good solution considering that in our code Swarm is incapsulated.

Can you elaborate why? Whether or not kademlia should operate in server-mode (i.e. answer inbound requests) literally depends on whether or not your node is publicly reachable and that is configured by Swarm::add_external_address (or using a system of libp2p-identify and libp2p-autonat). If your node is not reachable, it should not advertise kademlia, otherwise you'll poison the routing table of your peers! I don't follow why configuring the external address of a Swarm is not a good solution.

I personally do not like any auto configurations by default at all (especially if there is no obvious way to change such behavior). Also I think that auto configs should be enabled only manually by calling some method like do_autoconfig_magic()

I doubt you actually mean that. By that logic:

• Your phone shouldn't automatically change the timezone when you fly to another country
• Your AC shouldn't stop cooling once your room reaches the desired temperature
• Your car shouldn't turn the headlights on when you drive into a tunnel
• ...

Defaults matter, we just need to find the correct trigger for a behaviour. I am fairly certain that the presence of an external address is the correct trigger for kademlia server mode. And client-mode must be the default, otherwise your routing table will be full of unreachable peers and you'll have a terrible DHT performance.

There is already a proposal for a solution on how to force a particular mode. Contributions for that are highly welcome!