AMQ Protocol 0.80 Indicates that the method completed successfully. This reply code is reserved for future use - the current protocol design does not use positive confirmation and reply codes are sent only in case of an error. The client asked for a specific message that is no longer available. The message was delivered to another client, or was purged from the queue for some other reason. The client attempted to transfer content larger than the server could accept at the present time. The client may retry at a later time. An operator intervened to close the connection for some reason. The client may retry at some later date. The client tried to work with an unknown virtual host or cluster. The client attempted to work with a server entity to which it has no due to security settings. The client attempted to work with a server entity that does not exist. The client attempted to work with a server entity to which it has no access because another client is working with it. The client sent a malformed frame that the server could not decode. This strongly implies a programming error in the client. The client sent a frame that contained illegal values for one or more fields. This strongly implies a programming error in the client. The client sent an invalid sequence of frames, attempting to perform an operation that was considered invalid by the server. This usually implies a programming error in the client. The client attempted to work with a channel that had not been correctly opened. This most likely indicates a fault in the client layer. The server could not complete the method because it lacked sufficient resources. This may be due to the client creating too many of some type of entity. The client tried to work with some entity in a manner that is prohibited by the server, due to security settings or by some other criteria. The client tried to use functionality that is not implemented in the server. The server could not complete the method because of an internal error. The server may require intervention by an operator in order to resume normal operations. access ticket granted by server An access ticket granted by the server for a certain set of access rights within a specific realm. Access tickets are valid within the channel where they were created, and expire when the channel closes. consumer tag Identifier for the consumer, valid within the current connection. 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. server-assigned delivery tag The server-assigned and channel-specific 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. The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, meaning "all messages so far received". exchange name The exchange name is a client-selected string that identifies the exchange for publish methods. Exchange names may consist of any mixture of digits, letters, and underscores. Exchange names are scoped by the virtual host. list of known hosts Specifies the list of equivalent or alternative hosts that the server knows about, which will normally include the current server itself. Clients can cache this information and use it when reconnecting to a server after a failure. The server MAY leave this field empty if it knows of no other hosts than itself. no acknowledgement needed If this field is set the server does not expect acknowledgments for messages. That is, when a message is delivered to the client the server automatically and silently acknowledges it on behalf of the client. This functionality increases performance but at the cost of reliability. Messages can get lost if a client dies before it can deliver them to the application. do not deliver own messages If the no-local field is set the server will not send messages to the client that published them. Must start with a slash "/" and continue with path names separated by slashes. A path name consists of any combination of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. This string provides a set of peer properties, used for identification, debugging, and general information. 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. queue name The queue name identifies the queue within the vhost. Queue names may consist of any mixture of digits, letters, and underscores. message is being redelivered This indicates that the message has been previously delivered to this or another client. 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. 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. reply code from server The reply code. The AMQ reply codes are defined in AMQ RFC 011. localised reply text The localised reply text. This text can be logged as an aid to resolving issues. work with socket connections The connection class provides methods for a client to establish a network connection to a server, and for both peers to operate the connection thereafter. connection = open-connection *use-connection close-connection open-connection = C:protocol-header S:START C:START-OK *challenge S:TUNE C:TUNE-OK C:OPEN S:OPEN-OK | S:REDIRECT challenge = S:SECURE C:SECURE-OK use-connection = *channel close-connection = C:CLOSE S:CLOSE-OK / S:CLOSE C:CLOSE-OK start connection negotiation This method starts the connection negotiation process by telling the client the protocol version that the server proposes, along with a list of security mechanisms which the client can use for authentication. If the client cannot handle the protocol version suggested by the server it MUST close the socket connection. 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. protocol major version The protocol major version that the server agrees to use, which cannot be higher than the client's major version. protocol major version The protocol minor version that the server agrees to use, which cannot be higher than the client's minor version. server properties available security mechanisms A list of the security mechanisms that the server supports, delimited by spaces. Currently ASL supports these mechanisms: PLAIN. available message locales A list of the message locales that the server supports, delimited by spaces. The locale defines the language in which the server will send reply texts. All servers MUST support at least the en_US locale. select security mechanism and locale This method selects a SASL security mechanism. ASL uses SASL (RFC2222) to negotiate authentication and encryption. client properties selected security mechanism A single security mechanisms selected by the client, which must be one of those specified by the server. The client SHOULD authenticate using the highest-level security profile it can handle from the list provided by the server. 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. security response data A block of opaque data passed to the security mechanism. The contents of this data are defined by the SASL security mechanism. For the PLAIN security mechanism this is defined as a field table holding two fields, LOGIN and PASSWORD. selected message locale A single message local selected by the client, which must be one of those specified by the server. security mechanism challenge The SASL protocol works by exchanging challenges and responses until both peers have received sufficient information to authenticate each other. This method challenges the client to provide more information. security challenge data Challenge information, a block of opaque binary data passed to the security mechanism. security mechanism response This method attempts to authenticate, passing a block of SASL data for the security mechanism at the server side. security response data A block of opaque data passed to the security mechanism. The contents of this data are defined by the SASL security mechanism. propose connection tuning parameters This method proposes a set of connection configuration values to the client. The client can accept and/or adjust these. proposed maximum channels The maximum total number of channels that the server allows per connection. Zero means that the server does not impose a fixed limit, but the number of allowed channels may be limited by available server resources. proposed maximum frame size The largest frame size that the server proposes for the connection. The client can negotiate a lower value. Zero means that the server does not impose any specific limit but may reject very large frames if it cannot allocate resources for them. 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. desired heartbeat delay The delay, in seconds, of the connection heartbeat that the server wants. Zero means the server does not want a heartbeat. negotiate connection tuning parameters This method sends the client's connection tuning parameters to the server. Certain fields are negotiated, others provide capability information. negotiated maximum channels The maximum total number of channels that the client will use per connection. May not be higher than the value specified by the server. The server MAY ignore the channel-max value or MAY use it for tuning its resource allocation. negotiated maximum frame size The largest frame size that the client and server will use for the connection. Zero means that the client does not impose any specific limit but may reject very large frames if it cannot allocate resources for them. Note that the frame-max limit applies principally to content frames, where large contents can be broken into frames of arbitrary size. 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. desired heartbeat delay The delay, in seconds, of the connection heartbeat that the client wants. Zero means the client does not want a heartbeat. open connection to virtual host This method opens a connection to a virtual host, which is a collection of resources, and acts to separate multiple application domains within a server. The client MUST open the context before doing any work on the connection. virtual host name The name of the virtual host to work with. 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. The server SHOULD verify that the client has permission to access the specified 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. required capabilities The client may specify a number of capability names, delimited by spaces. The server can use this string to how to process the client's connection request. insist on connecting to server In a configuration with multiple load-sharing servers, the server may respond to a Connection.Open method with a Connection.Redirect. The insist option tells the server that the client is insisting on a connection to the specified server. When the client uses the insist option, the server SHOULD accept the client connection unless it is technically unable to do so. signal that the connection is ready This method signals to the client that the connection is ready for use. asks the client to use a different server This method redirects the client to another server, based on the requested virtual host and/or capabilities. 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. server to connect to Specifies the server to connect to. This is an IP address or a DNS name, optionally followed by a colon and a port number. If no port number is specified, the client should use the default port number for the protocol. request a connection close This method indicates that the sender wants to close the connection. This may be due to internal conditions (e.g. a forced shut-down) or due to an error handling a specific method, i.e. an exception. When a close is due to an exception, the sender provides the class and method id of the method which caused the exception. After sending this method any received method except the Close-OK method MUST be discarded. 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. 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. failing method class When the close is provoked by a method exception, this is the class of the method. failing method ID When the close is provoked by a method exception, this is the ID of the method. confirm a connection close This method confirms a Connection.Close method and tells the recipient that it is safe to release resources for the connection and close the socket. A peer that detects a socket closure without having received a Close-Ok handshake method SHOULD log the error. work with channels The channel class provides methods for a client to establish a virtual connection - a channel - to a server and for both peers to operate the virtual connection thereafter. channel = open-channel *use-channel close-channel open-channel = C:OPEN S:OPEN-OK use-channel = C:FLOW S:FLOW-OK / S:FLOW C:FLOW-OK / S:ALERT / functional-class close-channel = C:CLOSE S:CLOSE-OK / S:CLOSE C:CLOSE-OK open a channel for use This method opens a virtual connection (a channel). This method MUST NOT be called when the channel is already open. out-of-band settings Configures out-of-band transfers on this channel. The syntax and meaning of this field will be formally defined at a later date. signal that the channel is ready This method signals to the client that the channel is ready for use. enable/disable flow from peer This method asks the peer to pause or restart the flow of content data. This is a simple flow-control mechanism that a peer can use to avoid oveflowing its queues or otherwise finding itself receiving more messages than it can process. Note that this method is not intended for window control. The peer that receives a request to stop sending content should finish sending the current content, if any, and then wait until it receives a Flow restart method. 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. 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. 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. The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer that does not respect the request. start/stop content frames If 1, the peer starts sending content frames. If 0, the peer stops sending content frames. confirm a flow method Confirms to the peer that a flow command was received and processed. current flow setting Confirms the setting of the processed flow method: 1 means the peer will start sending or continue to send content frames; 0 means it will not. send a non-fatal warning message This method allows the server to send a non-fatal warning to the client. This is used for methods that are normally asynchronous and thus do not have confirmations, and for which the server may detect errors that need to be reported. Fatal errors are handled as channel or connection exceptions; non-fatal errors are sent through this method. detailed information for warning A set of fields that provide more information about the problem. The meaning of these fields are defined on a per-reply-code basis (TO BE DEFINED). request a channel close This method indicates that the sender wants to close the channel. This may be due to internal conditions (e.g. a forced shut-down) or due to an error handling a specific method, i.e. an exception. When a close is due to an exception, the sender provides the class and method id of the method which caused the exception. After sending this method any received method except Channel.Close-OK MUST be discarded. 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.. failing method class When the close is provoked by a method exception, this is the class of the method. failing method ID When the close is provoked by a method exception, this is the ID of the method. confirm a channel close This method confirms a Channel.Close method and tells the recipient that it is safe to release resources for the channel and close the socket. A peer that detects a socket closure without having received a Channel.Close-Ok handshake method SHOULD log the error. work with access tickets The protocol control access to server resources using access tickets. A client must explicitly request access tickets before doing work. An access ticket grants a client the right to use a specific set of resources - called a "realm" - in specific ways. access = C:REQUEST S:REQUEST-OK request an access ticket This method requests an access ticket for an access realm. The server responds by granting the access ticket. If the client does not have access rights to the requested realm this causes a connection exception. Access tickets are a per-channel resource. 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). 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. name of requested realm If the specified realm is not known to the server, the server must raise a channel exception with reply code 402 (invalid path). request exclusive access Request exclusive access to the realm. If the server cannot grant this - because there are other active tickets for the realm - it raises a channel exception. request passive access Request message passive access to the specified access realm. Passive access lets a client get information about resources in the realm but not to make any changes to them. request active access Request message active access to the specified access realm. Acvtive access lets a client get create and delete resources in the realm. request write access Request write access to the specified access realm. Write access lets a client publish messages to all exchanges in the realm. request read access Request read access to the specified access realm. Read access lets a client consume messages from queues in the realm. grant access to server resources This method provides the client with an access ticket. The access ticket is valid within the current channel and for the lifespan of the channel. The client MUST NOT use access tickets except within the same channel as originally granted. The server MUST isolate access tickets per channel and treat an attempt by a client to mix these as a connection exception. work with exchanges Exchanges match and distribute messages across queues. Exchanges can be configured in the server or created at runtime. exchange = C:DECLARE S:DECLARE-OK / C:DELETE S:DELETE-OK 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. amq_exchange_20 The server SHOULD implement the topic exchange type, and predeclare the corresponding exchange named amq.topic in each virtual host. 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). 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. declare exchange, create if needed This method creates an exchange if it does not already exist, and if the exchange exists, verifies that it is of the correct and expected class. 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. When a client defines a new exchange, this belongs to the access realm of the ticket used. All further work done with that exchange must be done with an access ticket for the same realm. 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. 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). exchange type Each exchange belongs to one of a set of exchange types implemented by the server. The exchange types define the functionality of the exchange - i.e. how messages are routed through it. It is not valid or meaningful to attempt to change the type of an existing exchange. 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). 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). do not create exchange If set, the server will not create the exchange. The client can use this to check whether an exchange exists without modifying the server state. 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). request a durable exchange If set when creating a new exchange, the exchange will be marked as durable. Durable exchanges remain active when a server restarts. Non-durable exchanges (transient exchanges) are purged if/when a server restarts. amq_exchange_24 The server MUST support both durable and transient exchanges. The server MUST ignore the durable field if the exchange already exists. auto-delete when unused If set, the exchange is deleted when all queues have finished using it. 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. amq_exchange_25 The server MUST ignore the auto-delete field if the exchange already exists. create internal exchange If set, the exchange may not be used directly by publishers, but only when bound to other exchanges. Internal exchanges are used to construct wiring that is not visible to applications. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. arguments for declaration A set of arguments for the declaration. The syntax and semantics of these arguments depends on the server implementation. This field is ignored if passive is 1. confirms an exchange declaration This method confirms a Declare method and confirms the name of the exchange, essential for automatically-named exchanges. delete an exchange This method deletes an exchange. When an exchange is deleted all queue bindings on the exchange are cancelled. The client MUST provide a valid access ticket giving "active" access rights to the exchange's access realm. amq_exchange_11 The exchange MUST exist. Attempting to delete a non-existing exchange causes a channel exception. delete only if unused If set, the server will only delete the exchange if it has no queue bindings. If the exchange has queue bindings the server does not delete it but raises a channel exception instead. amq_exchange_12 If set, the server SHOULD delete the exchange but only if it has no queue bindings. amq_exchange_13 If set, the server SHOULD raise a channel exception if the exchange is in use. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm deletion of an exchange This method confirms the deletion of an exchange. work with queues Queues store and forward messages. Queues can be configured in the server or created at runtime. Queues must be attached to at least one exchange in order to receive messages from publishers. queue = C:DECLARE S:DECLARE-OK / C:BIND S:BIND-OK / C:PURGE S:PURGE-OK / C:DELETE S:DELETE-OK 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. declare queue, create if needed This method creates or checks a queue. When creating a new queue the client can specify various properties that control the durability of the queue and its contents, and the level of sharing for the queue. 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'. 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. When a client defines a new queue, this belongs to the access realm of the ticket used. All further work done with that queue must be done with an access ticket for the same realm. The client provides a valid access ticket giving "active" access to the realm in which the queue exists or will be created, or "passive" access if the if-exists flag is set. 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. 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). do not create queue If set, the server will not create the queue. The client can use this to check whether a queue exists without modifying the server state. 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. request a durable queue If set when creating a new queue, the queue will be marked as durable. Durable queues remain active when a server restarts. Non-durable queues (transient queues) are purged if/when a server restarts. Note that durable queues do not necessarily hold persistent messages, although it does not make sense to send persistent messages to a transient queue. amq_queue_03 The server MUST recreate the durable queue after a restart. amq_queue_36 The server MUST support both durable and transient queues. amq_queue_37 The server MUST ignore the durable field if the queue already exists. request an exclusive queue Exclusive queues may only be consumed from by the current connection. Setting the 'exclusive' flag always implies 'auto-delete'. amq_queue_38 The server MUST support both exclusive (private) and non-exclusive (shared) queues. 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. auto-delete queue when unused If set, the queue is deleted when all consumers have finished using it. Last consumer can be cancelled either explicitly or because its channel is closed. If there was no consumer ever on the queue, it won't be deleted. 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. amq_queue_31 The server MUST ignore the auto-delete field if the queue already exists. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. arguments for declaration A set of arguments for the declaration. The syntax and semantics of these arguments depends on the server implementation. This field is ignored if passive is 1. confirms a queue definition This method confirms a Declare method and confirms the name of the queue, essential for automatically-named queues. Reports the name of the queue. If the server generated a queue name, this field contains that name. number of messages in queue Reports the number of messages in the queue, which will be zero for newly-created queues. number of consumers Reports the number of active consumers for the queue. Note that consumers can suspend activity (Channel.Flow) in which case they do not appear in this count. bind queue to an exchange This method binds a queue to an exchange. Until a queue is bound it will not receive any messages. In a classic messaging model, store-and-forward queues are bound to a dest exchange and subscription queues are bound to a dest_wild exchange. 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. amq_queue_39 If a bind fails, the server MUST raise a connection exception. 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. amq_queue_13 Bindings for durable queues are automatically durable and the server SHOULD restore such bindings after a server restart. 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). amq_queue_40 The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit except as defined by available resources. The client provides a valid access ticket giving "active" access rights to the queue's access realm. Specifies the name of the queue to bind. If the queue name is empty, refers to the current queue for the channel, which is the last declared 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). If the queue does not exist the server MUST raise a channel exception with reply code 404 (not found). The name of the exchange to bind to. amq_queue_14 If the exchange does not exist the server MUST raise a channel exception with reply code 404 (not found). message routing key Specifies the routing key for the binding. The routing key is used for routing messages depending on the exchange configuration. Not all exchanges use a routing key - refer to the specific exchange documentation. If the routing key is empty and the queue name is empty, the routing key will be the current queue for the channel, which is the last declared queue. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. arguments for binding A set of arguments for the binding. The syntax and semantics of these arguments depends on the exchange class. confirm bind successful This method confirms that the bind was successful. purge a queue This method removes all messages from a queue. It does not cancel consumers. Purged messages are deleted without any formal "undo" mechanism. amq_queue_15 A call to purge MUST result in an empty queue. amq_queue_41 On transacted channels the server MUST not purge messages that have already been sent to a client but not yet acknowledged. 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. The access ticket must be for the access realm that holds the queue. 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. Specifies the name of the queue to purge. If the queue name is empty, refers to the current queue for the channel, which is the last declared 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). The queue must exist. Attempting to purge a non-existing queue causes a channel exception. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirms a queue purge This method confirms the purge of a queue. number of messages purged Reports the number of messages purged. delete a queue This method deletes a queue. When a queue is deleted any pending messages are sent to a dead-letter queue if this is defined in the server configuration, and all consumers on the queue are cancelled. 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. The client provides a valid access ticket giving "active" access rights to the queue's access realm. Specifies the name of the queue to delete. If the queue name is empty, refers to the current queue for the channel, which is the last declared 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). The queue must exist. Attempting to delete a non-existing queue causes a channel exception. delete only if unused If set, the server will only delete the queue if it has no consumers. If the queue has consumers the server does does not delete it but raises a channel exception instead. amq_queue_29 amq_queue_30 The server MUST respect the if-unused flag when deleting a queue. delete only if empty amq_queue_27 If set, the server will only delete the queue if it has no messages. If the queue is not empty the server raises a channel exception. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm deletion of a queue This method confirms the deletion of a queue. number of messages purged Reports the number of messages purged. work with basic content The Basic class provides methods that support an industry-standard messaging model. basic = C:QOS S:QOS-OK / C:CONSUME S:CONSUME-OK / C:CANCEL S:CANCEL-OK / C:PUBLISH content / S:RETURN content / S:DELIVER content / C:GET ( S:GET-OK content / S:GET-EMPTY ) / C:ACK / C:REJECT 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. 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. 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. 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. The server MUST deliver messages of the same priority in order irrespective of their individual persistence. The server MUST support both automatic and explicit acknowledgements on Basic content. MIME content type MIME content encoding Message header field table Non-persistent (1) or persistent (2) The message priority, 0 to 9 The application correlation identifier The destination to reply to Message expiration specification The application message identifier The message timestamp The message type name The creating user id The creating application id Intra-cluster routing identifier specify quality of service This method requests a specific quality of service. The QoS can be specified for the current channel or for all channels on the connection. The particular properties and semantics of a qos method always depend on the content class semantics. Though the qos method could in principle apply to both peers, it is currently meaningful only for the server. prefetch window in octets The client can request that messages be sent in advance so that when the client finishes processing a message, the following message is already held locally, rather than needing to be sent down the channel. Prefetching gives a performance improvement. This field specifies the prefetch window size in octets. The server will send a message in advance if it is equal to or smaller in size than the available prefetch size (and also falls into other prefetch limits). May be set to zero, meaning "no specific limit", although other prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. 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. prefetch window in messages Specifies a prefetch window in terms of whole messages. This field may be used in combination with the prefetch-size field; a message will only be sent in advance if both prefetch windows (and those at the channel and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. The server MAY send less data in advance than allowed by the client's specified prefetch windows but it MUST NOT send more. apply to entire connection By default the QoS settings apply to the current channel only. If this field is set, they are applied to the entire connection. confirm the requested qos This method tells the client that the requested QoS levels could be handled by the server. The requested QoS applies to all active consumers until a new QoS is defined. start a queue consumer This method asks the server to start a "consumer", which is a transient request for messages from a specific queue. Consumers last as long as the channel they were created on, or until the client cancels them. 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. The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue. Specifies the name of the queue to consume from. If the queue name is null, refers to the current queue for the channel, which is the last declared 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). Specifies the identifier for the consumer. The consumer tag is local to a connection, so two clients can use the same consumer tags. If this field is empty the server will generate a unique 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). request exclusive access Request exclusive consumer access, meaning only this consumer can access the queue. 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). do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a new consumer The server provides the client with a consumer tag, which is used by the client for methods called on the consumer at a later stage. Holds the consumer tag specified by the client or provided by the server. end a queue consumer This method cancels a consumer. This does not affect already delivered messages, but it does mean the server will not send any more messages for that consumer. The client may receive an abitrary number of messages in between sending the cancel method and receiving the cancel-ok reply. 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. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a cancelled consumer This method confirms that the cancellation was completed. publish a message This method publishes a message to a specific exchange. The message will be routed to queues as defined by the exchange configuration and distributed to any active consumers when the transaction, if any, is committed. The client MUST provide a valid access ticket giving "write" access rights to the access realm for the exchange. Specifies the name of the exchange to publish to. The exchange name can be empty, meaning the default exchange. If the exchange name is specified, and that exchange does not exist, the server will raise a channel exception. The server MUST accept a blank exchange name to mean the default exchange. If the exchange was declared as an internal exchange, the server MUST raise a channel exception with a reply code 403 (access refused). The exchange MAY refuse basic content in which case it MUST raise a channel exception with reply code 540 (not implemented). Message routing key Specifies the routing key for the message. The routing key is used for routing messages depending on the exchange configuration. indicate mandatory routing This flag tells the server how to react if the message cannot be routed to a queue. If this flag is set, the server will return an unroutable message with a Return method. If this flag is zero, the server silently drops the message. The server SHOULD implement the mandatory flag. request immediate delivery This flag tells the server how to react if the message cannot be routed to a queue consumer immediately. If this flag is set, the server will return an undeliverable message with a Return method. If this flag is zero, the server will queue the message, but with no guarantee that it will ever be consumed. The server SHOULD implement the immediate flag. return a failed message This method returns an undeliverable message that was published with the "immediate" flag set, or an unroutable message published with the "mandatory" flag set. The reply code and text provide information about the reason that the message was undeliverable. Specifies the name of the exchange that the message was originally published to. Message routing key Specifies the routing key name specified when the message was published. notify the client of a consumer message This method delivers a message to the client, via a consumer. In the asynchronous message delivery model, the client starts a consumer using the Consume method, then the server responds with Deliver methods as and when messages arrive for that consumer. 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. Specifies the name of the exchange that the message was originally published to. Message routing key Specifies the routing key name specified when the message was published. direct access to a queue This method provides a direct access to the messages in a queue using a synchronous dialogue that is designed for specific types of application where synchronous functionality is more important than performance. The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue. Specifies the name of the queue to consume from. If the queue name is null, refers to the current queue for the channel, which is the last declared 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). provide client with a message This method delivers a message to the client following a get method. A message delivered by 'get-ok' must be acknowledged unless the no-ack option was set in the get method. Specifies the name of the exchange that the message was originally published to. If empty, the message was published to the default exchange. Message routing key Specifies the routing key name specified when the message was published. number of messages pending This field reports the number of messages pending on the queue, excluding the message being delivered. Note that this figure is indicative, not reliable, and can change arbitrarily as messages are added to the queue and removed by other clients. indicate no messages available This method tells the client that the queue has no messages available for the client. Cluster id For use by cluster applications, should not be used by client applications. acknowledge one or more messages This method acknowledges one or more messages delivered via the Deliver or Get-Ok methods. The client can ask to confirm a single message or a set of messages up to and including a specific message. acknowledge multiple messages If set to 1, the delivery tag is treated as "up to and including", so that the client can acknowledge multiple messages with a single method. If set to zero, the delivery tag refers to a single message. If the multiple field is 1, and the delivery tag is zero, tells the server to acknowledge all outstanding mesages. 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. reject an incoming message This method allows a client to reject a message. It can be used to interrupt and cancel large incoming messages, or return untreatable messages to their original queue. 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). The server SHOULD interpret this method as meaning that the client is unable to process the message at this time. 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. requeue the message If this field is zero, the message will be discarded. If this bit is 1, the server will attempt to requeue the message. 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. redeliver unacknowledged messages This method asks the broker to redeliver all unacknowledged messages on a specified channel. Zero or more messages may be redelivered. This method is only allowed on non-transacted channels. requeue the message If this field is zero, the message will be redelivered to the original recipient. If this bit is 1, the server will attempt to requeue the message, potentially then delivering it to an alternative subscriber. The server MUST set the redelivered flag on all messages that are resent. The server MUST raise a channel exception if this is called on a transacted channel. work with file content The file class provides methods that support reliable file transfer. File messages have a specific set of properties that are required for interoperability with file transfer applications. File messages and acknowledgements are subject to channel transactions. Note that the file class does not provide message browsing methods; these are not compatible with the staging model. Applications that need browsable file transfer should use Basic content and the Basic class. file = C:QOS S:QOS-OK / C:CONSUME S:CONSUME-OK / C:CANCEL S:CANCEL-OK / C:OPEN S:OPEN-OK C:STAGE content / S:OPEN C:OPEN-OK S:STAGE content / C:PUBLISH / S:DELIVER / S:RETURN / C:ACK / C:REJECT The server MUST make a best-effort to hold file messages on a reliable storage mechanism. The server MUST NOT discard a file message in case of a queue overflow. The server MUST use the Channel.Flow method to slow or stop a file message publisher when necessary. The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority levels. The server MUST support both automatic and explicit acknowledgements on file content. MIME content type MIME content encoding Message header field table The message priority, 0 to 9 The destination to reply to The application message identifier The message filename The message timestamp Intra-cluster routing identifier specify quality of service This method requests a specific quality of service. The QoS can be specified for the current channel or for all channels on the connection. The particular properties and semantics of a qos method always depend on the content class semantics. Though the qos method could in principle apply to both peers, it is currently meaningful only for the server. prefetch window in octets The client can request that messages be sent in advance so that when the client finishes processing a message, the following message is already held locally, rather than needing to be sent down the channel. Prefetching gives a performance improvement. This field specifies the prefetch window size in octets. May be set to zero, meaning "no specific limit". Note that other prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. prefetch window in messages Specifies a prefetch window in terms of whole messages. This is compatible with some file API implementations. This field may be used in combination with the prefetch-size field; a message will only be sent in advance if both prefetch windows (and those at the channel and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. The server MAY send less data in advance than allowed by the client's specified prefetch windows but it MUST NOT send more. apply to entire connection By default the QoS settings apply to the current channel only. If this field is set, they are applied to the entire connection. confirm the requested qos This method tells the client that the requested QoS levels could be handled by the server. The requested QoS applies to all active consumers until a new QoS is defined. start a queue consumer This method asks the server to start a "consumer", which is a transient request for messages from a specific queue. Consumers last as long as the channel they were created on, or until the client cancels them. 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. The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue. Specifies the name of the queue to consume from. If the queue name is null, refers to the current queue for the channel, which is the last declared 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). Specifies the identifier for the consumer. The consumer tag is local to a connection, so two clients can use the same consumer tags. If this field is empty the server will generate a unique 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). request exclusive access Request exclusive consumer access, meaning only this consumer can access the queue. 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 405 (resource locked). do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a new consumer This method provides the client with a consumer tag which it MUST use in methods that work with the consumer. Holds the consumer tag specified by the client or provided by the server. end a queue consumer This method cancels a consumer. This does not affect already delivered messages, but it does mean the server will not send any more messages for that consumer. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a cancelled consumer This method confirms that the cancellation was completed. request to start staging This method requests permission to start staging a message. Staging means sending the message into a temporary area at the recipient end and then delivering the message by referring to this temporary area. Staging is how the protocol handles partial file transfers - if a message is partially staged and the connection breaks, the next time the sender starts to stage it, it can restart from where it left off. staging identifier This is the staging identifier. This is an arbitrary string chosen by the sender. For staging to work correctly the sender must use the same staging identifier when staging the same message a second time after recovery from a failure. A good choice for the staging identifier would be the SHA1 hash of the message properties data (including the original filename, revised time, etc.). message content size The size of the content in octets. The recipient may use this information to allocate or check available space in advance, to avoid "disk full" errors during staging of very large messages. The sender MUST accurately fill the content-size field. Zero-length content is permitted. confirm staging ready This method confirms that the recipient is ready to accept staged data. If the message was already partially-staged at a previous time the recipient will report the number of octets already staged. already staged amount The amount of previously-staged content in octets. For a new message this will be zero. The sender MUST start sending data from this octet offset in the message, counting from zero. The recipient MAY decide how long to hold partially-staged content and MAY implement staging by always discarding partially-staged content. However if it uses the file content type it MUST support the staging methods. stage message content This method stages the message, sending the message content to the recipient from the octet offset specified in the Open-Ok method. publish a message This method publishes a staged file message to a specific exchange. The file message will be routed to queues as defined by the exchange configuration and distributed to any active consumers when the transaction, if any, is committed. The client MUST provide a valid access ticket giving "write" access rights to the access realm for the exchange. Specifies the name of the exchange to publish to. The exchange name can be empty, meaning the default exchange. If the exchange name is specified, and that exchange does not exist, the server will raise a channel exception. The server MUST accept a blank exchange name to mean the default exchange. If the exchange was declared as an internal exchange, the server MUST respond with a reply code 403 (access refused) and raise a channel exception. The exchange MAY refuse file content in which case it MUST respond with a reply code 540 (not implemented) and raise a channel exception. Message routing key Specifies the routing key for the message. The routing key is used for routing messages depending on the exchange configuration. indicate mandatory routing This flag tells the server how to react if the message cannot be routed to a queue. If this flag is set, the server will return an unroutable message with a Return method. If this flag is zero, the server silently drops the message. The server SHOULD implement the mandatory flag. request immediate delivery This flag tells the server how to react if the message cannot be routed to a queue consumer immediately. If this flag is set, the server will return an undeliverable message with a Return method. If this flag is zero, the server will queue the message, but with no guarantee that it will ever be consumed. The server SHOULD implement the immediate flag. staging identifier This is the staging identifier of the message to publish. The message must have been staged. Note that a client can send the Publish method asynchronously without waiting for staging to finish. return a failed message This method returns an undeliverable message that was published with the "immediate" flag set, or an unroutable message published with the "mandatory" flag set. The reply code and text provide information about the reason that the message was undeliverable. Specifies the name of the exchange that the message was originally published to. Message routing key Specifies the routing key name specified when the message was published. notify the client of a consumer message This method delivers a staged file message to the client, via a consumer. In the asynchronous message delivery model, the client starts a consumer using the Consume method, then the server responds with Deliver methods as and when messages arrive for that consumer. 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. Specifies the name of the exchange that the message was originally published to. Message routing key Specifies the routing key name specified when the message was published. staging identifier This is the staging identifier of the message to deliver. The message must have been staged. Note that a server can send the Deliver method asynchronously without waiting for staging to finish. acknowledge one or more messages This method acknowledges one or more messages delivered via the Deliver method. The client can ask to confirm a single message or a set of messages up to and including a specific message. acknowledge multiple messages If set to 1, the delivery tag is treated as "up to and including", so that the client can acknowledge multiple messages with a single method. If set to zero, the delivery tag refers to a single message. If the multiple field is 1, and the delivery tag is zero, tells the server to acknowledge all outstanding mesages. 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. reject an incoming message This method allows a client to reject a message. It can be used to return untreatable messages to their original queue. Note that file content is staged before delivery, so the client will not use this method to interrupt delivery of a large message. The server SHOULD interpret this method as meaning that the client is unable to process the message at this time. 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. requeue the message If this field is zero, the message will be discarded. If this bit is 1, the server will attempt to requeue the message. 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. work with streaming content The stream class provides methods that support multimedia streaming. The stream class uses the following semantics: one message is one packet of data; delivery is unacknowleged and unreliable; the consumer can specify quality of service parameters that the server can try to adhere to; lower-priority messages may be discarded in favour of high priority messages. stream = C:QOS S:QOS-OK / C:CONSUME S:CONSUME-OK / C:CANCEL S:CANCEL-OK / C:PUBLISH content / S:RETURN / S:DELIVER content The server SHOULD discard stream messages on a priority basis if the queue size exceeds some configured limit. The server MUST implement at least 2 priority levels for stream messages, where priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority levels. The server MUST implement automatic acknowledgements on stream content. That is, as soon as a message is delivered to a client via a Deliver method, the server must remove it from the queue. MIME content type MIME content encoding Message header field table The message priority, 0 to 9 The message timestamp specify quality of service This method requests a specific quality of service. The QoS can be specified for the current channel or for all channels on the connection. The particular properties and semantics of a qos method always depend on the content class semantics. Though the qos method could in principle apply to both peers, it is currently meaningful only for the server. prefetch window in octets The client can request that messages be sent in advance so that when the client finishes processing a message, the following message is already held locally, rather than needing to be sent down the channel. Prefetching gives a performance improvement. This field specifies the prefetch window size in octets. May be set to zero, meaning "no specific limit". Note that other prefetch limits may still apply. prefetch window in messages Specifies a prefetch window in terms of whole messages. This field may be used in combination with the prefetch-size field; a message will only be sent in advance if both prefetch windows (and those at the channel and connection level) allow it. transfer rate in octets/second Specifies a desired transfer rate in octets per second. This is usually determined by the application that uses the streaming data. A value of zero means "no limit", i.e. as rapidly as possible. The server MAY ignore the prefetch values and consume rates, depending on the type of stream and the ability of the server to queue and/or reply it. The server MAY drop low-priority messages in favour of high-priority messages. apply to entire connection By default the QoS settings apply to the current channel only. If this field is set, they are applied to the entire connection. confirm the requested qos This method tells the client that the requested QoS levels could be handled by the server. The requested QoS applies to all active consumers until a new QoS is defined. start a queue consumer This method asks the server to start a "consumer", which is a transient request for messages from a specific queue. Consumers last as long as the channel they were created on, or until the client cancels them. 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. Streaming applications SHOULD use different channels to select different streaming resolutions. AMQP makes no provision for filtering and/or transforming streams except on the basis of priority-based selective delivery of individual messages. The client MUST provide a valid access ticket giving "read" access rights to the realm for the queue. Specifies the name of the queue to consume from. If the queue name is null, refers to the current queue for the channel, which is the last declared 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). Specifies the identifier for the consumer. The consumer tag is local to a connection, so two clients can use the same consumer tags. If this field is empty the server will generate a unique 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). request exclusive access Request exclusive consumer access, meaning only this consumer can access the queue. 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 405 (resource locked). do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a new consumer This method provides the client with a consumer tag which it may use in methods that work with the consumer. Holds the consumer tag specified by the client or provided by the server. end a queue consumer This method cancels a consumer. Since message delivery is asynchronous the client may continue to receive messages for a short while after canceling a consumer. It may process or discard these as appropriate. do not send a reply method If set, the server will not respond to the method. The client should not wait for a reply method. If the server could not complete the method it will raise a channel or connection exception. confirm a cancelled consumer This method confirms that the cancellation was completed. publish a message This method publishes a message to a specific exchange. The message will be routed to queues as defined by the exchange configuration and distributed to any active consumers as appropriate. The client MUST provide a valid access ticket giving "write" access rights to the access realm for the exchange. Specifies the name of the exchange to publish to. The exchange name can be empty, meaning the default exchange. If the exchange name is specified, and that exchange does not exist, the server will raise a channel exception. The server MUST accept a blank exchange name to mean the default exchange. If the exchange was declared as an internal exchange, the server MUST respond with a reply code 403 (access refused) and raise a channel exception. The exchange MAY refuse stream content in which case it MUST respond with a reply code 540 (not implemented) and raise a channel exception. Message routing key Specifies the routing key for the message. The routing key is used for routing messages depending on the exchange configuration. indicate mandatory routing This flag tells the server how to react if the message cannot be routed to a queue. If this flag is set, the server will return an unroutable message with a Return method. If this flag is zero, the server silently drops the message. The server SHOULD implement the mandatory flag. request immediate delivery This flag tells the server how to react if the message cannot be routed to a queue consumer immediately. If this flag is set, the server will return an undeliverable message with a Return method. If this flag is zero, the server will queue the message, but with no guarantee that it will ever be consumed. The server SHOULD implement the immediate flag. return a failed message This method returns an undeliverable message that was published with the "immediate" flag set, or an unroutable message published with the "mandatory" flag set. The reply code and text provide information about the reason that the message was undeliverable. Specifies the name of the exchange that the message was originally published to. Message routing key Specifies the routing key name specified when the message was published. notify the client of a consumer message This method delivers a message to the client, via a consumer. In the asynchronous message delivery model, the client starts a consumer using the Consume method, then the server responds with Deliver methods as and when messages arrive for that consumer. Specifies the name of the exchange that the message was originally published to. Specifies the name of the queue that the message came from. Note that a single channel can start many consumers on different queues. work with standard transactions Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never lost, but there is a chance of confirmations being lost, so that messages may be resent. Applications that use standard transactions must be able to detect and ignore duplicate messages. 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. tx = C:SELECT S:SELECT-OK / C:COMMIT S:COMMIT-OK / C:ROLLBACK S:ROLLBACK-OK select standard transaction mode This method sets the channel to use standard transactions. The client must use this method at least once on a channel before using the Commit or Rollback methods. confirm transaction mode This method confirms to the client that the channel was successfully set to use standard transactions. commit the current transaction This method commits all messages published and acknowledged in the current transaction. A new transaction starts immediately after a commit. confirm a successful commit This method confirms to the client that the commit succeeded. Note that if a commit fails, the server raises a channel exception. abandon the current transaction This method abandons all messages published and acknowledged in the current transaction. A new transaction starts immediately after a rollback. confirm a successful rollback This method confirms to the client that the rollback succeeded. Note that if an rollback fails, the server raises a channel exception. work with distributed transactions Distributed transactions provide so-called "2-phase commit". The AMQP distributed transaction model supports the X-Open XA architecture and other distributed transaction implementations. The Dtx class assumes that the server has a private communications channel (not AMQP) to a distributed transaction coordinator. dtx = C:SELECT S:SELECT-OK C:START S:START-OK select standard transaction mode This method sets the channel to use distributed transactions. The client must use this method at least once on a channel before using the Start method. confirm transaction mode This method confirms to the client that the channel was successfully set to use distributed transactions. start a new distributed transaction This method starts a new distributed transaction. This must be the first method on a new channel that uses the distributed transaction mode, before any methods that publish or consume messages. transaction identifier The distributed transaction key. This identifies the transaction so that the AMQP server can coordinate with the distributed transaction coordinator. confirm the start of a new distributed transaction This method confirms to the client that the transaction started. Note that if a start fails, the server raises a channel exception. methods for protocol tunneling. The tunnel methods are used to send blocks of binary data - which can be serialised AMQP methods or other protocol frames - between AMQP peers. tunnel = C:REQUEST / S:REQUEST Message header field table The identity of the tunnelling proxy The name or type of the message being tunnelled The message durability indicator The message broadcast mode sends a tunnelled method This method tunnels a block of binary data, which can be an encoded AMQP method or other data. The binary data is sent as the content for the Tunnel.Request method. meta data for the tunnelled block This field table holds arbitrary meta-data that the sender needs to pass to the recipient. test functional primitives of the implementation The test class provides methods for a peer to test the basic operational correctness of another peer. The test methods are intended to ensure that all peers respect at least the basic elements of the protocol, such as frame and content organisation and field types. We assume that a specially-designed peer, a "monitor client" would perform such tests. test = C:INTEGER S:INTEGER-OK / S:INTEGER C:INTEGER-OK / C:STRING S:STRING-OK / S:STRING C:STRING-OK / C:TABLE S:TABLE-OK / S:TABLE C:TABLE-OK / C:CONTENT S:CONTENT-OK / S:CONTENT C:CONTENT-OK test integer handling This method tests the peer's capability to correctly marshal integer data. octet test value An octet integer test value. short test value A short integer test value. long test value A long integer test value. long-long test value A long long integer test value. operation to test The client must execute this operation on the provided integer test fields and return the result. return sum of test values return lowest of test values return highest of test values report integer test result This method reports the result of an Integer method. result value The result of the tested operation. test string handling This method tests the peer's capability to correctly marshal string data. short string test value An short string test value. long string test value A long string test value. operation to test The client must execute this operation on the provided string test fields and return the result. return concatentation of test strings return shortest of test strings return longest of test strings report string test result This method reports the result of a String method. result value The result of the tested operation. test field table handling This method tests the peer's capability to correctly marshal field table data. field table of test values A field table of test values. operation to test on integers The client must execute this operation on the provided field table integer values and return the result. return sum of numeric field values return min of numeric field values return max of numeric field values operation to test on strings The client must execute this operation on the provided field table string values and return the result. return concatenation of string field values return shortest of string field values return longest of string field values report table test result This method reports the result of a Table method. integer result value The result of the tested integer operation. string result value The result of the tested string operation. test content handling This method tests the peer's capability to correctly marshal content. report content test result This method reports the result of a Content method. It contains the content checksum and echoes the original content as provided. content hash The 32-bit checksum of the content, calculated by adding the content into a 32-bit accumulator.