Trait sc_network::service::traits::NetworkRequest

source ·
pub trait NetworkRequest {
    // Required methods
    fn request<'life0, 'async_trait>(
        &'life0 self,
        target: PeerId,
        protocol: ProtocolName,
        request: Vec<u8>,
        fallback_request: Option<(Vec<u8>, ProtocolName)>,
        connect: IfDisconnected,
    ) -> Pin<Box<dyn Future<Output = Result<(Vec<u8>, ProtocolName), RequestFailure>> + Send + 'async_trait>>
       where Self: 'async_trait,
             'life0: 'async_trait;
    fn start_request(
        &self,
        target: PeerId,
        protocol: ProtocolName,
        request: Vec<u8>,
        fallback_request: Option<(Vec<u8>, ProtocolName)>,
        tx: Sender<Result<(Vec<u8>, ProtocolName), RequestFailure>>,
        connect: IfDisconnected,
    );
}
Expand description

Provides ability to send network requests.

Required Methods§

source

fn request<'life0, 'async_trait>( &'life0 self, target: PeerId, protocol: ProtocolName, request: Vec<u8>, fallback_request: Option<(Vec<u8>, ProtocolName)>, connect: IfDisconnected, ) -> Pin<Box<dyn Future<Output = Result<(Vec<u8>, ProtocolName), RequestFailure>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait,

Sends a single targeted request to a specific peer. On success, returns the response of the peer.

Request-response protocols are a way to complement notifications protocols, but notifications should remain the default ways of communicating information. For example, a peer can announce something through a notification, after which the recipient can obtain more information by performing a request. As such, call this function with IfDisconnected::ImmediateError for connect. This way you will get an error immediately for disconnected peers, instead of waiting for a potentially very long connection attempt, which would suggest that something is wrong anyway, as you are supposed to be connected because of the notification protocol.

No limit or throttling of concurrent outbound requests per peer and protocol are enforced. Such restrictions, if desired, need to be enforced at the call site(s).

The protocol must have been registered through NetworkConfiguration::request_response_protocols.

source

fn start_request( &self, target: PeerId, protocol: ProtocolName, request: Vec<u8>, fallback_request: Option<(Vec<u8>, ProtocolName)>, tx: Sender<Result<(Vec<u8>, ProtocolName), RequestFailure>>, connect: IfDisconnected, )

Variation of request which starts a request whose response is delivered on a provided channel.

Instead of blocking and waiting for a reply, this function returns immediately, sending responses via the passed in sender. This alternative API exists to make it easier to integrate with message passing APIs.

Keep in mind that the connected receiver might receive a Canceled event in case of a closing connection. This is expected behaviour. With request you would get a RequestFailure::Network(OutboundFailure::ConnectionClosed) in that case.

Implementations on Foreign Types§

source§

impl<T> NetworkRequest for Arc<T>
where T: ?Sized + NetworkRequest,

source§

fn request<'life0, 'async_trait>( &'life0 self, target: PeerId, protocol: ProtocolName, request: Vec<u8>, fallback_request: Option<(Vec<u8>, ProtocolName)>, connect: IfDisconnected, ) -> Pin<Box<dyn Future<Output = Result<(Vec<u8>, ProtocolName), RequestFailure>> + Send + 'async_trait>>
where Self: 'async_trait, 'life0: 'async_trait,

source§

fn start_request( &self, target: PeerId, protocol: ProtocolName, request: Vec<u8>, fallback_request: Option<(Vec<u8>, ProtocolName)>, tx: Sender<Result<(Vec<u8>, ProtocolName), RequestFailure>>, connect: IfDisconnected, )

Implementors§

source§

impl<B, H> NetworkRequest for NetworkService<B, H>
where B: BlockT + 'static, H: ExHashT,