mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 09:54:16 +01:00
Code Issues Projects Releases Wiki Activity
4f0f84661e
core-lightning/connectd/multiplex.h

41 lines
1.3 KiB
C
Raw Normal View History

connectd: maintain connection with peer, shuffle data. Instead of passing the incoming socket to lightningd for the subdaemon, create a new one and simply shuffle data between them, keeping connectd in the loop. For the moment, we don't decrypt at all, just shuffle. This means our buffer code is kind of a hack, but that goes away once we start actually decrypting and understanding message boundaries. This implementation is naive: it closes the socket to the local daemon as soon as the peer closes the socket to us. This is fixed in a successive patch series (along with many other similar issues). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:19:29 +01:00
#ifndef LIGHTNING_CONNECTD_MULTIPLEX_H
#define LIGHTNING_CONNECTD_MULTIPLEX_H
#include "config.h"
#include <ccan/short_types/short_types.h>
per_peer_state: remove struct crypto_state Now that connectd does the crypto, no need to hand around crypto_state. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:24:29 +01:00
#include <common/crypto_state.h>
connectd: maintain connection with peer, shuffle data. Instead of passing the incoming socket to lightningd for the subdaemon, create a new one and simply shuffle data between them, keeping connectd in the loop. For the moment, we don't decrypt at all, just shuffle. This means our buffer code is kind of a hack, but that goes away once we start actually decrypting and understanding message boundaries. This implementation is naive: it closes the socket to the local daemon as soon as the peer closes the socket to us. This is fixed in a successive patch series (along with many other similar issues). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:19:29 +01:00
#include <common/msg_queue.h>
#include <common/node_id.h>
connectd: serve gossip_store file for the peer. We actually intercept the gossip_timestamp_filter, so the gossip_store mechanism inside the per-peer daemon never kicks off for normal connections. The gossipwith tool doesn't set OPT_GOSSIP_QUERIES, so it gets both, but that only effects one place. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:28:29 +01:00
struct peer;
struct io_conn;
struct feature_set;
connectd: maintain connection with peer, shuffle data. Instead of passing the incoming socket to lightningd for the subdaemon, create a new one and simply shuffle data between them, keeping connectd in the loop. For the moment, we don't decrypt at all, just shuffle. This means our buffer code is kind of a hack, but that goes away once we start actually decrypting and understanding message boundaries. This implementation is naive: it closes the socket to the local daemon as soon as the peer closes the socket to us. This is fixed in a successive patch series (along with many other similar issues). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:19:29 +01:00
/* Take over peer_conn as peer->to_peer */
struct io_plan *multiplex_peer_setup(struct io_conn *peer_conn,
struct peer *peer);
connectd: do io logging properly for msgs we make. We don't need to log msgs from subds, but we do our own, and we weren't. 1. Rename queue_peer_msg to inject_peer_msg for clarity, make it do logging 2. In the one place where we're relaying, call msg_queue() directly. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-29 04:33:05 +01:00
/* Inject a message into the output stream. Unlike a raw msg_enqueue,
misc: clarifications from cdecker review. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-02-07 04:32:32 +01:00
* this does io logging. */
connectd: do io logging properly for msgs we make. We don't need to log msgs from subds, but we do our own, and we weren't. 1. Rename queue_peer_msg to inject_peer_msg for clarity, make it do logging 2. In the one place where we're relaying, call msg_queue() directly. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-29 04:33:05 +01:00
void inject_peer_msg(struct peer *peer, const u8 *msg TAKES);
connectd: do decryption for peers. We temporarily hack to sync_crypto_write/sync_crypto_read functions to not do any crypto, and do it all in connectd. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:22:29 +01:00
connectd: serve gossip_store file for the peer. We actually intercept the gossip_timestamp_filter, so the gossip_store mechanism inside the per-peer daemon never kicks off for normal connections. The gossipwith tool doesn't set OPT_GOSSIP_QUERIES, so it gets both, but that only effects one place. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:28:29 +01:00
void setup_peer_gossip_store(struct peer *peer,
const struct feature_set *our_features,
const u8 *their_features);
connectd: don't just close to peer, but use shutdown(). We would lose packets sometimes due to this previously, but it doesn't happen over localhost so our tests didn't notice. However, now we have connectd being sole thing talking to peers, we can do a more elegant shutdown, which should fix closing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: Always flush sockets to increase chance that final message get to peer (esp. error packets).
2022-01-11 02:16:49 +01:00
connectd: handle pings and pongs. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: JSON_RPC: `ping` now works with connected peers, even without a channel.
2022-01-29 04:31:32 +01:00
/* When lightningd says to send a ping */
void send_manual_ping(struct daemon *daemon, const u8 *msg);
connectd: handle custom messages. This is neater than what we had before, and slightly more general. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: JSON_RPC: `sendcustommsg` now works with any connected peer, even when shutting down a channel.
2022-01-29 04:33:05 +01:00
/* When lightningd says to send a custom message (from a plugin) */
void send_custommsg(struct daemon *daemon, const u8 *msg);
connectd: hold peer until we're interested. Either because lightningd tells us it wants to talk, or because the peer says something about a channel. We also introduce a behavior change: we disconnect after a failed open. We might want to modify this later, but we it's a side-effect of openingd not holding onto idle connections. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-03-22 21:27:29 +01:00
lightningd: tell connectd about the custom messages. We re-send whenever a plugin which allows them starts/finishes. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-23 13:29:51 +02:00
/* When lightningd says what custom messages we can recv */
void set_custommsgs(struct daemon *daemon, const u8 *msg);
connectd: hold peer until we're interested. Either because lightningd tells us it wants to talk, or because the peer says something about a channel. We also introduce a behavior change: we disconnect after a failed open. We might want to modify this later, but we it's a side-effect of openingd not holding onto idle connections. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-03-22 21:27:29 +01:00
/* Lightningd wants to talk to you. */
lightningd: hand fds to connectd, not receive them from connectd. Before this patch: 1. connectd says it's connected (peer_connected) 2. we tell connectd we want to talk about each channel (peer_make_active) 3. connectd gives us an fd for each channel, and we connect it to a subd (peer_active) 4. OR, connectd says it sent something about a channel we didn't tell it about, with an fd (peer_active) Now: 1. connectd says it's connected (peer_connected) 2. we start all appropriate subds and tell connectd to what channels/fds (peer_connect_subd). 3. if connectd says it sent something about a channel we didn't tell it about, we either tell it to hang up (peer_final_msg), or connect a new opening daemon (peer_connect_subd). This is the minimal-size patch, which is why we create socket pairs in so many places to use the existing functions. Many cleanups are possible, since the new flow is so simple. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-07-18 14:12:18 +02:00
void peer_connect_subd(struct daemon *daemon, const u8 *msg, int fd);
connectd: give subds a chance to drain when lightningd says to disconnect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-22 06:07:31 +02:00
/* Start shutting down peer. */
void drain_peer(struct peer *peer);
connectd: maintain connection with peer, shuffle data. Instead of passing the incoming socket to lightningd for the subdaemon, create a new one and simply shuffle data between them, keeping connectd in the loop. For the moment, we don't decrypt at all, just shuffle. This means our buffer code is kind of a hack, but that goes away once we start actually decrypting and understanding message boundaries. This implementation is naive: it closes the socket to the local daemon as soon as the peer closes the socket to us. This is fixed in a successive patch series (along with many other similar issues). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-08 14:19:29 +01:00
#endif /* LIGHTNING_CONNECTD_MULTIPLEX_H */
Reference in New Issue Copy Permalink