-
Notifications
You must be signed in to change notification settings - Fork 267
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
Find route for messages #2656
Find route for messages #2656
Conversation
Codecov Report
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. @@ Coverage Diff @@
## master #2656 +/- ##
==========================================
+ Coverage 85.85% 85.93% +0.08%
==========================================
Files 214 215 +1
Lines 17591 17728 +137
Branches 723 752 +29
==========================================
+ Hits 15102 15235 +133
- Misses 2489 2493 +4
|
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.
This turned out more complex than I expected! I proposed some simplifications and refactorings in #2663. We're getting closer to an MVP release!
eclair-core/src/main/scala/fr/acinq/eclair/payment/send/OfferPayment.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/message/Postman.scala
Outdated
Show resolved
Hide resolved
eclair-core/src/main/scala/fr/acinq/eclair/message/Postman.scala
Outdated
Show resolved
Hide resolved
I've merged your improvements but kept a separate routing algorithm for messages and payments. Routing messages is too different to be solved by the current payment routing algorithm and I find it much simpler to separate the two than to try to make something generic. |
When sending a message, the postman can now ask the router to find a route using channels only. The same route is also used as a reply path when applicable.
3793e46
to
0547d8d
Compare
Now using Dijkstra for message routing too. We can prioritize big channels, old channels and penalize disabled edges (but still be able to consider them). |
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.
This looks mostly good to me, but it's hard to gauge the potential performance regressions, and this is quite a critical component...I didn't realize we'd need that much changes on the graph structure (but I agree that they make sense and are necessary). I think we should leave this PR out of the release, we should spend time testing it on our node before releasing it. We'll make the release first, and will merge this to master
right after the release and after your performance benchmarks.
eclair-core/src/main/scala/fr/acinq/eclair/message/Postman.scala
Outdated
Show resolved
Hide resolved
ActiveEdge and DisabledEdge extend GraphEdge
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.
Some benchmarks:
DirectedGraph.makeGraph
now takes 653ms instead of 225ms (x2.9)
.addEdges
now takes 356ms instead of 2.676s to update the whole graph (x0.13)
yenKshortestPaths
now takes 2.578s to find paths to the top 1000 nodes compared to 2.345s before (x1.1)
I don't think writing ad hoc code for DirectedGraph.makeGraph
is worth it as it only called once at start up.
It looks like storing edges in a map instead of a list costs us 10% on the path-finding side and brings a 10x improvement on the update side.
eclair-core/src/main/scala/fr/acinq/eclair/message/Postman.scala
Outdated
Show resolved
Hide resolved
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 code is looking good to me, that's really good work!
I'm going to spend more time on the benchmarks and I'll report early next week.
I'm finding the same results by tweaking your performance benchmarks. I think the additional 10% cost on path-finding is acceptable (even though it would be nice if we're able to improve that in the future), I'm a bit more frustrated at the |
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.
LGTM!
When sending a message, the postman can now ask the router to find a route using channels only. The same route is also used as a reply path when applicable.