AMQP 0-9-1 Protocol Specification (2008)

This 39-page specification, dated 13 November 2008, defines both a broker object model and its binary client/server protocol. It is primary evidence for what AMQP 0-9-1 means; it is not a current operations manual for RabbitMQ.

Durable contribution #

The AMQ model separates three roles:

• an exchange accepts publishes and chooses zero or more destinations;
• a binding supplies the relationship and matching arguments between an exchange and a queue;
• a message queue stores each routed copy and distributes deliveries to consumers.

This separation makes point-to-point work, publish-subscribe, and topic/header routing compositions of the same primitives. The default exchange is a direct exchange with an automatic queue-name binding, so apparent direct-to-queue publishing still follows the model.

The specification also makes several boundaries explicit:

• channels multiplex independent command streams over one TCP connection;
• an application acknowledgement tells a queue that a delivery was processed;
• unacknowledged deliveries are marked for redelivery when their channel closes;
• prefetch limits deliveries outstanding before acknowledgement;
• FIFO is weak in the presence of multiple consumers, priorities, transactions, selectors, and redelivery;
• stable order is specified only for one incoming channel → exchange → queue → outgoing channel path;
• operational errors close a channel, while structural protocol errors close the connection.

The wire layer uses typed frames with a seven-octet header, payload size, channel id, and frame-end marker. Content-carrying methods are followed by one content header and zero or more opaque body frames. These details matter when diagnosing frame-size limits, channel-scoped delivery tags, heartbeat failure, or a connection closed by a protocol exception, but they are intentionally not reproduced in the GTK messaging chapter.

Historical boundaries #

Several statements are true only of the 2008 base specification and must not be generalized to current RabbitMQ:

• Section 2.2.3 says successful asynchronous publishes are silent and explicit success tracking should use transactions. RabbitMQ later added publisher confirms (confirm.select) as a lighter extension; current applications normally use confirms rather than per-publish AMQP transactions.
• The specification describes persistent messages and durable queues but does not define RabbitMQ quorum queues, Raft replication, stream/superstream data structures, modern dead-letter safety modes, or current flow-control behavior.
• Its deployment-scale examples and performance magnitudes are historical, not capacity guidance.
• AMQP 0-9-1 and AMQP 1.0 are distinct protocols with different models. A modern product saying “AMQP” does not imply the exchange/binding model in this document.

GTK therefore uses the specification for protocol semantics and verifies all product behavior against current RabbitMQ documentation.

Visual audit #

All 39 physical pages were extracted, read, rendered at 140 DPI, and accounted for. Information-bearing diagrams occur on pages 7, 11, 13, 16, 19, 23, 25, 33, 36, and 37: functional/transport layers, the AMQ entity model, message flow, temporary queue lifecycle, method mapping, frame layouts, client layers, content framing, and channel multiplexing.

The original figures are legible but use dense monospaced boxes and focus on the protocol document's implementation structure. None is retained as an article asset. The GTK chapter synthesizes the load-bearing exchange → queue → consumer topology into a new responsibility-boundary diagram that also adds current publisher confirms, durable business effects, and redelivery — the failure path the original drawings do not show.