Crate fidl_next_protocol

Source
Expand description

Protocol support for FIDL.

This crate provides a number of types and traits related to FIDL protocols. These types and traits are all “untyped” - that is, they do not know about the specific types of the FIDL messages being sent and received. They only deal with protocol-layer semantics: requests and responses, clients and servers, and transports.

§Transports

This crate uses “transport” to refer to the specific object which moves bytes and handles from a sender to a receiver. For example, this crate may refer to a channel, socket, file, or other byte source/sink as a “transport”. This differs from the @transport(..) annotation in the FIDL language, which can be added to protocols.

FIDL transports implement the Transport trait. This trait defines several key properties:

  • The associated Sender and Receiver types.
  • The buffer types for sending and receiving data.
  • The async methods for sending and receiving data with those buffers.

All types in the protocol layer are generic over the transport, making it easy to add support for new types of transports.

By default, both sending and receiving data with a transport are asynchronous operations. However, transports may support synchronous send operations by implementing the NonBlockingTransport trait. This trait allows users to replace .await-ing a send operation with .send_immediately(), which synchronously completes the send future.

This crate provides an implementation of Transport for Fuchsia channels.

§Clients and servers

Clients and Servers are constructed from a transport, and can be run with a corresponding ClientHandler or ServerHandler. The client or server will then run its event loop to receive data through the transport. Clients use the handler to handle incoming events, and communicate with any ClientSenders to route two-way method responses to waiting futures. Servers use the handler to handle incoming one-way and two-way method requests, but do not generally communicate with its associated ServerSenders.

ClientSenders and ServerSenders generally implement Clone, and should be cloned to send from multiple locations.

Modules§

fuchsia
Fuchsia-specific FIDL protocol extensions.
mpsc
A basic Transport implementation based on MPSC channels.

Structs§

Client
A client for an endpoint.
ClientSender
A sender for a client endpoint.
IgnoreEvents
A client handler which ignores any incoming events.
RecvFuture
A future which receives an encoded message over the transport.
Responder
A responder for a two-way message.
ResponseFuture
A future for a request pending a response.
SendFuture
A future which sends an encoded message over the transport.
Server
A server for an endpoint.
ServerSender
A sender for a server endpoint.
WireFlexible
A flexible FIDL response.
WireFlexibleResult
A flexible FIDL result.
WireFrameworkError
An internal framework error.
WireMessageHeader
A FIDL protocol message header

Enums§

Flexible
A flexible FIDL response.
FlexibleResult
A flexible FIDL result.
FrameworkError
An internal framework error.
ProtocolError
Errors that can be produced by FIDL clients and servers.

Constants§

FLAG_0_WIRE_FORMAT_V2_BIT
The flag 0 bit indicating that the wire format is v2.
MAGIC_NUMBER
The magic number indicating FIDL protocol compatibility.

Traits§

ClientHandler
A type which handles incoming events for a client.
NonBlockingTransport
A transport layer which can send messages without blocking.
ServerHandler
A type which handles incoming events for a server.
ServiceInstance
An instance of a FIDL service.
Transport
A transport layer which can send and receive messages.
TransportExt
Helper methods for Transport.

Functions§

decode_header
Parses the transaction ID and ordinal from the given buffer.
encode_header
Encodes a message into the given buffer.