Update NodeAnnouncement address advertisement to match spec #131
Labels
beginner
Issues suitable for new developers
database
Related to the database/storage of LND
p2p
Code related to the peer-to-peer behaviour
routing
wire protocol
Encoding of messages for the communication between nodes
Milestone
Comments
|
Will take this one. |
bryanvu
added a commit
to bryanvu/lnd
that referenced
this issue
Mar 1, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue lightningnetwork#131 .
bryanvu
added a commit
to bryanvu/lnd
that referenced
this issue
Mar 3, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue lightningnetwork#131 .
bryanvu
added a commit
to bryanvu/lnd
that referenced
this issue
Mar 20, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue lightningnetwork#131 .
bryanvu
added a commit
to bryanvu/lnd
that referenced
this issue
Mar 22, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue lightningnetwork#131 .
bryanvu
added a commit
to bryanvu/lnd
that referenced
this issue
Mar 29, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue lightningnetwork#131 .
Roasbeef
pushed a commit
that referenced
this issue
Mar 29, 2017
This commit modifies address handling in the NodeAnnouncement struct, switching from net.TCPAddr to []net.Addr. This enables more flexible address handling with multiple types and multiple addresses for each node. This commit addresses the first part of issue #131 .
|
Closed by #154. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the
lnwire.NodeAnnouncementuses a recently dated format for communicating the reachable address of a particular node. Atm we assume that they're always encoding an IPv4 or IPv6 address within an IPv6 address. However, this is rather restricts as it means we can't signal hidden service addresses (both the current and next-gen version), or i2p address etc. A recent modification to the spec allows for a much more flexible format, which can be adapted to any new address types we'd like to advertise in the future.Additionally, the database (
channeldb.LightnignNode) should be updated to also store a variable number of address for a particular ndoe.Steps To Completion
Modify the
Addressfield within thelnwire.NodeAnnouncementstruct to instead be a more flexible[]net.AddrModify the encoding/decoding routine for
lnwire.NodeAnnouncementto use the format defined within the specification. Rather than packing in a single IPv6 address, it should now pack in an integer signaling the number of addresses, then induvidual pack in each known address with a byte prefix denoting the proper type.Modify the encoding/decoding routines for
channeldb.LightningNodeto also accept and update a variable amount of reachable addresses.Follow Up Tasks
Once the above has been completed, then the logic around the
connmgrshould also be updated to attempt to connect out to all advertised addresses. In the event that we're able to connect out or revive a connection from one of the advertise addresses, then all the gorourtines launched by theconnmgrto connect out to the directed node should be cancelled. This will require a modification to theconnmgrpackage withinbtcdto allow the cancellation of a connection attempt that didn't succeed. Currently one is only able to cancel a persistent connection attempt iff one was successful in the past.The text was updated successfully, but these errors were encountered: