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
Shared
andExclusive
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
ClientDispatcher
s and ServerDispatcher
s are constructed from a
transport, and can be run
with a corresponding ClientHandler
or
ServerHandler
. The dispatcher will then run its event loop to receive
data through the transport. Client dispatchers use their handlers to handle
incoming events, and coordinate with any Client
s to route two-way method
responses to waiting futures. Server dispatchers use their handlers to
handle incoming one-way and two-way method requests, but do not generally
coordinate with their associated Server
s.
Client
s and Server
s implement Clone
, and should be cloned to
interact with the connection from multiple locations.
Modules§
- fuchsia
- Fuchsia-specific FIDL protocol extensions.
- mpsc
- A basic
Transport
implementation based on MPSC channels.
Structs§
- Client
- A client endpoint.
- Client
Dispatcher - A dispatcher for a client endpoint.
- Ignore
Events - A client handler which ignores any incoming events.
- Respond
Future - A future which responds to a request over a connection.
- Responder
- A responder for a two-way message.
- Send
Future - A future which sends an encoded message to a connection.
- Server
- A server endpoint.
- Server
Dispatcher - A dispatcher for a server endpoint.
- TwoWay
Request Future - A future for a sending a two-way FIDL message.
- TwoWay
Response Future - A future for a pending response to a two-way message.
- Wire
Epitaph - A FIDL protocol epitaph.
- Wire
Flexible - A flexible FIDL response.
- Wire
Flexible Result - A flexible FIDL result.
- Wire
Framework Error - An internal framework error.
- Wire
Message Header - A FIDL protocol message header
Enums§
- Flexible
- A flexible FIDL response.
- Flexible
Result - A flexible FIDL result.
- Framework
Error - An internal framework error.
- Protocol
Error - 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§
- Client
Handler - A type which handles incoming events for a client.
- NonBlocking
Transport - A transport layer which can send messages without blocking.
- Server
Handler - A type which handles incoming events for a server.
- Service
Connector - A member connector for a FIDL service.
- Service
Handler - A type which handles incoming service connections for a server.
- Transport
- A transport layer which can send and receive messages.
Functions§
- decode_
epitaph - Parses the epitaph error from the given buffer.
- decode_
header - Parses the transaction ID and ordinal from the given buffer.
- encode_
epitaph - Encodes an epitaph into the given buffer.
- encode_
header - Encodes a message into the given buffer.