Skip to content

kad: Allow connecting to more than one DHT network#473

Merged
dmitry-markin merged 2 commits into
masterfrom
dm-multi-kad
Nov 19, 2025
Merged

kad: Allow connecting to more than one DHT network#473
dmitry-markin merged 2 commits into
masterfrom
dm-multi-kad

Conversation

@dmitry-markin
Copy link
Copy Markdown
Collaborator

Needed for IPFS support in substrate, because we need to connect to polkadot & IPFS DHTs simultaneously.

Close #471.

@dmitry-markin
Copy link
Copy Markdown
Collaborator Author

dmitry-markin commented Nov 13, 2025

I would like to release this as v0.12.1 (because the public API hasn't changed) and include into litep2p upgrade PR paritytech/polkadot-sdk#9685 in polkadot-sdk. UPD: or we can merge the litep2p upgrade PR now and later just bump litep2p with cargo update in polkadot-sdk.

let Some(actions) = self.pending_dials.remove(&peer) else {
entry.insert(PeerContext::new());
// Note that we do not add peer entry if we don't have any pending actions.
// This is done to not populate `self.peers` with peers that don't support
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dq: This won't affect networks with a single DHT started? Maybe we could add a trace here in case some issues popup in the future?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking outloud: If that's the case we could maybe add a new builder method on the KadConfig to signal we run in multi-dht-worlds? And return none only on multi-dht?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't affect a single DHT network, as the entry is always inserted anyway when substream is opened. Strictly speaking, it doesn't make sense to consider transport-level connected peers as connected, because they might not speak the Kademlia protocol (even in a single DHT case). We are interested in substreams over a specific protocol.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking outloud: If that's the case we could maybe add a new builder method on the KadConfig to signal we run in multi-dht-worlds? And return none only on multi-dht?

The logic shouldn't be different for a single DHT versus multi-DHT cases.

let pending_action = &mut self
.peers
.get_mut(&peer)
// If we opened an outbound substream, we must have pending actions for the peer.
Copy link
Copy Markdown
Collaborator

@lexnv lexnv Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we get in a race case here between the following timelines?

  • T0: Pending to open outbound substream
  • T1: Outbound opened and queue for reporting
  • T2: disconnect_peer - the peer is disconnected and reported
  • T3: Outbound opened reproted now

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might happen when there was an error reading inbound request at the same time as we sent an outbound request. The worst that can happen is we won't process pending actions for a peer, but this is not much different to an error during outbound request.

As a side note, the PR doesn't change the way this race can happen.

Copy link
Copy Markdown
Collaborator

@lexnv lexnv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@dmitry-markin dmitry-markin merged commit 643d4ff into master Nov 19, 2025
8 checks passed
@dmitry-markin dmitry-markin deleted the dm-multi-kad branch November 19, 2025 09:18
@github-project-automation github-project-automation Bot moved this to Blocked ⛔️ in Networking Nov 19, 2025
dmitry-markin added a commit that referenced this pull request Nov 21, 2025
## [0.12.1] - 2025-11-21

This release adds support for connecting to multiple Kademlia DHT
networks. The change is backward-compatible, no client code
modifications should be needed compared to v0.12.0.

### Changed

- kad: Allow connecting to more than one DHT network
([#473](#473))
- service: Log services that have closed
([#474](#474))

### Fixed

- update simple-dns
([#470](#470))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Blocked ⛔️

Development

Successfully merging this pull request may close these issues.

kad: Allow connecting to more than one DHT network simultaneously

2 participants