2017-01-10 06:08:33 +01:00
|
|
|
#ifndef LIGHTNING_LIGHTNINGD_PEER_CONTROL_H
|
|
|
|
#define LIGHTNING_LIGHTNINGD_PEER_CONTROL_H
|
|
|
|
#include "config.h"
|
2017-01-10 06:08:33 +01:00
|
|
|
#include <ccan/compiler/compiler.h>
|
2017-06-20 07:51:03 +02:00
|
|
|
#include <ccan/crypto/shachain/shachain.h>
|
2017-04-01 12:24:59 +02:00
|
|
|
#include <ccan/list/list.h>
|
2017-08-28 18:05:01 +02:00
|
|
|
#include <common/channel_config.h>
|
2017-08-28 18:04:01 +02:00
|
|
|
#include <common/htlc.h>
|
|
|
|
#include <common/json.h>
|
2017-10-23 06:17:38 +02:00
|
|
|
#include <common/wireaddr.h>
|
2018-02-12 11:12:55 +01:00
|
|
|
#include <lightningd/channel.h>
|
2018-02-19 02:06:14 +01:00
|
|
|
#include <lightningd/channel_state.h>
|
2017-01-10 06:08:33 +01:00
|
|
|
#include <stdbool.h>
|
2017-07-19 16:55:47 +02:00
|
|
|
#include <wallet/wallet.h>
|
2017-06-27 04:55:01 +02:00
|
|
|
#include <wire/peer_wire.h>
|
2017-01-10 06:08:33 +01:00
|
|
|
|
2017-03-20 17:09:12 +01:00
|
|
|
#define ANNOUNCE_MIN_DEPTH 6
|
|
|
|
|
2017-02-24 06:52:56 +01:00
|
|
|
struct crypto_state;
|
|
|
|
|
2017-01-10 06:08:33 +01:00
|
|
|
struct peer {
|
2017-12-15 11:22:57 +01:00
|
|
|
/* Inside ld->peers. */
|
|
|
|
struct list_node list;
|
|
|
|
|
|
|
|
/* Master context */
|
2017-01-10 06:08:33 +01:00
|
|
|
struct lightningd *ld;
|
|
|
|
|
2017-08-14 22:06:59 +02:00
|
|
|
/* Database ID of the peer */
|
|
|
|
u64 dbid;
|
|
|
|
|
2017-06-06 05:08:42 +02:00
|
|
|
/* ID of peer */
|
|
|
|
struct pubkey id;
|
|
|
|
|
2018-02-12 11:12:55 +01:00
|
|
|
/* Our channels */
|
|
|
|
struct list_head channels;
|
2017-01-10 06:08:33 +01:00
|
|
|
|
2018-02-19 02:06:02 +01:00
|
|
|
/* Our (only) uncommitted channel, still opening. */
|
|
|
|
struct uncommitted_channel *uncommitted_channel;
|
|
|
|
|
2017-01-10 06:08:33 +01:00
|
|
|
/* History */
|
|
|
|
struct log_book *log_book;
|
|
|
|
|
2017-01-10 06:08:33 +01:00
|
|
|
/* Where we connected to, or it connected from. */
|
2017-10-23 06:17:38 +02:00
|
|
|
struct wireaddr addr;
|
2017-01-10 06:08:33 +01:00
|
|
|
|
2018-01-23 22:11:44 +01:00
|
|
|
/* If we open a channel our direction will be this */
|
|
|
|
u8 direction;
|
2017-01-10 06:08:33 +01:00
|
|
|
};
|
2017-01-10 06:08:33 +01:00
|
|
|
|
2018-02-12 11:12:55 +01:00
|
|
|
struct peer *find_peer_by_dbid(struct lightningd *ld, u64 dbid);
|
|
|
|
|
|
|
|
struct peer *new_peer(struct lightningd *ld, u64 dbid,
|
|
|
|
const struct pubkey *id,
|
|
|
|
const struct wireaddr *addr);
|
2017-05-22 13:24:59 +02:00
|
|
|
|
2018-02-14 02:53:04 +01:00
|
|
|
/* Also removes from db. */
|
|
|
|
void delete_peer(struct peer *peer);
|
|
|
|
|
2017-02-24 06:52:56 +01:00
|
|
|
struct peer *peer_by_id(struct lightningd *ld, const struct pubkey *id);
|
2017-04-01 12:24:59 +02:00
|
|
|
struct peer *peer_from_json(struct lightningd *ld,
|
|
|
|
const char *buffer,
|
|
|
|
jsmntok_t *peeridtok);
|
2017-02-24 06:52:56 +01:00
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-10-11 12:09:49 +02:00
|
|
|
/* The three ways peers enter from the network:
|
|
|
|
*
|
|
|
|
* peer_connected - when it first connects to gossipd (after init exchange).
|
|
|
|
* peer_sent_nongossip - when it tries to fund a channel.
|
|
|
|
* gossip_peer_released - when we tell gossipd to release it so we can fund
|
|
|
|
* a channel.
|
|
|
|
*/
|
|
|
|
void peer_connected(struct lightningd *ld, const u8 *msg,
|
|
|
|
int peer_fd, int gossip_fd);
|
|
|
|
|
2018-01-10 06:30:54 +01:00
|
|
|
/* This simply means we asked to reach a peer, but we already have it */
|
|
|
|
void peer_already_connected(struct lightningd *ld, const u8 *msg);
|
|
|
|
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-10-11 12:09:49 +02:00
|
|
|
void peer_sent_nongossip(struct lightningd *ld,
|
|
|
|
const struct pubkey *id,
|
2017-10-23 06:17:38 +02:00
|
|
|
const struct wireaddr *addr,
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-10-11 12:09:49 +02:00
|
|
|
const struct crypto_state *cs,
|
2017-12-11 04:33:16 +01:00
|
|
|
u64 gossip_index,
|
gossipd: rewrite to do the handshake internally.
Now the flow is much simpler from a lightningd POV:
1. If we want to connect to a peer, just send gossipd `gossipctl_reach_peer`.
2. Every new peer, gossipd hands up to lightningd, with global/local features
and the peer fd and a gossip fd using `gossip_peer_connected`
3. If lightningd doesn't want it, it just hands the peerfd and global/local
features back to gossipd using `gossipctl_handle_peer`
4. If a peer sends a non-gossip msg (eg `open_channel`) the gossipd sends
it up using `gossip_peer_nongossip`.
5. If lightningd wants to fund a channel, it simply calls `release_channel`.
Notes:
* There's no more "unique_id": we use the peer id.
* For the moment, we don't ask gossipd when we're told to list peers, so
connected peers without a channel don't appear in the JSON getpeers API.
* We add a `gossipctl_peer_addrhint` for the moment, so you can connect to
a specific ip/port, but using other sources is a TODO.
* We now (correctly) only give up on reaching a peer after we exchange init
messages, which changes the test_disconnect case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2017-10-11 12:09:49 +02:00
|
|
|
const u8 *gfeatures,
|
|
|
|
const u8 *lfeatures,
|
|
|
|
int peer_fd, int gossip_fd,
|
|
|
|
const u8 *in_msg);
|
2017-06-20 08:17:03 +02:00
|
|
|
|
2017-06-27 04:55:01 +02:00
|
|
|
/* Could be configurable. */
|
|
|
|
#define OUR_CHANNEL_FLAGS CHANNEL_FLAGS_ANNOUNCE_CHANNEL
|
|
|
|
|
2017-12-06 04:22:35 +01:00
|
|
|
/* Peer has failed to open; return to gossipd. */
|
|
|
|
void opening_failed(struct peer *peer, const u8 *msg TAKES);
|
|
|
|
|
2017-01-10 06:08:33 +01:00
|
|
|
void setup_listeners(struct lightningd *ld);
|
2017-11-10 03:01:10 +01:00
|
|
|
|
2018-01-03 06:26:44 +01:00
|
|
|
/* We've loaded peers from database, set them going. */
|
|
|
|
void activate_peers(struct lightningd *ld);
|
|
|
|
|
2018-02-12 11:13:04 +01:00
|
|
|
void drop_to_chain(struct lightningd *ld, struct channel *channel);
|
|
|
|
|
2018-02-12 11:13:04 +01:00
|
|
|
void free_htlcs(struct lightningd *ld, const struct channel *channel);
|
2018-01-16 10:24:46 +01:00
|
|
|
|
|
|
|
/* Get range of feerates to insist other side abide by for normal channels. */
|
|
|
|
u32 feerate_min(struct lightningd *ld);
|
|
|
|
u32 feerate_max(struct lightningd *ld);
|
|
|
|
|
2018-02-20 21:59:04 +01:00
|
|
|
bool peer_start_channeld(struct channel *channel,
|
|
|
|
const struct crypto_state *cs,
|
|
|
|
u64 gossip_index,
|
|
|
|
int peer_fd, int gossip_fd,
|
|
|
|
const u8 *funding_signed,
|
|
|
|
bool reconnected);
|
|
|
|
|
|
|
|
void channel_watch_funding(struct lightningd *ld, struct channel *channel);
|
2017-01-10 06:08:33 +01:00
|
|
|
#endif /* LIGHTNING_LIGHTNINGD_PEER_CONTROL_H */
|