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

48 lines
1.2 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 13:19:29 +00: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 13:24:29 +00: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 13:19:29 +00:00
#include <common/msg_queue.h>
#include <common/node_id.h>
struct peer {
struct node_id id;
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 13:24:29 +00:00
/* Counters and keys for symmetric crypto */
struct crypto_state cs;
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 13:19:29 +00:00
/* Connection to the peer */
struct io_conn *to_peer;
/* Connection to the subdaemon */
struct io_conn *to_subd;
/* Final message to send to peer (and hangup) */
u8 *final_msg;
/* Input buffers. */
u8 *subd_in, *peer_in;
/* Output buffers. */
struct msg_queue *subd_outq, *peer_outq;
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 13:22:29 +00:00
/* Peer sent buffer (for freeing after sending) */
const u8 *sent_to_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 13:19:29 +00:00
};
/* Set up peer->to_subd; sets fd_for_subd to pass to lightningd. */
bool multiplex_subd_setup(struct peer *peer, int *fd_for_subd);
/* Take over peer_conn as peer->to_peer */
struct io_plan *multiplex_peer_setup(struct io_conn *peer_conn,
struct peer *peer);
/* Send this message to peer and disconnect. */
void multiplex_final_msg(struct peer *peer,
const u8 *final_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 13:22:29 +00:00
/* Inject a message into the output stream */
void queue_peer_msg(struct peer *peer, const u8 *msg TAKES);
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 13:19:29 +00:00
#endif /* LIGHTNING_CONNECTD_MULTIPLEX_H */