lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
9107 Commits
55 Branches
107 Tags
38 MiB
Tree: 5b3af00e28
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5b3af00e28'
${ noResults }
lightning/lightningd/opening_control.h

24 lines
639 B
Raw Normal View History

lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
7 years ago
#ifndef LIGHTNING_LIGHTNINGD_OPENING_CONTROL_H
#define LIGHTNING_LIGHTNINGD_OPENING_CONTROL_H
#include "config.h"
#include <ccan/short_types/short_types.h>
subd: Add a helper to get the current owning subd for a given peer This is currently in opening_control since that&#39;s the only part that has access to the uncommitted_channel internals. Otherwise it&#39;s independent from the specific daemon.
5 years ago
#include <lightningd/peer_control.h>
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
struct channel_id;
struct crypto_state;
Rename `struct json_result` to `struct json_stream` (RENAMEONLY) Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
struct json_stream;
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
struct lightningd;
common/per_per_state: generalize lightningd/peer_comm Part 1 Encapsulating the peer state was a win for lightningd; not surprisingly, it&#39;s even more of a win for the other daemons, especially as we want to add a little gossip information. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
struct per_peer_state;
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
struct uncommitted_channel;
Rename `struct json_result` to `struct json_stream` (RENAMEONLY) Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
void json_add_uncommitted_channel(struct json_stream *response,
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
const struct uncommitted_channel *uc);
openingd: take peer before we&#39;re opening, wait for explicit funding msg. Prior to this, lightningd would hand uninteresting peers back to connectd, which would then return it to lightningd if it sent a non-gossip msg, or if lightningd asked it to release the peer. Now connectd hands the peer to lightningd once we&#39;ve done the init handshake, which hands it off to openingd. This is a deep structural change, so we do the minimum here and cleanup in the following patches. Lightningd: 1. Remove peer_nongossip handling from connect_control and peer_control. 2. Remove list of outstanding fundchannel command; it was only needed to find the race between us asking connectd to release the peer and it reconnecting. 3. We can no longer tell if the remote end has started trying to fund a channel (until it has succeeded): it&#39;s very transitory anyway so not worth fixing. 4. We now always have a struct peer, and allocate an uncommitted_channel for it, though it may never be used if neither end funds a channel. 5. We start funding on messages for openingd: we can get a funder_reply or a fundee, or an error in response to our request to fund a channel. so we handle all of them. 6. A new peer_start_openingd() is called after connectd hands us a peer. 7. json_fund_channel just looks through local peers; there are none hidden in connectd any more. 8. We sometimes start a new openingd just to send an error message. Openingd: 1. We always have information we need to accept them funding a channel (in the init message). 2. We have to listen for three fds: peer, gossip and master, so we opencode the poll. 3. We have an explicit message to start trying to fund a channel. 4. We can be told to send a message in our init message. Testing: 1. We don&#39;t handle some things gracefully yet, so two tests are disabled. 2. &#39;hand_back_peer .*: now local again&#39; from connectd is no longer a message, openingd says &#39;Handed peer, entering loop&#39; once its managing it. 3. peer[&#39;state&#39;] used to be set to &#39;GOSSIPING&#39; (otherwise this field doesn&#39;t exist; &#39;state&#39; is now per-channel. It doesn&#39;t exist at all now. 4. Some tests now need to turn on IO logging in openingd, not connectd. 5. There&#39;s a gap between connecting on one node and having connectd on the peer hand over the connection to openingd. Our tests sometimes checked getpeers() on the peer, and didn&#39;t see anything, so line_graph needed updating. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
void peer_start_openingd(struct peer *peer,
common/per_per_state: generalize lightningd/peer_comm Part 1 Encapsulating the peer state was a win for lightningd; not surprisingly, it&#39;s even more of a win for the other daemons, especially as we want to add a little gossip information. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
struct per_peer_state *pps,
openingd: take peer before we&#39;re opening, wait for explicit funding msg. Prior to this, lightningd would hand uninteresting peers back to connectd, which would then return it to lightningd if it sent a non-gossip msg, or if lightningd asked it to release the peer. Now connectd hands the peer to lightningd once we&#39;ve done the init handshake, which hands it off to openingd. This is a deep structural change, so we do the minimum here and cleanup in the following patches. Lightningd: 1. Remove peer_nongossip handling from connect_control and peer_control. 2. Remove list of outstanding fundchannel command; it was only needed to find the race between us asking connectd to release the peer and it reconnecting. 3. We can no longer tell if the remote end has started trying to fund a channel (until it has succeeded): it&#39;s very transitory anyway so not worth fixing. 4. We now always have a struct peer, and allocate an uncommitted_channel for it, though it may never be used if neither end funds a channel. 5. We start funding on messages for openingd: we can get a funder_reply or a fundee, or an error in response to our request to fund a channel. so we handle all of them. 6. A new peer_start_openingd() is called after connectd hands us a peer. 7. json_fund_channel just looks through local peers; there are none hidden in connectd any more. 8. We sometimes start a new openingd just to send an error message. Openingd: 1. We always have information we need to accept them funding a channel (in the init message). 2. We have to listen for three fds: peer, gossip and master, so we opencode the poll. 3. We have an explicit message to start trying to fund a channel. 4. We can be told to send a message in our init message. Testing: 1. We don&#39;t handle some things gracefully yet, so two tests are disabled. 2. &#39;hand_back_peer .*: now local again&#39; from connectd is no longer a message, openingd says &#39;Handed peer, entering loop&#39; once its managing it. 3. peer[&#39;state&#39;] used to be set to &#39;GOSSIPING&#39; (otherwise this field doesn&#39;t exist; &#39;state&#39; is now per-channel. It doesn&#39;t exist at all now. 4. Some tests now need to turn on IO logging in openingd, not connectd. 5. There&#39;s a gap between connecting on one node and having connectd on the peer hand over the connection to openingd. Our tests sometimes checked getpeers() on the peer, and didn&#39;t see anything, so line_graph needed updating. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
const u8 *msg);
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
subd: Add a helper to get the current owning subd for a given peer This is currently in opening_control since that&#39;s the only part that has access to the uncommitted_channel internals. Otherwise it&#39;s independent from the specific daemon.
5 years ago
struct subd *peer_get_owning_subd(struct peer *peer);
lightningd/opening_control: routines to control openingd (move from peer_control.c) We also fold opening_got_hsm_funding_sig() into the caller; it was previously a callback before we decided to always use the HSM synchronously. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
#endif /* LIGHTNING_LIGHTNINGD_OPENING_CONTROL_H */