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

@@ -2876,7 +2876,7 @@ class LightningDTests(BaseLightningDTests):
# Wait for l1 to notice
wait_for(lambda: not 'connected' in l1.rpc.listpeers()['peers'][0]['channels'][0])
# Now restart l1 and it should reload peers/channels from the DB
# Now restart l2 and it should reload peers/channels from the DB
l2.daemon.start()
wait_for(lambda: len(l2.rpc.listpeers()['peers']) == 1)