Uh oh!
There was an error while loading. Please reload this page.
Use NodeAddress everywhere instead of InetAddress - #2202
Conversation
t-bast
left a comment
There was a problem hiding this comment.
Nice change, this will also make it much easier to implement lightning/bolts#911
Also, in cluster mode all outgoing connections (including tor) are now made on the front.
Can you remind me why we previously couldn't resolve tor addresses on the front?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
codecov-commenter
commented
Mar 25, 2022
Codecov Report
@@ Coverage Diff @@## master #2202 +/- ##
==========================================
+ Coverage 83.86% 83.89% +0.02%
==========================================
Files 186 186 Lines 13940 13952 +12 Branches 580 590 +10 ==========================================
+ Hits 11691 11705 +14 + Misses 2249 2247 -2
|
There is no reason to use the version of guava targetting android anymore. Also `HostAndPort` was in beta in our current lib version. We now use guava's `InetAddresses.toUriString()` to format host string, instead of manually adding brackets. Reworked `NodeURI` tests: - less repetition with one single test and multiple `testCases` - focus on non-reg (no need to verify what we know we don't support)
pm47
commented
Mar 25, 2022
There is no real reason, except that a prerequisite was to move the tor gateway on a separate machine, which happened later. |
Uh oh!
There was an error while loading. Please reload this page.
This makes us control more strictly when and where name resolution happens, which is important in a security-hardened setup. The
InetAddressjdk class indeed does a lot of things behind the scenes, but now we restrict it to tcp-related classes likeClientandServer.Also, in cluster mode all outgoing connections (including tor) are now made on the front.