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
andReceiver
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
Client
s and Server
s 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 ClientSender
s 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 ServerSender
s.
ClientSender
s and ServerSender
s 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.
- Client
Sender - A sender for a client endpoint.
- Ignore
Events - A client handler which ignores any incoming events.
- Recv
Future - A future which receives an encoded message over the transport.
- Responder
- A responder for a two-way message.
- Response
Future - A future for a request pending a response.
- Send
Future - A future which sends an encoded message over the transport.
- Server
- A server for an endpoint.
- Server
Sender - A sender for a server endpoint.
- 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
Instance - An instance of a FIDL service.
- Transport
- A transport layer which can send and receive messages.
- Transport
Ext - 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.