Clean up message forwarding and relay gossip messages#948
Clean up message forwarding and relay gossip messages#948TheBlueMatt merged 8 commits intolightningdevkit:mainfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## main #948 +/- ##
==========================================
+ Coverage 90.58% 90.62% +0.03%
==========================================
Files 60 60
Lines 30423 30409 -14
==========================================
- Hits 27560 27559 -1
+ Misses 2863 2850 -13
Continue to review full report at Codecov.
|
|
is there a quick explanation why |
|
utACK |
Not that its superfluous, but that it violates the stated API of read handling not generating reentrant callbacks, see eae0904. |
|
I guess I'm asking if something else will kick off any writes that need to be sent out? |
Yes, the docs indicate you need to call |
| } | ||
| } | ||
|
|
||
| self.do_attempt_write_data(peer_descriptor, peer); |
There was a problem hiding this comment.
If you remember about it, what the initial purpose of this "write-just-after-read-in-case-of-reply" ? Save a call to process_events to the API user?
There was a problem hiding this comment.
Yea, just to be quicker about it - save an inertion into the peers_needing_send map and such. Its not all that critical unless the user only calls process_events in a loop and has some sleep we end up blocking on.
| } | ||
| if except_node.is_some() && peer.their_node_id.as_ref() == except_node { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
Should you include a non-replay-to-channel-update-broadcaster check as it's done for the 2 other gossips ?
There was a problem hiding this comment.
There is no node_id field in a channel_update, its assumed the network graph can figure it out from the short_channel_id.
| Ok(()) | ||
| } | ||
|
|
||
| fn forward_broadcast_msg(&self, peers: &mut PeerHolder<Descriptor>, msg: &wire::Message, except_node: Option<&PublicKey>) { |
There was a problem hiding this comment.
Presumably it could be used for any broadcast message? I like mentioning the word "broadcast" in it.
|
|
||
| /// When the outbound buffer has this many messages, we'll stop reading bytes from the peer until | ||
| /// we manage to send messages until we reach this limit. | ||
| const OUTBOUND_BUFFER_LIMIT_READ_PAUSE: usize = 10; |
There was a problem hiding this comment.
Shouldn't this constant call OUTBOUND_BUFFER_LIMIT_SYNC_PAUSE ? Otherwise, it's a bit confusing given it's called in do_attempt_write_data
There was a problem hiding this comment.
Hmm, its used for both, not sure which is better to focus on. I could just call it like OUTBOUND_BUFFER_LOW_WATER_MARK which is pretty normal for these types of constants, and document in the doccomment what its used for?
41bb42a to
72a668b
Compare
|
tested ACK |
We can never assume that messages were reliably delivered whether we placed them in the socket or not, so there isn't a lot of use in explicitly handling the case that a peer was not connected when we went to send it a message. Two TODOs are left for the generation of a `FundingAbandoned` (or similar) event, though it ultimately belongs in `ChannelManager`.
`Julian Knutsen <julianknutsen@users.noreply.github.com>` pointed out in a previous discussion that `read_event` can reenter user code despite the documentation stating explicitly that it will not. This was addressed in lightningdevkit#456 by simply codifying the reentrancy, but its somewhat simpler to just drop the `do_attempt_write_data` call. Ideally we could land most of Julian's work, but its still in need of substantial git history cleanup to get it in a reviewable state and this solves the immediate issue.
This will allow us to broadcast messages received in the next commit.
c505f07 to
0d374cf
Compare
|
Rebased to fix a trivial conflict and squashed fixup commits. |
0d374cf to
0d4fa0e
Compare
|
Addressed comments (with fixup commits and one new commit at the head). |
We do a lot of work to track which peers have buffers which need to be flushed, when we could instead just try to flush ever peer's buffer.
This avoids a now-unnecessary SocketDescriptor clone() call in addition to cleaning up the callsite code somewhat.
0d4fa0e to
895d1a8
Compare
|
Squashed with no changes. Changes since @devrandom's last ack are also trivial. Will merge after CI. |
While we really should eventually clean up some of the big PeerHandler refactors and merge them, this fixes a bit of low-hanging fruit in the mean time, also adding forwarding of gossip messages which @devrandom wanted.