use std::{cmp, fmt};
use std::io::Read;
-use util::events;
+use util::events::MessageSendEventsProvider;
use util::ser::{Readable, Writeable, Writer, FixedLengthReader, HighZeroBytesDroppedVarInt};
use ln::channelmanager::{PaymentPreimage, PaymentHash, PaymentSecret};
}
/// An init message to be sent or received from a peer
+#[derive(Clone)]
pub struct Init {
#[cfg(not(feature = "fuzztarget"))]
pub(crate) features: InitFeatures,
}
/// A ping message to be sent or received from a peer
+#[derive(Clone)]
pub struct Ping {
/// The desired response length
pub ponglen: u16,
}
/// A pong message to be sent or received from a peer
+#[derive(Clone)]
pub struct Pong {
/// The pong packet size.
/// This field is not sent on the wire. byteslen zeros are sent.
///
/// Messages MAY be called in parallel when they originate from different their_node_ids, however
/// they MUST NOT be called in parallel when the two calls have the same their_node_id.
-pub trait ChannelMessageHandler : events::MessageSendEventsProvider + Send + Sync {
+pub trait ChannelMessageHandler : MessageSendEventsProvider + Send + Sync {
//Channel init:
/// Handle an incoming open_channel message from the given peer.
fn handle_open_channel(&self, their_node_id: &PublicKey, their_features: InitFeatures, msg: &OpenChannel);
}
/// A trait to describe an object which can receive routing messages.
-pub trait RoutingMessageHandler : Send + Sync {
+///
+/// # Implementor DoS Warnings
+///
+/// For `gossip_queries` messages there are potential DoS vectors when handling
+/// inbound queries. Implementors using an on-disk network graph should be aware of
+/// repeated disk I/O for queries accessing different parts of the network graph.
+pub trait RoutingMessageHandler : Send + Sync + MessageSendEventsProvider {
/// Handle an incoming node_announcement message, returning true if it should be forwarded on,
/// false or returning an Err otherwise.
fn handle_node_announcement(&self, msg: &NodeAnnouncement) -> Result<bool, LightningError>;
/// immediately higher (as defined by <PublicKey as Ord>::cmp) than starting_point.
/// If None is provided for starting_point, we start at the first node.
fn get_next_node_announcements(&self, starting_point: Option<&PublicKey>, batch_amount: u8) -> Vec<NodeAnnouncement>;
- /// Returns whether a full sync should be requested from a peer.
- fn should_request_full_sync(&self, node_id: &PublicKey) -> bool;
+ /// Called when a connection is established with a peer. This can be used to
+ /// perform routing table synchronization using a strategy defined by the
+ /// implementor.
+ fn sync_routing_table(&self, their_node_id: &PublicKey, init: &Init);
+ /// Handles the reply of a query we initiated to learn about channels
+ /// for a given range of blocks. We can expect to receive one or more
+ /// replies to a single query.
+ fn handle_reply_channel_range(&self, their_node_id: &PublicKey, msg: ReplyChannelRange) -> Result<(), LightningError>;
+ /// Handles the reply of a query we initiated asking for routing gossip
+ /// messages for a list of channels. We should receive this message when
+ /// a node has completed its best effort to send us the pertaining routing
+ /// gossip messages.
+ fn handle_reply_short_channel_ids_end(&self, their_node_id: &PublicKey, msg: ReplyShortChannelIdsEnd) -> Result<(), LightningError>;
+ /// Handles when a peer asks us to send a list of short_channel_ids
+ /// for the requested range of blocks.
+ fn handle_query_channel_range(&self, their_node_id: &PublicKey, msg: QueryChannelRange) -> Result<(), LightningError>;
+ /// Handles when a peer asks us to send routing gossip messages for a
+ /// list of short_channel_ids.
+ fn handle_query_short_channel_ids(&self, their_node_id: &PublicKey, msg: QueryShortChannelIds) -> Result<(), LightningError>;
}
mod fuzzy_internal_msgs {