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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Direct connect for
OnionMessage
sending #2723Direct connect for
OnionMessage
sending #2723Changes from all commits
79f212b
8412e83
ddee928
17af8d5
1114c3c
b86f02a
ba2a822
06b05df
cfaa7f3
ae98517
36ecc8e
ce68f22
6ca81ff
e25af3e
210407e
89e630b
d46519b
0b83116
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe after async functions in traits are stabilized, we can add an async event processing method to
EventsProvider
with a default implementation 🤔 I'm just wondering if this could be a temporary workaround.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, possibly.
EventsProvider
is kinda weird in that up until now it never really needed to be a trait.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand the reason for this now? Can we not just add a
process_pending_events_async
method onOnionMessenger
just like we do forChannelManager
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BackgroundProcessor
gets theOnionMessenger
throughPeerManager
, which only knows it is something that implementsOnionMessageHandler
andEventsProvider
. If we instead passOnionMessenger
toBackgroundProcessor
, then we would need to add three more type parameters toBackgroundProcessor
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you end up going the event route vs having an "start opening a connection async" trait (or even just doing it via the onion message router)? I guess an event could let us reuse it later in
ChannelManager
to just tell the user to reconnect every time a peer disconnects we care about, rather than users having to poll that, but it does seem like a lot of indirection to get the needs-connection event out.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would require adding another parameterization for users to implement (i.e., either a new trait on
OnionMessenger
or one onDefaultMessageRotuer
), which would then need to bubble up to theSimple*
aliases.And since it needs to be async, the trait implementation wouldn't be enough. Users would need to write code to process connection requests in the background from what their trait enqueued. If we wrote some of this logic for them, then we'd need to do it for each language's IO layer. But that wouldn't fit well into any peer management logic that they may have (e.g., LDK Node's
PeerStore
).Seems much simpler just to surface an event for them so that no additional parameterization and processing code is needed, other than handling one more event variant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, fair, I guess. I think the current piping through of the needs-connected nodes is also a bit gross, but I'm not sure its more gross. One further thing to consider is what we want the eventual end state to be. If we want to to generate
ConnectionNeeded
events for peers with which we have a channel, we should stick with the event route (and probably start generating such events in the same release). If we don't, adding it via the router is easier to "walk back", and is at least only gross temporarily.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we pipe the needs-connect nodes through
OffersMessageHandler
/CustomOMHandler
with a new trait method? Then theChannelManager
could generateConnectionNeeded
events and we wouldn't have to trouble the background processor. I do see Jeff's argument that the current design aligns with the peer manager doing peer stuff though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... that wouldn't work for uses of
send_onion_message
or anyone using something other thanChannelManager
to implement one of those traits.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The custom trait implementations would need to support connecting to peers outbound, would it not work in some other way? I'm not convinced it's cleaner than the current approach though :/ just nicer in terms of the
PeerMan
/BgProcessor
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure that I follow. All custom implementations should work with the current approach of using
OnionMessenger
. Or are you saying a custom implementation ofOnionMessageHandler
(i.e., something other thanOnionMessenger
)? Note thatCustomOnionMessageHandler
andOffersMessageHandler
are specific toOnionMessenger
. Any implementations of those work fine with the current approach.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline. Updated to have events processed directly from any
OnionMessageHandler
by requiring implementations to also implementEventsProvider
. I was able to do so without adding another type parameter toBackgroundProcessor
since the handler can be fetched fromPeerManager
.