Trait Channel 

pub trait Channel
where
    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 { ... }
}

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

type Req

Type of request item.

type Resp

Type of response sink item.

type Transport

The wrapped transport.

Required Methods

fn config(&self) -> &Config

Configuration of the channel.

fn in_flight_requests(&self) -> usize

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

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

Returns the transport underlying the channel.

Provided Methods

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.

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.

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.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors

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

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

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