Trait tarpc::server::Channel

source ·
pub trait Channelwhere
    Self: Transport<Response<Self::Resp>, TrackedRequest<Self::Req>>,{
    type Req;
    type Resp;
    type Transport;

    // Required methods
    fn config(&self) -> &Config;
    fn in_flight_requests(&self) -> usize;
    fn transport(&self) -> &Self::Transport;

    // Provided methods
    fn max_concurrent_requests(self, limit: usize) -> MaxRequests<Self>
       where Self: Sized { ... }
    fn requests(self) -> Requests<Self>
       where Self: Sized { ... }
    fn execute<S>(self, serve: S) -> TokioChannelExecutor<Requests<Self>, S> 
       where Self: Sized,
             S: Serve<Self::Req, Resp = Self::Resp> + Send + 'static,
             S::Fut: Send,
             Self::Req: Send + 'static,
             Self::Resp: Send + 'static { ... }
}
Expand description

The server end of an open connection with a client, receiving requests from, and sending responses to, the client. Channel is a Transport with request lifecycle management.

The ways to use a Channel, in order of simplest to most complex, is:

  1. Channel::execute - Requires the tokio1 feature. This method is best for those who do not have specific scheduling needs and whose services are Send + 'static.
  2. Channel::requests - This method is best for those who need direct access to individual requests, or are not using tokio, or want control over futures scheduling. Requests is a stream of InFlightRequests, each which has an execute method. If using execute, request processing will automatically cease when either the request deadline is reached or when a corresponding cancellation message is received by the Channel.
  3. Stream::next / Sink::send - A user is free to manually read requests from, and send responses into, a Channel in lieu of the previous methods. Channels stream TrackedRequests, which, in addition to the request itself, contains the server Span, request lifetime [AbortRegistration], and an inert ResponseGuard. Wrapping response logic in an [Abortable] future using the abort registration will ensure that the response does not execute longer than the request deadline. The Channel itself will clean up request state once either the deadline expires, or the response guard is dropped, or a response is sent.

Channels must be implemented using the decorator pattern: the only way to create a TrackedRequest is to get one from another Channel. Ultimately, all TrackedRequests are created by BaseChannel.

Required Associated Types§

source

type Req

Type of request item.

source

type Resp

Type of response sink item.

source

type Transport

The wrapped transport.

Required Methods§

source

fn config(&self) -> &Config

Configuration of the channel.

source

fn in_flight_requests(&self) -> usize

Returns the number of in-flight requests over this channel.

source

fn transport(&self) -> &Self::Transport

Returns the transport underlying the channel.

Provided Methods§

source

fn max_concurrent_requests(self, limit: usize) -> MaxRequests<Self>where Self: Sized,

Caps the number of concurrent requests to limit. An error will be returned for requests over the concurrency limit.

Note that this is a very simplistic throttling heuristic. It is easy to set a number that is too low for the resources available to the server. For production use cases, a more advanced throttler is likely needed.

source

fn requests(self) -> Requests<Self>where Self: Sized,

Returns a stream of requests that automatically handle request cancellation and response routing.

This is a terminal operation. After calling requests, the channel cannot be retrieved, and the only way to complete requests is via Requests::execute or InFlightRequest::execute.

source

fn execute<S>(self, serve: S) -> TokioChannelExecutor<Requests<Self>, S> where Self: Sized, S: Serve<Self::Req, Resp = Self::Resp> + Send + 'static, S::Fut: Send, Self::Req: Send + 'static, Self::Resp: Send + 'static,

Available on crate feature tokio1 only.

Runs the channel until completion by executing all requests using the given service function. Request handlers are run concurrently by spawning on tokio’s default executor.

Implementors§

source§

impl<C> Channel for MaxRequests<C>where C: Channel,

§

type Req = <C as Channel>::Req

§

type Resp = <C as Channel>::Resp

§

type Transport = <C as Channel>::Transport

source§

impl<C, K> Channel for TrackedChannel<C, K>where C: Channel,

§

type Req = <C as Channel>::Req

§

type Resp = <C as Channel>::Resp

§

type Transport = <C as Channel>::Transport

source§

impl<Req, Resp, T> Channel for BaseChannel<Req, Resp, T>where T: Transport<Response<Resp>, ClientMessage<Req>>,

§

type Req = Req

§

type Resp = Resp

§

type Transport = T