8 AMQP Frames: Storage and Throughput Calculations

8.8.1 Learning Objectives

Follow One Delivery Until Both Sides Agree

Picture a pump station sending a pressure record while a control service sends a valve command back. A connection can stay open even when one direction has no room to move. The useful question is which delivery stopped, why it stopped, and what state each side recorded.

AMQP means Advanced Message Queuing Protocol. A protocol is a shared set of message and state rules. A broker is a service that accepts and routes messages. A gateway is the device or service that joins two system paths. Telemetry means measurements and status sent from a remote device for review.

Send one numbered record, remove receiver credit, restore it, repeat the delivery, and restart one peer before settlement. Keep the delivery identity, direction, credit, outcome, and final application state together. Reachability alone does not prove that a valve acted once.

This runway does not choose a settlement mode for every workload. The deeper sections compare the two AMQP families, link credit, session windows, delivery outcomes, and the boundary between a settled message and an external side effect.

After this page, you should be able to:

• Explain why AMQP 1.0 is not a newer wire-compatible version of AMQP 0-9-1.
• Map AMQP 0-9-1 channels, publishing, prefetch, and acknowledgments to AMQP 1.0 sessions, links, credit, transfers, and dispositions.
• Trace how receiver-granted link credit constrains AMQP 1.0 message flow.
• Choose settlement behavior for at-most-once, at-least-once, and exactly-once link guarantees.
• Debug an AMQP 1.0 stalled transfer by checking both link credit and the session window.

8.8.2 Why This Follows AMQP Features and Frames

AMQP Features and Frames introduces frame roles, routing patterns, reliability features, AMQP 1.0 frame types, and the frame sequence workbench. This page narrows in on the design contract that matters during migrations and packet captures: AMQP 0-9-1 exposes exchanges, queues, bindings, and broker methods on the wire, while AMQP 1.0 exposes connections, sessions, links, credit, transfers, dispositions, and settlement.

Use it when a RabbitMQ team is moving to an AMQP 1.0 broker, when a gateway uses both telemetry and command streams on one connection, or when a packet trace shows flow credit and unsettled deliveries instead of basic.qos and basic.ack.

8.8.3 Overview: AMQP 1.0 Is a Different Protocol from AMQP 0-9-1

It is easy to assume AMQP 1.0 is just a newer AMQP 0-9-1, but they are genuinely different wire protocols that happen to share a name. AMQP 0-9-1 (what RabbitMQ speaks by default) bakes the broker model — exchanges, queues, bindings — into the protocol. AMQP 1.0 (the OASIS/ISO standard) deliberately does not: it standardises only the symmetric, peer-to-peer transfer of messages between two nodes and leaves routing to whatever broker or peer sits behind an address. That is why Azure Service Bus, ActiveMQ, and Qpid can all interoperate over AMQP 1.0 while implementing very different internals.

The difference shows up most clearly when you read the frames. In 0-9-1, the broker vocabulary is visible on the wire: clients issue methods such as exchange.declare, queue.bind, basic.publish, and basic.consume. A published message is then split into a method frame, a content header frame with properties and body size, and one or more body frames. In 1.0, the wire vocabulary is more abstract: peers open a connection, begin a session, attach sender or receiver links, exchange flow credit, transfer message sections, and settle deliveries with dispositions.

The 1.0 model nests three scopes: a connection carries one or more sessions, and each session carries one or more links. A link is unidirectional and has a role — a sender link or a receiver link — attached between a source and a target terminus. Messages travel as transfer frames along a link; the frames the chapter listed above (open, begin, attach, flow, transfer, disposition) are just the lifecycle of setting up and using those scopes.

That means migration is not a search-and-replace exercise. A RabbitMQ 0-9-1 producer might publish telemetry to a topic exchange with a routing key, where bindings choose the queue. An AMQP 1.0 producer instead attaches a sender link to an address; the broker decides what that address means. A packet capture therefore answers different questions. In 0-9-1 you ask, “Which exchange, queue, and method is this?” In 1.0 you ask, “Which connection/session/link is this transfer on, how much credit was available, and what delivery state settled it?”

8.8.4 Practitioner: Credit-Based Flow, and How the Two Versions Map

AMQP 1.0 flow control is credit-based and receiver-driven. A sender may not push at will: the receiver issues link credit in a flow frame, and the sender can emit only that many transfer frames before it must wait for more. This makes back-pressure explicit — a slow consumer simply stops granting credit. AMQP 0-9-1 achieves a similar effect differently, with basic.qos prefetch: the broker pushes up to a fixed number of unacknowledged messages and then pauses. Same goal, opposite direction: 1.0 receivers pull credit; 0-9-1 brokers push up to a cap.

Worked example: suppose a receiver link grants 25 credits. The sender can place 25 deliveries on that link and then must stop until another flow frame grants more credit. If the receiver processes 10 messages and grants 10 more credits, the sender gets room for 10 additional transfers without changing the TCP connection or creating a new link. The comparable 0-9-1 setting is basic.qos(prefetch_count=25), but the broker enforces that cap by withholding more pushed deliveries once 25 are outstanding.

For IoT gateways, this affects failure isolation. Put a high-rate telemetry stream and a low-rate command stream on separate links, and each link can have its own credit policy. Telemetry might keep 200 messages in flight because each sample is small and replaceable; commands might grant only one or two credits so the device handles each command deliberately. The session window still caps total in-flight transfers across links, so a gateway that multiplexes many devices should size link credit and session windows together rather than treating them as independent knobs.

8.8.5 Under the Hood: Settlement Is How 1.0 Chooses a Guarantee

In AMQP 1.0 each delivery is settled or unsettled, and a receiver reports an outcome in a disposition: terminal delivery states are accepted, rejected, released (send it to someone else), or modified (return it with annotations, e.g. increment a failure count). The two settlement-mode knobs on the link decide the guarantee:

Before choosing a delivery label, inspect Figure 8.3 to identify exactly when sender and receiver consider a transfer finished.

Read Figure 8.3 from at-most-once through at-least-once to coordinated settlement. The growing handshake reduces ambiguity on the link but adds state and latency. The final branch still cannot prove an external side effect occurred once, which is why the chapter returns to idempotency and transaction boundaries.

• At-most-once: the sender pre-settles — fires the transfer and forgets it. Fast, may lose.
• At-least-once: the sender leaves the delivery unsettled until the receiver’s disposition confirms accepted; a lost confirm means resend, so duplicates are possible.
• Exactly-once: a two-phase settlement (rcv-settle-mode = second) where the receiver settles only after the sender acknowledges the receiver’s outcome, so neither loss nor duplication occurs on that link.

Use those modes as engineering choices, not labels on a marketing slide. A temperature sample sent every few seconds may be acceptable as at-most-once because a later sample replaces it. A valve command should usually be unsettled until accepted, and the application should include a command id so a retry does not execute the same command twice. Two-phase settlement can remove ambiguity on the AMQP link, but side effects outside that link still need idempotency or transaction boundaries. For example, if a consumer accepts a delivery and then writes to a database, the database write and AMQP settlement are separate unless the system explicitly coordinates them.

This is a real difference from AMQP 0-9-1, which offers no native exactly-once settlement mode and pushes most systems toward at-least-once plus idempotent consumers. Sessions also carry their own flow window (incoming-window and outgoing-window) on top of per-link credit, so 1.0 does back-pressure at two levels: the session bounds total in-flight transfers, and each link bounds its own. When debugging a stalled link, inspect both numbers; a link can have credit and still be blocked if the session window is exhausted.