Backpressure ensures that the backpressure server has a bound on the number of
events in its event queue, at all times. This is achieved by preventing the clients
from sending too many events.
Clients must ask the backpressure server for a backpressure link. When a client
receives a link, it must check if it has sufficient budget to send events to
the server, and potentially wait before sending an event. The budget is spent each
time that the client sends an event, and replenished when the server sends a token.
There are several kinds of backpressure exposed by this module:
The for-all backpressure policy maintains a fixed number of tokens across all
backpressure links. The advantage is that the server cannot be overwhelmed,
regardless of the number of clients. The disadvantage is that some clients can
fail while holding some of the tokens, in which case tokens are lost. If failures
are possible in the system, such scenarios can ultimately starve the protocol.
The per-client backpressure policy maintains a fixed number of tokens per each
backpressure link. The advantage is that the failure of any single client only
obliviates the tokens from the client's own backpressure links, so other clients
cannot be starved. The disadvantage is that the total number of clients may be
unbounded, which can overwhelm the backpressure server.
Communication patterns based on backpressure.
Backpressure ensures that the backpressure server has a bound on the number of events in its event queue, at all times. This is achieved by preventing the clients from sending too many events.
Clients must ask the backpressure server for a backpressure link. When a client receives a link, it must check if it has sufficient budget to send events to the server, and potentially wait before sending an event. The budget is spent each time that the client sends an event, and replenished when the server sends a token.
There are several kinds of backpressure exposed by this module: