Class NetworkGraph


  • public class NetworkGraph
    extends Object
    Represents the network as nodes and channels between them
    • Method Detail

      • handle_network_update

        public void handle_network_update​(NetworkUpdate network_update)
        Handles any network updates originating from [`Event`]s. [`Event`]: crate::events::Event
      • write

        public byte[] write()
        Serialize the NetworkGraph object into a byte array which can be read by NetworkGraph_read
      • read_only

        public ReadOnlyNetworkGraph read_only()
        Returns a read-only view of the network graph.
      • get_last_rapid_gossip_sync_timestamp

        public Option_u32Z get_last_rapid_gossip_sync_timestamp()
        The unix timestamp provided by the most recent rapid gossip sync. It will be set by the rapid sync process after every sync completion.
      • set_last_rapid_gossip_sync_timestamp

        public void set_last_rapid_gossip_sync_timestamp​(int last_rapid_gossip_sync_timestamp)
        Update the unix timestamp provided by the most recent rapid gossip sync. This should be done automatically by the rapid sync process after every sync completion.
      • update_node_from_announcement

        public Result_NoneLightningErrorZ update_node_from_announcement​(NodeAnnouncement msg)
        For an already known node (from channel announcements), update its stored properties from a given node announcement. You probably don't want to call this directly, instead relying on a P2PGossipSync's RoutingMessageHandler implementation to call it indirectly. This may be useful to accept routing messages from a source using a protocol other than the lightning P2P protocol.
      • update_node_from_unsigned_announcement

        public Result_NoneLightningErrorZ update_node_from_unsigned_announcement​(UnsignedNodeAnnouncement msg)
        For an already known node (from channel announcements), update its stored properties from a given node announcement without verifying the associated signatures. Because we aren't given the associated signatures here we cannot relay the node announcement to any of our peers.
      • update_channel_from_announcement

        public Result_NoneLightningErrorZ update_channel_from_announcement​(ChannelAnnouncement msg,
                                                                           Option_UtxoLookupZ utxo_lookup)
        Store or update channel info from a channel announcement. You probably don't want to call this directly, instead relying on a P2PGossipSync's RoutingMessageHandler implementation to call it indirectly. This may be useful to accept routing messages from a source using a protocol other than the lightning P2P protocol. If a [`UtxoLookup`] object is provided via `utxo_lookup`, it will be called to verify the corresponding UTXO exists on chain and is correctly-formatted.
      • update_channel_from_unsigned_announcement

        public Result_NoneLightningErrorZ update_channel_from_unsigned_announcement​(UnsignedChannelAnnouncement msg,
                                                                                    Option_UtxoLookupZ utxo_lookup)
        Store or update channel info from a channel announcement without verifying the associated signatures. Because we aren't given the associated signatures here we cannot relay the channel announcement to any of our peers. If a [`UtxoLookup`] object is provided via `utxo_lookup`, it will be called to verify the corresponding UTXO exists on chain and is correctly-formatted.
      • add_channel_from_partial_announcement

        public Result_NoneLightningErrorZ add_channel_from_partial_announcement​(long short_channel_id,
                                                                                long timestamp,
                                                                                ChannelFeatures features,
                                                                                byte[] node_id_1,
                                                                                byte[] node_id_2)
        Update channel from partial announcement data received via rapid gossip sync `timestamp: u64`: Timestamp emulating the backdated original announcement receipt (by the rapid gossip sync server) All other parameters as used in [`msgs::UnsignedChannelAnnouncement`] fields.
      • channel_failed_permanent

        public void channel_failed_permanent​(long short_channel_id)
        Marks a channel in the graph as failed permanently. The channel and any node for which this was their last channel are removed from the graph.
      • node_failed_permanent

        public void node_failed_permanent​(byte[] node_id)
        Marks a node in the graph as permanently failed, effectively removing it and its channels from local storage.
      • remove_stale_channels_and_tracking

        public void remove_stale_channels_and_tracking()
        Removes information about channels that we haven't heard any updates about in some time. This can be used regularly to prune the network graph of channels that likely no longer exist. While there is no formal requirement that nodes regularly re-broadcast their channel updates every two weeks, the non-normative section of BOLT 7 currently suggests that pruning occur for updates which are at least two weeks old, which we implement here. Note that for users of the `lightning-background-processor` crate this method may be automatically called regularly for you. This method will also cause us to stop tracking removed nodes and channels if they have been in the map for a while so that these can be resynced from gossip in the future. This method is only available with the `std` feature. See [`NetworkGraph::remove_stale_channels_and_tracking_with_time`] for `no-std` use.
      • remove_stale_channels_and_tracking_with_time

        public void remove_stale_channels_and_tracking_with_time​(long current_time_unix)
        Removes information about channels that we haven't heard any updates about in some time. This can be used regularly to prune the network graph of channels that likely no longer exist. While there is no formal requirement that nodes regularly re-broadcast their channel updates every two weeks, the non-normative section of BOLT 7 currently suggests that pruning occur for updates which are at least two weeks old, which we implement here. This method will also cause us to stop tracking removed nodes and channels if they have been in the map for a while so that these can be resynced from gossip in the future. This function takes the current unix time as an argument. For users with the `std` feature enabled, [`NetworkGraph::remove_stale_channels_and_tracking`] may be preferable.
      • update_channel

        public Result_NoneLightningErrorZ update_channel​(ChannelUpdate msg)
        For an already known (from announcement) channel, update info about one of the directions of the channel. You probably don't want to call this directly, instead relying on a P2PGossipSync's RoutingMessageHandler implementation to call it indirectly. This may be useful to accept routing messages from a source using a protocol other than the lightning P2P protocol. If built with `no-std`, any updates with a timestamp more than two weeks in the past or materially in the future will be rejected.
      • update_channel_unsigned

        public Result_NoneLightningErrorZ update_channel_unsigned​(UnsignedChannelUpdate msg)
        For an already known (from announcement) channel, update info about one of the directions of the channel without verifying the associated signatures. Because we aren't given the associated signatures here we cannot relay the channel update to any of our peers. If built with `no-std`, any updates with a timestamp more than two weeks in the past or materially in the future will be rejected.