[c-lightning] Splitting gossipd

Tue Jul 3 15:01:25 AEST 2018

Good morning c-lightningers,

I had a plan to propose something similar (`peerd`) which I hadn't fully fleshed out yet at this time (and had no code, so I was not going to propose it until I at least had some idea about how it would look like overall...).

My `peerd` plan seems slightly different in focus from the Rusty `connectd`, however.

In particular:

1.  `peerd` handles each peer connection, regardless of current channel state (no channel, `openingd`, `channeld`, or `closingd`).

2.  `peerd` has a socket to `gossipd`, a socket to `masterd`/`lightningd`, and a map of channel IDs to sockets to channel-level `openingd`/`channeld`/`closingd`.

3.  `peerd` keeps the cryptochannel state.  Messages to other daemons are unencrypted.  No more passing cryptochannel state between channel-level daemons.

4.  Each peer connection has its own `peerd`.  `gossipd` still handles incoming connections and outgoing connect attempts (and launches/causes `masterd` to launch a `peerd` to handle the connection from init onwards).

5.  `peerd` is at heart a very simple daemon.  Incoming gossip messages go to `gossipd`.  Incoming channel messages are looked up in the channel map (maps channel IDs to sockets) and forwarded to the socket connected to it.  The only message it has to parse is `funding_created`, which remaps the channel ID to a new channel ID; all other incoming messages from the peer are parsed only to determine the channel ID or to recognize if it is a gossip message.

6.  `peerd` just forwards whatever messages it receives from `gossipd` and any channel-level daemons to the peer.

The intent was to eventually let us form an architecture that would let us have multiple channels per peer, which while suboptimal is something that users seem to want to have...

It has the advantage that the `openingd` and `closingd` architectures do not need to change, and, the method of passing the socket from `openingd` to `channeld` to `closingd` will be almost exactly the same (the only difference, being, sending and receiving unencrypted messages, since, cryptochannel state is exclusively with `peerd`).

Major changes will be in `masterd` and `gossipd`, I think.  Channel-level `openingd`/`channeld`/`closingd` changes will only be removal of cryptochannel state.

I have not seen in detail the Rusty `connectd` plan, but it seems to be a singular daemon for all peers,

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On July 2, 2018 9:25 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> 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.
> 
> 
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> c-lightning mailing list
> 
> c-lightning at lists.ozlabs.org
> 
> https://lists.ozlabs.org/listinfo/c-lightning