RabbitMQ / Basic: protocol resources, routing and ownership / Lesson 1

Messaging, connections and channels

Locate a message in an AMQP 0-9-1 flow and distinguish protocol resources from business identity.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain publisher, exchange, queue and consumer responsibilities.
Distinguish a TCP connection, a channel and an application operation.

A message has an application contract

A synthetic parcel job asks a worker to calculate a label for one parcel. Its message identifier, parcel identifier and operation version have different meanings. RabbitMQ transports the body and properties; it does not know whether calculating the label twice is acceptable. Decide whether the message describes a completed fact or requests an action, who owns failures and how the receiver recognizes retransmission. Stable business identity makes later recovery understandable. A random identifier generated for every retry creates different transport records while potentially repeating the same underlying business operation.

Follow the AMQP 0-9-1 path

This course's core flow uses AMQP 0-9-1: publishers send to exchanges, bindings route to queues and consumers receive deliveries from queues. Other supported protocols use different concepts and client APIs, so do not transfer a channel-specific rule to AMQP 1.0, MQTT or the dedicated Streams protocol without review. An exchange routes rather than serving as a retained queue itself. Multiple consumers on one queue normally share its work, while independent subscribers usually need separate queues or a deliberately selected stream design. Choose that delivery relationship before writing client code.

Channels share a connection but keep protocol state

An AMQP 0-9-1 connection can multiplex channels, each carrying protocol operations and channel-scoped state. Closing the connection closes its channels. A channel-level protocol exception can close one channel while leaving the connection available, but the application must observe the closure and correct its cause. Opening a connection or channel per message adds avoidable overhead. Reuse resources under the chosen client's concurrency rules rather than sharing a channel arbitrarily across worker threads. Channel numbers and delivery tags identify protocol context, not durable business operations that remain stable across reconnection.

Inspect a small job envelope

The JSON fixture separates message_id from parcel_id and records a declared operation version. It is an application envelope, not the AMQP wire format or a verified schema enforced by RabbitMQ. A retransmission of this exact label request retains its original message identity. A later request to generate a different label version should use an appropriately distinct operation identity. Avoid addresses or credentials in routing labels and identifiers because they can appear in diagnostics. Keep unsupported-version handling explicit so a worker does not silently interpret a new request shape using old business rules.

json Synthetic label-job contract

{"message_id":"label-P17-v1","parcel_id":"P17","operation":"calculate-label","operation_version":1}

The operation identity remains stable for retransmission; the broker does not validate these business fields automatically.

Model protocol context without opening a socket

The local example distinguishes two equal delivery-tag numbers belonging to different channels. The complete tuples differ, illustrating why a tag alone is insufficient context. It does not emulate channel recovery, RabbitMQ scheduling or acknowledgments. The selected documentation baseline is RabbitMQ 4.1, not a claim about the newest or currently supported release. All platform snippets in this course remain non-runnable, and no broker, client connection or configured service is started. Later lessons connect these resource boundaries to confirms, consumer acknowledgments and duplicate-safe external effects using explicit synthetic fixtures.

python Offline channel-scoped identity example

delivery_a = ('channel-a', 7)
delivery_b = ('channel-b', 7)
assert delivery_a != delivery_b
assert delivery_a[1] == delivery_b[1]
print(len({delivery_a, delivery_b}))

Expected output

Two equal numeric tags remain distinct protocol contexts; no message is acknowledged.

Common errors and fixes

A closed channel is reused after a protocol error.

Why it happens: The closure event and original cause were ignored.
How to fix it: Observe the shutdown reason, correct the contract and recover through the client’s supported lifecycle.
Prevent it next time: Record channel and connection failures separately.

Each retry receives a new business operation key.

Why it happens: Transport attempts were confused with logical occurrences.
How to fix it: Preserve the original operation identity for retransmission.
Prevent it next time: Define identity creation and persistence before publication.

Two independent applications miss messages on one shared queue.

Why it happens: Work sharing was mistaken for independent subscription.
How to fix it: Choose separate subscription queues or an appropriate stream design.
Prevent it next time: Document which consumers must each receive every event.

Check your understanding

1. Should a delivery tag be used as a durable label-operation identifier?

Show worked solution

No. The tag belongs to channel protocol state and can be reused in another channel context. Keep a stable application operation key in the message contract, and retain channel/tag context separately for acknowledgment diagnostics. Recovery can then recognize a repeated business request even when its new delivery has different protocol metadata.

2. Does the local tuple check prove a RabbitMQ client can reconnect correctly?