Skip to content

nodes in key#237

Merged
lejeunerenard merged 8 commits intomainfrom
nodes-in-key
Apr 9, 2026
Merged

nodes in key#237
lejeunerenard merged 8 commits intomainfrom
nodes-in-key

Conversation

@Drache93
Copy link
Copy Markdown
Contributor

  • Add support for encoding closest nodes in key
  • flip order of providedNodes

@Drache93 Drache93 closed this Mar 1, 2026
@Drache93 Drache93 reopened this Mar 10, 2026
@Drache93
Copy link
Copy Markdown
Contributor Author

Have moved to using hyperdht-address @lejeunerenard

@Drache93 Drache93 requested a review from lejeunerenard March 10, 2026 22:15
* Use closestNodes to connect in parallel to findPeer query

Given `relayAddresses` (referred to as `closestNodes` in `dht-rpc`) are
passed when connecting, these nodes could be used to connect through
immediately while the normal `FIND_PEER` query is run. The closestNodes
are likely candidates for connecting to a specific peer so attempting
connection can speed up connection by skipping querying the DHT.

To accommodate the extra connection, the total connections allowed is
increased by 1 when closestNodes are passed. If a closestNode is
returned as part of the findPeer query, then connection is skipped
assuming that the preConnect parallel approach will establish the
connection.

* Add closestNode address to remoteRelayAddresses when attempting

In the same way that connectThroughNode may work for a node returned via
a `FIND_PEER` query, closestNodes attempted as part of preconnect should
also be tracked for caching.

* Add closestNode address to remoteRelayAddresses when attempting

In the same way that connectThroughNode may work for a node returned via
a `FIND_PEER` query, closestNodes attempted as part of preconnect should
also be tracked for caching.

* Check that `closestNodes` is set before skipping node in `FIND_PEER`

`preConnect` can be `true` while `closestNodes` is `null` when the
`closestNodes` were set initially but then cleared when the query makes
a second attempt.

* Filter out double `open` events in server side pool test

This test previously wasn't likely to emit two `open` events, but since
the pre-connect feature was added, if the client has the servers `id` in
it's cache and populates the `closestNodes` with it, it will immediately
connect to the server via the relay node simultaneously. This allows the
encrypted stream to `open` twice instead of the normal 1 time because
the connection to the relay has opened but the connection from the relay
to the server will error when a duplicate connection is detected.

* Split out logic to detect if `FIND_PEER` node is an existing `closestNode`

Moved to a function with a simple for loop instead of using `.find()`.

* Use `preConnect` bool to set number of semaphore waits

Without this check, 3 query nodes would attempt connecting at once if
`closestNodes` is an empty array. Pre-connnect wouldn't run so they
should be the same.

* Rename `closestNodes` to `relayAddresses` in `findAndConnect()`

Often `closestNodes` & `relayAddresses` are the same, but they are
distinct.

`closestNodes` are DHT nodes that are closest (via XOR metric) to the
target.

`relayAddresses` are nodes that will serve as the relay node for doing
the handshake with a given peer.
@lejeunerenard lejeunerenard merged commit f6ab3db into main Apr 9, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants