relay

Type Members

1. class ChannelRelayer extends Actor with DiagnosticActorLogging

   

   The Channel Relayer is used to relay a single upstream HTLC to a downstream channel.

   The Channel Relayer is used to relay a single upstream HTLC to a downstream channel. It selects the best channel to use to relay and retries using other channels in case a local failure happens.

2. class CommandBuffer extends Actor with ActorLogging

   

   We store CMD_FULFILL_HTLC/CMD_FAIL_HTLC/CMD_FAIL_MALFORMED_HTLC in a database because we don't want to lose preimages, or to forget to fail incoming htlcs, which would lead to unwanted channel closings.

3. class NodeRelayer extends Actor with DiagnosticActorLogging

   

   The Node Relayer is used to relay an upstream payment to a downstream remote node (which is not necessarily a direct peer).

   The Node Relayer is used to relay an upstream payment to a downstream remote node (which is not necessarily a direct peer). It aggregates incoming HTLCs (in case multi-part was used upstream) and then forwards the requested amount (using the router to find a route to the remote node and potentially splitting the payment using multi-part).

4. sealed trait Origin extends AnyRef

   

5. class PostRestartHtlcCleaner extends Actor with ActorLogging

   

   If we have stopped eclair while it was handling HTLCs, it is possible that we are in a state were incoming HTLCs were committed by both sides, but we didn't have time to send and/or sign corresponding HTLCs to the downstream node.

   If we have stopped eclair while it was handling HTLCs, it is possible that we are in a state were incoming HTLCs were committed by both sides, but we didn't have time to send and/or sign corresponding HTLCs to the downstream node. It's also possible that we partially forwarded a payment (if MPP was used downstream): we have lost the intermediate state necessary to retry that payment, so we need to wait for the partial HTLC set sent downstream to either fail or fulfill (and forward the result upstream).

   If we were sending a payment (no downstream HTLCs) when we stopped eclair, we might have sent only a portion of the payment (because of multi-part): we have lost the intermediate state necessary to retry that payment, so we need to wait for the partial HTLC set sent downstream to either fail or fulfill the payment in our DB.

6. class Relayer extends Actor with DiagnosticActorLogging

   

   The Relayer decrypts incoming HTLCs and relays accordingly:

   The Relayer decrypts incoming HTLCs and relays accordingly:

   • to a payment handler if we are the final recipient
   • to a channel relayer if we are relaying from an upstream channel to a downstream channel
   • to a node relayer if we are relaying a trampoline payment

   It also receives channel HTLC events (fulfill / failed) and relays those to the appropriate handlers. It also maintains an up-to-date view of local channel balances.