Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection service (connectiond) #20

Closed
dr-orlovsky opened this issue Oct 16, 2020 · 0 comments
Closed

Connection service (connectiond) #20

dr-orlovsky opened this issue Oct 16, 2020 · 0 comments
Assignees
Labels
epic Large or meta-issues with multiple related issues and tasks
Milestone

Comments

@dr-orlovsky
Copy link
Contributor

Connectiond is a lightning peer network connection microservice.

Program operations

Since this daemon must operate external P2P TCP socket, and TCP socket can
be either connected to the remote or accept remote connections; and we need
a daemon per connection, while the incoming TCP socket can't be transferred
between processes using IPC, the only option here is to have two special
cases of the daemon.

The first one will open TCP socket in listening mode and wait for incoming
connections, forking on each one of them, passing the accepted TCP socket to
the child and continuing on listening to the new connections. (In
multi-thread mode, differentiated with --threaded argument, instead of
forking damon will launch a new thread).

The second one will be launched by some control process and then commanded
(through command API) to connect to a specific remote TCP socket.

These two cases are differentiated by a presence command-line option
--listen followed by a listening address to bind (IPv4, IPv6, Tor and TCP
port number) or --connect option followed by a remote address in the same
format.

The overall program logic thus is the following:

In the process starting from main():

  • Parse cli arguments into a config. There is no config file, since the
    daemon can be started only from another control process (lnpd) or by
    forking itself.
  • If --listen argument is present, start a listening version as described
    above and open TCP port in listening mode; wait for incoming connections
  • If --connect argument is present, connect to the remote TCP peer

In forked/spawned version:

  • Acquire connected TCP socket from the parent

From here, all actions must be taken by either forked version or by a daemon
launched from the control process:

  • Open control interface socket
  • Split TCP socket and related transcoders into reading and writing parts
  • Create bridge ZMQ PAIR socket
  • Put both TCP socket reading ZMQ bridge write PAIR parts into a thread
    ("bridge")
  • Create run loop in the main thread for polling three ZMQ sockets:
    • control interface
    • LN P2P messages from intranet
    • bridge socket

tg_image_2563057733

@dr-orlovsky dr-orlovsky added the epic Large or meta-issues with multiple related issues and tasks label Oct 16, 2020
@dr-orlovsky dr-orlovsky added this to the v0.1 Alpha milestone Oct 16, 2020
@dr-orlovsky dr-orlovsky self-assigned this Oct 16, 2020
@dr-orlovsky dr-orlovsky pinned this issue Oct 17, 2020
@dr-orlovsky dr-orlovsky unpinned this issue Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Large or meta-issues with multiple related issues and tasks
Projects
None yet
Development

No branches or pull requests

1 participant