With this commit, calls to htlcSwitch.SendHTLC() are now synchronous,
only returning after the payment has been fully settled. This will
allow one to accurately measure the commitment update speed with the
current state machine implementation which is missing a number of
low-hanging optimizations.
The htlcManager for each channel now keeps a map of cleared HTLC’s
keyed by the index number of the add entry within the state machine’s
HTLC log. This map of HTLC’s will later be used to properly implement
time outs
Additionally, a slight refactoring has been executed w.r.t handling
upstream/downstream messages. This cleans up the main htlcManager loop,
freeing it up for the addition of future logic to properly observe
timeouts as well as, proper batching+trickling of HTLC updates, and a
commitment signature ticker.
This commit introduces the HtlcSwitch service into the daemon. The
purpose of the switch is to manage the message passing between the
goutiness within he peer managing each active channel. The switch
treats connected peers as interfaces, and their active channels as
links. All multi-hop, single-hop, and channel closure orchestration
will be managed by various goroutines within the HtlcSwitch.
The HtlcSwitch will also serve as the L2 contact point between the
yet-to-be-written LightningRouter and the switch, forwarding the new
htlc packet on the proper interface. Additionally, the switch will
handle dispatching htlc’s created locally via RPC, and multi-hop
forwarding initiated by peers.
This commit adds the necessary plumbing within the server, peer, and
rpcServer to handle opening and cooperatively closing a channel with a
remote peer.
Many new data structures have been added to the peer in order to allow
it to efficiently manage opening+.losing new/existing lightning
channels. Additional documentation has been added to several methods
within the peer struct, with some minor renaming along with way. The
peer has also gained a dedicated goroutine whose job it is to manage
any requests pertaining to opening, or closing any channels with the
remote peer.
The messages have been added to lnrpc define the requests and responses
to channel open+close messages. Additional channel logic has been added
between the rpcServer, peer, and server in order to properly manage the
necessary synchronization.
