feat(swarm): async network behavior #5698
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR drafts a generic async wrapper for network behaviors with asynchronous requests or queries (i.e. where the results for called methods are reported in swarm events).
It is inspired by #5294 and #5294 (comment).
The basic idea is:
Async
behavior wraps a network behavior and keeps track of pending requestsControl
interface commands can be sent to theAsync
behavior. The commands are mapped to methods of the inner network behavior.Async
Behavior intercepts out events from the inner behavior and returns them directly through a result channel if they are among the pending queries. Else they are bubbled up to the swarm as usual.The implementation is abstract over the inner network behavior, and only defines a trait
QueryMapper
that must be implemented for a network behavior. The goal is to have an async interface for all network behaviors that do any kind of long-running queries or requests.I added basic POC support for kademlia. I think it would also work well for request-response.
@jxs was that roughly what you had in mind in #5294 (comment)?
Notes & open questions
As a consequence of keeping
Async
generic and independent from a concrete behavior, there are no convenient async mirrors of the behavior methods (e.g.get_closest_peers_async
) like there is in #5294.Instead, there is just one method for sending the
Command
from the control, and the single result type for all commands needs to be mapped/ unwrapped by the caller. However, the unpacking of the result is also how it currently needs to be done when polling the result of a query from the swarm.Also, we could still add individual
Control
interfaces for the behaviors that wrap the genericControl
and provide convenience functions.Another alternative to the current trait design would be to use macros to generate async versions of a behavior.
Interested to hear what other folks think.
Change checklist