feat(lightning): Add Lightning as transport #85

Add message (de)serilaization to teos-common This commit adds lightning messages and message (de)serialization using helper local modules (ser_utils, ser_macros) and LDK v0.0.108 instead of the attempted fork used before (https://github.com/meryacine/rust-lightning/tree/expose-tlv-macros) Most of the serialization macros and utils are copied from LDK's own serialization framework though. Also we might remove some of the locally implemented TLV stuff if they ever get exposed by LDK. But some of the macros have been edited and diverged from LDK's first implementation: for example, the `vec` arms for the macros were adjusted so that it works with `impl_writeable_msg` macro to send arrays as TLV (which is not the case for LDK ATM). Note that we could have had vectors(arrays) be inside `Option`s and put in a TLV, but this will waste extra two bytes for vector length annotation (we don't need the vector length annotated in the V(value) of the TLV since L(length) already embeds this information) We also now have another macro match arm `str_opt`, which indicates an optional string inside a TLV, this was created to avoid adding extra length field for strings just like `vec`.

This commit adds the lightning server and its port configuration option. The peer manager in charge of the lightning server doesn't know about routing and lightning channels (yet?). It can only responde to the user custom messages defined in `teos_common::lightning::messages`. A \`block_in_place\` is used in \`handle_tower_message\` to synchronously block on grpc calls.

These tests are analogous to tests in `http::tests_methods` and they test the tower message handler logic only (not the tower message handler when inside a peer manager)

These test utils include: - A test lightning client: this simulates a client's peer manager that is trying to connect to the tower and send/receive tower messages. For a real client, this should be part of a bigger application (say a lightning node) and the custom message handler adds the capabilities of speaking with the tower over Lightning. - Some utils to launch a Lightning server and connect one peer manager to another - A simple proof of concept test

This fixes a deadlock issue that appears with too many concurrent requtests. This solution was taken from devrandom's issue: lightningdevkit/rust-lightning #1367 Another solution that would probably work is that lightning net tokio wraps our sync calls with `tokio::task::spawn_blocking(|| sync_call()).await.unwarp()`, but not sure how would this affect performace of other users with no async code requirements. Note that peer_manager_tests now don't need to be anotated with `flavor = "multi_thread"`, that's because the runtime we block_on (inside lightning net tokio) is the artificial runtime created in `api::lightning::server` which is already "multi_thread"

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(lightning): Add Lightning as transport #85

feat(lightning): Add Lightning as transport #85

Commits on Feb 6, 2023

feat(lightning): Add Lightning as transport #85

Are you sure you want to change the base?

feat(lightning): Add Lightning as transport #85

Commits on Feb 6, 2023