lightningd: split struct peer into struct peer and struct channel.

Much like the database; peer contains id, address, channel contains
per-channel information.  Where we create a channel, we always create
the peer too.

For the moment, peer->log and channel->log coexist side-by-side, to
reduce some of the churn.

Note that this changes the API to dev-forget-channel: if we have more
than one channel, we insist they specify the short-channel-id.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
2018-02-12 20:42:55 +10:30
committed by Christian Decker
parent 6b71654351
commit 32411de90e
15 changed files with 1287 additions and 915 deletions

View File

@@ -79,15 +79,19 @@ static void json_dev_ping(struct command *cmd,
/* First, see if it's in channeld. */
peer = peer_by_id(cmd->ld, &id);
if (peer) {
if (!peer->owner ||
!streq(peer->owner->name, "lightning_channeld")) {
struct channel *channel = peer_active_channel(peer);
if (!channel
|| !channel->owner
|| !streq(channel->owner->name, "lightning_channeld")) {
command_fail(cmd, "Peer in %s",
peer->owner
? peer->owner->name : "unattached");
channel && channel->owner
? channel->owner->name
: "unattached");
return;
}
msg = towire_channel_ping(cmd, pongbytes, len);
owner = peer->owner;
owner = channel->owner;
} else {
/* We assume it's in gossipd. */
msg = towire_gossip_ping(cmd, &id, pongbytes, len);