vincenzopalazzo
/
rgb-cln
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
rgb-cln/lightningd/connect_control.h

17 lines
551 B
C
Raw Normal View History

lightningd/connect_control: routines to control connecting (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 20:59:09 +00:00
#ifndef LIGHTNING_LIGHTNINGD_CONNECT_CONTROL_H
#define LIGHTNING_LIGHTNINGD_CONNECT_CONTROL_H
#include "config.h"
struct lightningd;
struct pubkey;
gossipd: take connectd fd on initialization. connectd has a dedicated fd to gossipd, so it can ask for a new gossip_fd for a peer. gossipd has a standalone routine to create a remote peer (this will eventually be the only way gossipd creates a new peer). For now lightningd creates a socketpair but doesn't run connectd, so gossipd never sees any requests on this fd. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-07-24 07:18:58 +01:00
/* Returns fd for gossipd to talk to connectd */
int connectd_init(struct lightningd *ld);
gossipd: remove connectd functionality, enable connectd. This patch guts gossipd of all peer-related functionality, and hands all the peer-related requests to channeld instead. gossipd now gets the final announcable addresses in its init msg, since it doesn't handle socket binding any more. lightningd now actually starts connectd, and activates it. The init messages for both gossipd and connectd still contain redundant fields which need cleaning up. There are shims to handle the fact that connectd's wire messages are still (mostly) gossipd messages. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-07-24 07:18:58 +01:00
void connectd_activate(struct lightningd *ld);
connectd: rely on the master to tell us to reconnect. connectd tells master about every disconnection, and master knows whether it's important to reconnect. Just get the master to invoke a new connect command if it considers the peer important! The only twist is timeouts: we don't want to immediately reconnect if we've failed to connect. To solve this, connectd passes a 'delaytime' to the master when a connection fails, and the master passes it back when it asks for a connection. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-09 01:25:29 +01:00
void delay_then_reconnect(struct channel *channel, u32 seconds_delay);
connectd: always tell master when connection fails/succeeded. We used to separate implicit connection requests (ie. timed retries for important peers) and explicit ones, and send a WIRE_CONNECTCTL_CONNECT_TO_PEER_RESULT for the latter. In the success case, that's now redundant, since we hand the connected peer to the master using WIRE_CONNECT_PEER_CONNECTED; we just need a message for the failure case. And we might as well tell the master every failure, so we don't have to distinguish internally. This also solves a race we had before: connectd would send WIRE_CONNECTCTL_CONNECT_TO_PEER_RESULT which completes the incoming JSON connect command, then send WIRE_CONNECT_PEER_CONNECTED. So there's a window where the JSON command can return, but the peer isn't known to lightningd yet. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-09 01:25:29 +01:00
void connect_succeeded(struct lightningd *ld, const struct pubkey *id);
gossipd: keep reaching struct only when we're actively connecting, and don't retry 1. Lifetime of 'struct reaching' now only while we're actively doing connect. 2. Always free after a single attempt: if it's an important peer, retry on a timer. 3. Have a single response message to master, rather than relying on peer_connected on success and other msgs on failure. 4. If we are actively connecting and we get another command for the same id, just increment the counter The result is much simpler in the master daemon, and much nicer for reconnection: if they say to connect they get an immediate response, rather than waiting for 10 retries. Even if it's an important peer, it fires off another reconnect attempt, unless it's actively connecting now. This removes exponential backoff: that's restored in next patch. It also doesn't handle multiple addresses for a single peer. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-04-26 05:50:58 +01:00
void gossip_connect_result(struct lightningd *ld, const u8 *msg);
lightningd/peer_control: reorder, move more functions out. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 20:59:09 +00:00
lightningd/connect_control: routines to control connecting (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 20:59:09 +00:00
#endif /* LIGHTNING_LIGHTNINGD_CONNECT_CONTROL_H */