Compatibility and Conformance
Table of Contents
Specification versions supported
The following table describes the version of the AMQP protocol specification implemented by each RabbitMQ release:
| RabbitMQ versions through | implement AMQP protocol version |
|---|---|
| (present release) (server and Java client) | 0-8 (core spec, class def pdf, class def xml) |
| (present release) (.NET/C# client ONLY) | 0-8 and 0-9, switchable at runtime |
Unimplemented Features
Currently, we have implemented the core AMQP features. Some features are yet to be implemented, including "channel.qos" prefetch windowing and "channel.flow" flow control (TCP windowing still provides primitive flow control).
See also the detailed specification compatibility tables below.
Classes from the AMQP specification, version 0-8
The following table describes the current implementation status of the various AMQP protocol message classes.
| Current Status | Class | Notes |
|---|---|---|
| ok | connection | |
| ok | channel | |
| ok | access | |
| ok | exchange | |
| ok | queue | |
| ok | basic | |
| planned | file | |
| planned | stream | |
| ok | tx | |
| dtx | ||
| tunnel | ||
| test |
Methods from the AMQP specification, version 0-8
The following table describes the current implementation status of the various AMQP protocol methods in each class.
| Current Status | Method | Notes |
|---|---|---|
| ok | connection.start | |
| ok | connection.start-ok | |
| ok | connection.secure | We also plan to implement further authentication methods. |
| ok | connection.secure-ok | |
| ok | connection.tune | |
| ok | connection.tune-ok | |
| ok | connection.open | |
| ok | connection.open-ok | |
| ok | connection.redirect | |
| ok | connection.close | |
| ok | connection.close-ok | |
| ok | channel.open | |
| ok | channel.open-ok | |
| planned | channel.flow | |
| planned | channel.flow-ok | |
| deprecated | channel.alert | |
| ok | channel.close | |
| ok | channel.close-ok | |
| ok | access.request | |
| ok | access.request-ok | |
| ok | exchange.declare | |
| ok | exchange.declare-ok | |
| ok | exchange.delete | |
| ok | exchange.delete-ok | |
| ok | queue.declare | |
| ok | queue.declare-ok | |
| ok | queue.bind | |
| ok | queue.bind-ok | |
| ok | queue.purge | |
| ok | queue.purge-ok | |
| ok | queue.delete | |
| ok | queue.delete-ok | |
| planned | basic.qos | |
| planned | basic.qos-ok | |
| ok | basic.consume | |
| ok | basic.consume-ok | |
| ok | basic.cancel | |
| ok | basic.cancel-ok | |
| ok | basic.publish | |
| ok | basic.return | |
| ok | basic.deliver | |
| ok | basic.get | |
| ok | basic.get-ok | |
| ok | basic.get-empty | |
| ok | basic.ack | |
| planned | basic.reject | |
| ok | basic.recover | |
| ok | tx.select | |
| ok | tx.select-ok | |
| ok | tx.commit | |
| ok | tx.commit-ok | |
| ok | tx.rollback | |
| ok | tx.rollback-ok |
Rules from the AMQP specification, version 0-8
The first few entries in the following table are taken from the non-XML part of the specification, and the remainder are automatically generated from the XML part.
| Current Status | Type | Actor | Text |
|---|---|---|---|
| does | SHOULD | v0-8, 1.5.1:
API names taken from specification
|
|
| ok | MUST NOT | server | v0-8, 2.2.6:
Trust presented tickets
|
| ok | MUST | server |
Check resource accessibility when a ticket is presented
|
| ok | MUST | client |
Treat tickets as opaque data
|
| doesn't | MAY | server | v0-8, 2.3.3:
Host multiple protocol versions on the same port
|
| ok | MUST NOT | server | v0-8, 3.1.1:
Modify message content bodies
|
| ok | MUST | server | v0-8, 3.1.2:
Associate a single Virtual Host with each connection
|
| ok | MUST | server | v0-8, 3.1.3.1:
Implement "direct" exchanges
|
| ok | MUST | server |
Bind each queue to the default direct exchange
|
| ok | MUST | server |
Predeclare "amq.direct" and "" exchanges
|
| ok | MUST | server | v0-8, 3.1.3.2:
Implement "fanout" exchanges
|
| ok | MUST | server |
Predeclare "amq.fanout" exchange
|
| planned | MUST | client | v0-8, 3.1.3.3:
Routing key matches regex ([a-zA-Z0-9.]*)
|
| does | SHOULD | server |
Implement "topic" exchanges
|
| ok | MUST | server |
Predeclare "amq.topic" exchange (only if "topic" exchange implemented)
|
| ok | MUST | server | v0-8, 3.1.3.5:
Nonstandard exchange types must be named with "x-" prefix
|
| ok | MUST | v0-8, 3.1.10:
Respect naming conventions ("amq.", "x-")
|
|
| ok | Erratum | v0-8, 4.2.2:
Corrected AMQP protocol header is A,M,Q,P,1,1,8,0
|
|
| ok | MUST | server |
Accept protocol with class 1, instance 1 (AMQP over TCP/IP)
|
| planned | MAY | server |
Accept non-AMQP protocols
|
| ok | MUST | server |
Reject invalid header with a valid header and connection-close
|
| does | MAY | server |
Log reception of an invalid header
|
| doesn't | MAY | client |
Detect supported protocol versions by attempting connection with different protocol headers
|
| ok | MUST | v0-8, 4.2.3:
Immediately close connection on reception of an invalid frame type
|
|
| ok | MUST |
Check for frame-end octet before further decoding a frame
|
|
| ok | MUST |
Immediately close connection on frame-end octet check failure
|
|
| does | SHOULD |
Log frame-end octet check failures
|
|
| ok | MUST NOT |
Send frames larger than the agreed-upon size
|
|
| planned | MUST |
Signal connection exception FRAME_ERROR when oversize frames are detected
|
|
| ok | MUST NOT | v0-8, 4.2.5.1:
Assume particular word alignment of multi-byte fields within a frame
|
|
| planned | MUST | v0-8, 4.2.5.5:
Generate field names conforming to specified pattern
|
|
| doesn't | SHOULD |
Check syntax of field names, with connection exception SYNTAX_ERROR on failure
|
|
| ok | MUST |
Ignore all but first of all identically-named fields within a table
|
|
| ok | MUST | v0-8, 4.2.5.6:
Raise connection exception FRAME_ERROR when incomplete content received
|
|
| ok | MUST | v0-8, 4.2.5.7:
Raise connection exception FRAME_ERROR when content header class does not match method class
|
|
| ok | MUST NOT |
Produce content frames with zero channel number
|
|
| ok | MUST |
Signal connection exception CHANNEL_ERROR if receiving a content frame with zero channel number
|
|
| ok | MUST | v0-8, 4.2.5.8:
Support multiple-frame content bodies
|
|
| doesn't | MAY | v0-8, 4.2.5.9:
Support structured content
|
|
| MUST |
Reject structured content with NOT_IMPLEMENTED, if not supporting structured content
|
||
| MUST |
If supporting structured content, detect weight mismatch, raising FRAME_ERROR if mismatch detected
|
||
| ok | MUST | v0-8, 4.2.5.11:
Always use channel zero for "trace" frames
|
|
| ok | MUST |
Signal FRAME_ERROR on receipt of "trace" frame with nonzero channel
|
|
| ok | MUST |
Discard trace frames without fault if no appropriate trace handler is available
|
|
| ok | MUST | v0-8, 4.2.5.12:
Always use channel zero for "heartbeat" frames
|
|
| ok | MUST |
Signal FRAME_ERROR on receipt of "heartbeat" frame with nonzero channel
|
|
| ok | MUST |
Discard heartbeat frames without fault if heartbeating is not supported or not enabled
|
|
| does | SHOULD | v0-8, 4.3:
Support multiple channels per connection
|
|
| does | SHOULD |
Balance channel traffic fairly within a connection
|
|
| doesn't | SHOULD NOT |
Allow a very busy channel to starve other channels within a connection
|
|
| planned | SHOULD | server | v0-8, 4.6.2:
Log potentially hostile connection attempts, and flag or block hostile clients
|
| ok | MUST | client | domain/consumer tag:
The consumer tag is valid only within the channel from which the consumer was created. I.e. a client MUST NOT create a consumer in one channel and then use it in another.
|
| ok | MUST | client | domain/delivery tag:
The delivery tag is valid only within the channel from which the message was received. I.e. a client MUST NOT receive a message on one channel and then acknowledge it on another.
|
| ok | MUST | domain/delivery tag:
The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, meaning "all messages so far received".
|
|
| does | MAY | server | domain/known hosts:
The server MAY leave this field empty if it knows of no other hosts than itself.
|
| does | SHOULD | domain/peer properties:
The properties SHOULD contain these fields: "product", giving the name of the peer product, "version", giving the name of the peer version, "platform", giving the name of the operating system, "copyright", if appropriate, and "information", giving other general information.
|
|
| planned | SHOULD |
domain/redelivered:
The server SHOULD try to signal redelivered messages when it can. When redelivering a message that was not successfully acknowledged, the server SHOULD deliver it to the original client if possible.
Notes: We plan on supplying a "redelivered" hint in more situations than we currently do. See also rule amq_basic_19.
|
|
| planned | MUST | client |
domain/redelivered:
The client MUST NOT rely on the redelivered field but MUST take it as a hint that the message may already have been processed. A fully robust client must be able to track duplicate received messages on non-transacted, and locally-transacted channels.
Notes: The client already conforms, in that it does not rely on the redelivered field, and we plan on adding duplicate tracking in a future release.
|
| ok | MUST | method/connection/start:
If the client cannot handle the protocol version suggested by the server it MUST close the socket connection.
|
|
| ok | MUST | method/connection/start:
The server MUST provide a protocol version that is lower than or equal to that requested by the client in the protocol header. If the server cannot support the specified protocol it MUST NOT send this method, but MUST close the socket connection.
|
|
| ok | MUST | server | field/connection/locales:
All servers MUST support at least the en_US locale.
|
| planned | SHOULD | field/connection/mechanism:
The client SHOULD authenticate using the highest-level security profile it can handle from the list provided by the server.
|
|
| ok | MUST | server | field/connection/mechanism:
The mechanism field MUST contain one of the security mechanisms proposed by the server in the Start method. If it doesn't, the server MUST close the socket.
|
| ok | MUST | field/connection/frame max:
Until the frame-max has been negotiated, both peers MUST accept frames of up to 4096 octets large. The minimum non-zero value for the frame-max field is 4096.
|
|
| does | MAY | server | field/connection/channel max:
The server MAY ignore the channel-max value or MAY use it for tuning its resource allocation.
|
| ok | MUST | field/connection/frame max:
Until the frame-max has been negotiated, both peers must accept frames of up to 4096 octets large. The minimum non-zero value for the frame-max field is 4096.
|
|
| ok | MUST | client | method/connection/open:
The client MUST open the context before doing any work on the connection.
|
| ok | MUST | server | field/connection/virtual host:
If the server supports multiple virtual hosts, it MUST enforce a full separation of exchanges, queues, and all associated entities per virtual host. An application, connected to a specific virtual host, MUST NOT be able to access resources of another virtual host.
|
| does | SHOULD | field/connection/virtual host:
The server SHOULD verify that the client has permission to access the specified virtual host.
|
|
| doesn't | MAY | server | field/connection/virtual host:
The server MAY configure arbitrary limits per virtual host, such as the number of each type of entity that may be used, per connection and/or in total.
|
| does | SHOULD | field/connection/insist:
When the client uses the insist option, the server SHOULD accept the client connection unless it is technically unable to do so.
|
|
| does | SHOULD | client | method/connection/redirect:
When getting the Connection.Redirect method, the client SHOULD reconnect to the host specified, and if that host is not present, to any of the hosts specified in the known-hosts list.
|
| ok | MUST | method/connection/close:
After sending this method any received method except the Close-OK method MUST be discarded.
|
|
| does | MAY | method/connection/close:
The peer sending this method MAY use a counter or timeout to detect failure of the other peer to respond correctly with the Close-OK method.
|
|
| ok | MUST | method/connection/close:
When a server receives the Close method from a client it MUST delete all server-side resources associated with the client's context. A client CANNOT reconnect to a context after sending or receiving a Close method.
|
|
| does | SHOULD | method/connection/close-ok:
A peer that detects a socket closure without having received a Close-Ok handshake method SHOULD log the error.
|
|
| ok | MUST | method/channel/open:
This method MUST NOT be called when the channel is already open.
|
|
| planned | MAY | client | method/channel/flow:
When a new channel is opened, it is active. Some applications assume that channels are inactive until started. To emulate this behaviour a client MAY open the channel, then pause it.
|
| planned | SHOULD | method/channel/flow:
When sending content data in multiple frames, a peer SHOULD monitor the channel for incoming methods and respond to a Channel.Flow as rapidly as possible.
|
|
| planned | MAY | method/channel/flow:
A peer MAY use the Channel.Flow method to throttle incoming content data for internal reasons, for example, when exchangeing data over a slower connection.
|
|
| doesn't | MAY | method/channel/flow:
The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer that does not respect the request.
|
|
| ok | MUST | method/channel/close:
After sending this method any received method except Channel.Close-OK MUST be discarded.
|
|
| does | MAY | method/channel/close:
The peer sending this method MAY use a counter or timeout to detect failure of the other peer to respond correctly with Channel.Close-OK.
|
|
| does | SHOULD | method/channel/close-ok:
A peer that detects a socket closure without having received a Channel.Close-Ok handshake method SHOULD log the error.
|
|
| ok | MUST | server | method/access/request:
The realm name MUST start with either "/data" (for application resources) or "/admin" (for server administration resources). If the realm starts with any other path, the server MUST raise a connection exception with reply code 403 (access refused).
|
| ok | MUST | server | method/access/request:
The server MUST implement the /data realm and MAY implement the /admin realm. The mapping of resources to realms is not defined in the protocol - this is a server-side configuration issue.
|
| ok | MUST | server | field/access/realm:
If the specified realm is not known to the server, the server must raise a channel exception with reply code 402 (invalid path).
|
| planned | MUST | client | method/access/request-ok:
The client MUST NOT use access tickets except within the same channel as originally granted.
|
| ok | MUST | method/access/request-ok:
The server MUST isolate access tickets per channel and treat an attempt by a client to mix these as a connection exception.
|
|
| ok | MUST | server | amq_exchange_19:
The server MUST implement the direct and fanout exchange types, and predeclare the corresponding exchanges named amq.direct and amq.fanout in each virtual host. The server MUST also predeclare a direct exchange to act as the default exchange for content Publish methods and for default queue bindings.
|
| does | SHOULD | server | amq_exchange_20:
The server SHOULD implement the topic exchange type, and predeclare the corresponding exchange named amq.topic in each virtual host.
|
| planned | MAY | amq_exchange_21:
The server MAY implement the system exchange type, and predeclare the corresponding exchanges named amq.system in each virtual host. If the client attempts to bind a queue to the system exchange, the server MUST raise a connection exception with reply code 507 (not allowed).
|
|
| planned | MUST | amq_exchange_22:
The default exchange MUST be defined as internal, and be inaccessible to the client except by specifying an empty exchange name in a content Publish method. That is, the server MUST NOT let clients make explicit bindings to this exchange.
|
|
| does | SHOULD | server | amq_exchange_23:
The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose no limit except as defined by available resources.
|
| ok | MUST | client | field/exchange/ticket:
The client MUST provide a valid access ticket giving "active" access to the realm in which the exchange exists or will be created, or "passive" access if the if-exists flag is set.
|
| ok | MUST | amq_exchange_15:
Exchange names starting with "amq." are reserved for predeclared and standardised exchanges. If the client attempts to create an exchange starting with "amq.", the server MUST raise a channel exception with reply code 403 (access refused).
|
|
| ok | MUST | server | amq_exchange_16:
If the exchange already exists with a different type, the server MUST raise a connection exception with a reply code 507 (not allowed).
|
| ok | MUST | server | amq_exchange_18:
If the server does not support the requested exchange type it MUST raise a connection exception with a reply code 503 (command invalid).
|
| ok | MUST | server | amq_exchange_05:
If set, and the exchange does not already exist, the server MUST raise a channel exception with reply code 404 (not found).
|
| ok | MUST | server | amq_exchange_24:
The server MUST support both durable and transient exchanges.
|
| ok | MUST | server | field/exchange/durable:
The server MUST ignore the durable field if the exchange already exists.
|
| planned | SHOULD | amq_exchange_02:
The server SHOULD allow for a reasonable delay between the point when it determines that an exchange is not being used (or no longer used), and the point when it deletes the exchange. At the least it must allow a client to create an exchange and then bind a queue to it, with a small but non-zero delay between these two actions.
|
|
| ok | MUST | server | amq_exchange_25:
The server MUST ignore the auto-delete field if the exchange already exists.
|
| ok | MUST | client | field/exchange/ticket:
The client MUST provide a valid access ticket giving "active" access rights to the exchange's access realm.
|
| ok | MUST | amq_exchange_11:
The exchange MUST exist. Attempting to delete a non-existing exchange causes a channel exception.
|
|
| does | SHOULD | server | amq_exchange_12:
If set, the server SHOULD delete the exchange but only if it has no queue bindings.
|
| does | SHOULD | server | amq_exchange_13:
If set, the server SHOULD raise a channel exception if the exchange is in use.
|
| planned | MUST | server | amq_queue_33:
A server MUST allow any content class to be sent to any queue, in any mix, and queue and delivery these content classes independently. Note that all methods that fetch content off queues are specific to a given content class.
|
| ok | MUST | server | amq_queue_34:
The server MUST create a default binding for a newly-created queue to the default exchange, which is an exchange of type 'direct'.
|
| does | SHOULD | server | amq_queue_35:
The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no limit except as defined by available resources.
|
| does | MAY, MUST | amq_queue_10:
The queue name MAY be empty, in which case the server MUST create a new queue with a unique generated name and return this to the client in the Declare-Ok method.
|
|
| planned | MUST | server | amq_queue_32:
Queue names starting with "amq." are reserved for predeclared and standardised server queues. If the queue name starts with "amq." and the passive option is zero, the server MUST raise a connection exception with reply code 403 (access refused).
|
| ok | MUST | server | amq_queue_05:
If set, and the queue does not already exist, the server MUST respond with a reply code 404 (not found) and raise a channel exception.
|
| ok | MUST | server | amq_queue_03:
The server MUST recreate the durable queue after a restart.
|
| ok | MUST | server | amq_queue_36:
The server MUST support both durable and transient queues.
|
| ok | MUST | server | amq_queue_37:
The server MUST ignore the durable field if the queue already exists.
|
| ok | MUST | server | amq_queue_38:
The server MUST support both exclusive (private) and non-exclusive (shared) queues.
|
| ok | MUST | server | amq_queue_04:
The server MUST raise a channel exception if 'exclusive' is specified and the queue already exists and is owned by a different connection.
|
| planned | SHOULD | amq_queue_02:
The server SHOULD allow for a reasonable delay between the point when it determines that a queue is not being used (or no longer used), and the point when it deletes the queue. At the least it must allow a client to create a queue and then create a consumer to read from it, with a small but non-zero delay between these two actions. The server should equally allow for clients that may be disconnected prematurely, and wish to re-consume from the same queue without losing messages. We would recommend a configurable timeout, with a suitable default value being one minute.
|
|
| ok | MUST | server | amq_queue_31:
The server MUST ignore the auto-delete field if the queue already exists.
|
| ok | MUST | server | amq_queue_25:
A server MUST allow ignore duplicate bindings - that is, two or more bind methods for a specific queue, with identical arguments - without treating these as an error.
|
| ok | MUST | server | amq_queue_39:
If a bind fails, the server MUST raise a connection exception.
|
| ok | MUST | amq_queue_12:
The server MUST NOT allow a durable queue to bind to a transient exchange. If the client attempts this the server MUST raise a channel exception.
|
|
| does | SHOULD | server | amq_queue_13:
Bindings for durable queues are automatically durable and the server SHOULD restore such bindings after a server restart.
|
| planned | MUST | amq_queue_17:
If the client attempts to an exchange that was declared as internal, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| does | SHOULD | server | amq_queue_40:
The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit except as defined by available resources.
|
| ok | MUST | field/queue/queue:
If the client did not previously declare a queue, and the queue name in this method is empty, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST | server | amq_queue_26:
field/queue/queue:
If the queue does not exist the server MUST raise a channel exception with reply code 404 (not found).
|
| ok | MUST | server | amq_queue_14:
If the exchange does not exist the server MUST raise a channel exception with reply code 404 (not found).
|
| ok | MUST | amq_queue_15:
A call to purge MUST result in an empty queue.
|
|
| ok | MUST | amq_queue_41:
On transacted channels the server MUST not purge messages that have already been sent to a client but not yet acknowledged.
|
|
| doesn't | MAY | server | amq_queue_42:
The server MAY implement a purge queue or log that allows system administrators to recover accidentally-purged messages. The server SHOULD NOT keep purged messages in the same storage spaces as the live messages since the volumes of purged messages may get very large.
|
| ok | MUST | client | field/queue/ticket:
The client MUST provide a valid access ticket giving "read" access rights to the queue's access realm. Note that purging a queue is equivalent to reading all messages and discarding them.
|
| ok | MUST | field/queue/queue:
If the client did not previously declare a queue, and the queue name in this method is empty, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST | amq_queue_16:
field/queue/queue:
The queue must exist. Attempting to purge a non-existing queue causes a channel exception.
|
|
| planned | SHOULD | server | amq_queue_43:
The server SHOULD use a dead-letter queue to hold messages that were pending on a deleted queue, and MAY provide facilities for a system administrator to move these messages back to an active queue.
|
| ok | MUST | field/queue/queue:
If the client did not previously declare a queue, and the queue name in this method is empty, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST | amq_queue_21:
field/queue/queue:
The queue must exist. Attempting to delete a non-existing queue causes a channel exception.
|
|
| ok | MUST | server | amq_queue_29:
The server MUST respect the if-unused flag when deleting a queue.
|
| ok | MUST | server | amq_queue_30:
The server MUST respect the if-unused flag when deleting a queue.
|
| does | SHOULD | server | amq_basic_08:
class/basic/basic:
The server SHOULD respect the persistent property of basic messages and SHOULD make a best-effort to hold persistent basic messages on a reliable storage mechanism.
|
| ok | MUST NOT, MAY | server | amq_basic_09:
class/basic/basic:
The server MUST NOT discard a persistent basic message in case of a queue overflow. The server MAY use the Channel.Flow method to slow or stop a basic message publisher when necessary.
|
| doesn't | MAY | server | amq_basic_10:
class/basic/basic:
The server MAY overflow non-persistent basic messages to persistent storage and MAY discard or dead-letter non-persistent basic messages on a priority basis if the queue size exceeds some configured limit.
|
| planned | MUST, MAY | server | amq_basic_11:
class/basic/basic:
The server MUST implement at least 2 priority levels for basic messages, where priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority levels.
|
| planned | MUST | server | amq_basic_12:
class/basic/basic:
The server MUST deliver messages of the same priority in order irrespective of their individual persistence.
|
| ok | MUST | server | amq_basic_13:
class/basic/basic:
The server MUST support both automatic and explicit acknowledgements on Basic content.
|
| planned | MUST | amq_basic_17:
field/basic/prefetch size:
The server MUST ignore this setting when the client is not processing any messages - i.e. the prefetch size does not limit the transfer of single messages to a client, only the sending in advance of more messages while the client still has one or more unacknowledged messages.
|
|
| planned | MUST NOT, MAY | amq_basic_18:
field/basic/prefetch count:
The server MAY send less data in advance than allowed by the client's specified prefetch windows but it MUST NOT send more.
|
|
| does | SHOULD | server | amq_basic_01:
method/basic/consume:
The server SHOULD support at least 16 consumers per queue, unless the queue was declared as private, and ideally, impose no limit except as defined by available resources.
|
| ok | MUST | client | field/basic/ticket:
The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue.
|
| ok | MUST | field/basic/queue:
If the client did not previously declare a queue, and the queue name in this method is empty, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST NOT | todo:
field/basic/consumer tag:
The tag MUST NOT refer to an existing consumer. If the client attempts to create two consumers with the same non-empty tag the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST | server | amq_basic_02:
field/basic/exclusive:
If the server cannot grant exclusive access to the queue when asked, - because there are other consumers active - it MUST raise a channel exception with return code 403 (access refused).
|
| ok | client | todo:
method/basic/cancel:
If the queue no longer exists when the client sends a cancel command, or the consumer has been cancelled for other reasons, this command has no effect.
|
|
| ok | MUST | client | field/basic/ticket:
The client MUST provide a valid access ticket giving "write" access rights to the access realm for the exchange.
|
| ok | MUST | server | amq_basic_06:
field/basic/exchange:
The server MUST accept a blank exchange name to mean the default exchange.
|
| planned | MUST | server | amq_basic_14:
field/basic/exchange:
If the exchange was declared as an internal exchange, the server MUST raise a channel exception with a reply code 403 (access refused).
|
| doesn't | MUST, MAY | amq_basic_15:
field/basic/exchange:
The exchange MAY refuse basic content in which case it MUST raise a channel exception with reply code 540 (not implemented).
|
|
| does | SHOULD | server | amq_basic_07:
field/basic/mandatory:
The server SHOULD implement the mandatory flag.
|
| does | SHOULD | server | amq_basic_16:
field/basic/immediate:
The server SHOULD implement the immediate flag.
|
| planned | SHOULD | amq_basic_19:
method/basic/deliver:
The server SHOULD track the number of times a message has been delivered to clients and when a message is redelivered a certain number of times - e.g. 5 times - without being acknowledged, the server SHOULD consider the message to be unprocessable (possibly causing client applications to abort), and move the message to a dead letter queue.
|
|
| ok | MUST | client | field/basic/ticket:
The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue.
|
| ok | MUST | field/basic/queue:
If the client did not previously declare a queue, and the queue name in this method is empty, the server MUST raise a connection exception with reply code 530 (not allowed).
|
|
| ok | MUST | server | amq_basic_20:
field/basic/multiple:
The server MUST validate that a non-zero delivery-tag refers to an delivered message, and raise a channel exception if this is not the case.
|
| planned | SHOULD | server | amq_basic_21:
method/basic/reject:
The server SHOULD be capable of accepting and process the Reject method while sending message content with a Deliver or Get-Ok method. I.e. the server should read and process incoming methods while sending output frames. To cancel a partially-send content, the server sends a content body frame of size 1 (i.e. with no data except the frame-end octet).
|
| planned | SHOULD | amq_basic_22:
method/basic/reject:
The server SHOULD interpret this method as meaning that the client is unable to process the message at this time.
|
|
| ok | MUST NOT, MAY | client | method/basic/reject:
A client MUST NOT use this method as a means of selecting messages to process. A rejected message MAY be discarded or dead-lettered, not necessarily passed to another client.
|
| planned | MUST NOT, MAY | amq_basic_23:
field/basic/requeue:
The server MUST NOT deliver the message to the same client within the context of the current channel. The recommended strategy is to attempt to deliver the message to an alternative consumer, and if that is not possible, to move the message to a dead-letter queue. The server MAY use more sophisticated tracking to hold the message on the queue and redeliver it to the same client at a later stage.
|
|
| ok | MUST | server | method/basic/recover:
The server MUST set the redelivered flag on all messages that are resent.
|
| ok | MUST | server | method/basic/recover:
The server MUST raise a channel exception if this is called on a transacted channel.
|
| planned | SHOULD | client | class/tx/tx:
An client using standard transactions SHOULD be able to track all messages received within a reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT pass these to the application layer.
|