You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
connectd: don't stall peer reads when lightningd attaches no subd
When connectd reads a peer message whose channel_id has no attached
subd, it creates a subd with conn == NULL and sends connectd_peer_spoke
to lightningd, asking it to start up a subdaemon and respond with
connectd_peer_connect_subd and the file descriptor that should be
assigned to conn. While connectd is waiting for lightningd's response,
it stops reading *all* messages from the peer.
There were six cases in lightningd's handle_peer_spoke where lightningd
would fail to respond, so when those occurred connectd would end up
waiting indefinitely while never reading or responding to the peer's
messages. Essentially the connection would become a "zombie" until
either the next gossip flush (if any) or the ping timeout caused the
connection to be dropped.
Add a new connectd_peer_no_subd message for lightningd to send connectd
when it will not be creating a subdaemon, so connectd can then continue
servicing the connection as usual.
Notably the connectd_peer_no_subd message uses a new spoke_id to
uniquely identify the connectd_peer_spoke message that it is responding
to, since multiple connectd_peer_spoke messages may be in flight at a
time and because the channel_id (which is the more natural choice) can
be changed by connectd before lightningd's response is received, thereby
causing the wrong subd to be freed.
Fixes: #9369
Changelog-Fixed: connectd: no longer stop servicing a peer connection for ~80s when a channel fails.
0 commit comments