Loading...
Searching...
No Matches
Actor-based Network Abstraction

Brokers provide an actor-based abstraction for low-level network IO. More...

## Classes

class | caf::io::abstract_broker
| A broker mediates between actor systems and other components in the network. More...
class | caf::io::broker
| Describes a dynamically typed broker. More...
class | caf::io::broker_servant< Base, Handle, SysMsgType >
| Base class for scribe and doorman. More...
class | caf::io::datagram_servant
| Manages writing to a datagram sink. More...
class | caf::io::doorman
| Manages incoming connections. More...
class | caf::io::scribe
| Manages a stream. More...

## Detailed Description

Brokers provide an actor-based abstraction for low-level network IO.

The central component in the network abstraction of CAF is the middleman. It connects any number of brokers to a multiplexer, which implements a low-level IO event loop.

Relation between middleman, multiplexer, and broker

Brokers do not operate on sockets or other platform-dependent communication primitives. Instead, brokers use a connection_handle to identify a reliable, end-to-end byte stream (e.g. a TCP connection) and accept_handle to identify a communication endpoint others can connect to via its port.

Each connection_handle is associated with a scribe that provides access to an output buffer as well as a flush operation to request sending its content via the network. Instead of actively receiving data, brokers configure a scribe to asynchronously receive data, e.g., self->configure_read(hdl, receive_policy::exactly(1024)) would configure the scribe associated with hdl to receive exactly 1024 bytes and generate a new_data_msg message for the broker once the data is available. The buffer in this message will be re-used by the scribe to minimize memory usage and heap allocations.

Each accept_handle is associated with a doorman that will create a new_connection_msg whenever a new connection was established.

All scribe and doorman instances are managed by the multiplexer