Feature Request: Expose PONG Message Metadata Associated with Sent PING Requests
Description
In the current implementation of the discv5 discovery library, it is not possible to retrieve the metadata from a received PONG message in association with a previously sent PING request. While PongHandler internally receives and processes the PONG packet, this is handled through externalAddressSelector.onExternalAddressReport(...) without preserving context about the original sender or request.
This makes it impossible to obtain important metadata from the PONG, such as:
recipientIPrecipientPortenrSeq
These fields are explicitly required by the Portal Network spec for validating PONG messages in response to a discv5_ping request. This limitation creates a gap for downstream clients like Samba, which depend on discv5 to fulfill the Portal Discovery protocol.
Proposed Change
Introduce a mechanism to expose PONG message metadata in association with the corresponding PING, ideally using one of the following approaches:
- Callback or listener for completed PINGs, receiving the decoded
Pong along with metadata (recipientIP, recipientPort, enrSeq).
- Public API exposing a
CompletableFuture<Pong> or similar structure when calling ping(...), allowing the response to be matched with the in-flight request.
Motivation
Implementing this feature would:
- Enable strict protocol compliance with the Portal Discovery spec.
- Improve observability of the handshake and peer discovery process.
- Allow better diagnostics of node reachability and NAT behavior.
- Facilitate client implementations that rely on accurate peer address discovery and validation.
Current Workaround
The current recommendation to use streamLiveNodes() or lookupNode() allows access to NodeRecord data, but not to the recipientIP and recipientPort as observed by the peer. These values cannot be retrieved after the PONG is processed o matched with the corresponding sender and original ping request.
Suggested Implementation Location
The functionality could be implemented in:
DiscoveryManager (to expose additional metadata),- or via a new listener interface registered on the
DiscoverySystem.
This enhancement would improve the utility and standards-compliance of the discv5 library and directly support critical infrastructure like the Portal Network. Thank you for considering this feature!
Since the future of the Portal Network remains uncertain, this feature might not be required if the protocol is no longer maintained.
Feature Request: Expose PONG Message Metadata Associated with Sent PING Requests
Description
In the current implementation of the
discv5discovery library, it is not possible to retrieve the metadata from a received PONG message in association with a previously sent PING request. WhilePongHandlerinternally receives and processes the PONG packet, this is handled throughexternalAddressSelector.onExternalAddressReport(...)without preserving context about the original sender or request.This makes it impossible to obtain important metadata from the PONG, such as:
recipientIPrecipientPortenrSeqThese fields are explicitly required by the Portal Network spec for validating PONG messages in response to a discv5_ping request. This limitation creates a gap for downstream clients like Samba, which depend on
discv5to fulfill the Portal Discovery protocol.Proposed Change
Introduce a mechanism to expose PONG message metadata in association with the corresponding PING, ideally using one of the following approaches:
Pongalong with metadata (recipientIP,recipientPort,enrSeq).CompletableFuture<Pong>or similar structure when callingping(...), allowing the response to be matched with the in-flight request.Motivation
Implementing this feature would:
Current Workaround
The current recommendation to use
streamLiveNodes()orlookupNode()allows access toNodeRecorddata, but not to therecipientIPandrecipientPortas observed by the peer. These values cannot be retrieved after the PONG is processed o matched with the corresponding sender and original ping request.Suggested Implementation Location
The functionality could be implemented in:
DiscoveryManager(to expose additional metadata),DiscoverySystem.This enhancement would improve the utility and standards-compliance of the
discv5library and directly support critical infrastructure like the Portal Network. Thank you for considering this feature!Since the future of the Portal Network remains uncertain, this feature might not be required if the protocol is no longer maintained.