[c-lightning] Splitting gossipd

[Rusty Russell]

Christian Decker <decker.christian at gmail.com> writes:
> Thanks Rusty for taking the lead here, this is a very much needed
> simplification of how we handle peer connections. Splitting out a
> `connectd` is definitely a good idea, also because it moves any code
> that is directly in contact with the peers into a separate binary and
> away from our global daemons.

Agreed.  Connectd still needs to do the crypto setup and the init
message send and read, but that's strictly ordered and has no real
branches, so is far easier to audit.

> Maybe we could even go a step further and merge all the daemons
> (`handshaked`, `openingd`, `channeld`, `closingd`) that handle the peer
> connection, into `channeld`. We've discussed this a few times before,
> but I think this would be a major simplification (there is only ever one
> owner, no hand-over between daemons of the peer fd, no need to drain
> message queues, ...), and it's much more in line with other projects
> that have separate workers, e.g., apache2, at a reasonable cost IMHO.

We could merge them, openingd and channeld are on fairly convenient
high-level fault lines, *and* their implementations don't overlap at
all.

For example, we don't touch the db until openingd returns: ie. until
that point, the peer is considered transient.

channeld and closingd have more in common: they both have to handle
retransmission for example, and they're basically identical from a
master POV.  But they're still very separate internally: once you're
in shutdown mode, the protocol is very different.

> This way we could move the listening socket back to the main daemon,
> which would then just take the peer fd, and fork off the `channeld` for
> that, using fd inheritance (which also simplifies alternative
> implementations since we don't need to use fd-passing as much.

Unfortunately, there's a lot of logic to do with connecting,
reconnecting, handshaking and init messages.  Isolating that into its
own daemon works well: the master just gets told when a new peer is
connected.

> We'd lose the simple synchronous nature of `openingd` and `closingd`,
> but I don't think that that's a major loss. Also I don't think that the
> flexibility argument to keep separate daemon applies here, since I don't
> really see us switching out `openingd` with a custom implementation for
> example.

My only counter-argument is that anything which takes code out of
channeld (a complex monster of a protocol) is good :)

But OTOH it's a fairly easy experiment to do, to see what it looks like.

Cheers,
Rusty.