From cd2d0d3cf3263f5dbf9291d4b755f7fa01c3a798 Mon Sep 17 00:00:00 2001 From: Gordon Sim Date: Tue, 24 Jul 2007 12:46:22 +0000 Subject: latest xml for 0-10 (with some edits to ease the transition from 0-9) git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/trunk@559029 13f79535-47bb-0310-9956-ffa450edef68 --- qpid/specs/amqp-transitional.0-10.xml | 7265 +++++++++++++++++++++++++++++++++ 1 file changed, 7265 insertions(+) create mode 100644 qpid/specs/amqp-transitional.0-10.xml diff --git a/qpid/specs/amqp-transitional.0-10.xml b/qpid/specs/amqp-transitional.0-10.xml new file mode 100644 index 0000000000..eb2d745c35 --- /dev/null +++ b/qpid/specs/amqp-transitional.0-10.xml @@ -0,0 +1,7265 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + When the exchange cannot route the result of a .Publish, most likely due to an invalid routing + key. Only when the mandatory flag is set. + + + + + + When the exchange cannot deliver to a consumer when the immediate flag is set. As a result of + pending data on the queue or the absence of any consumers of the queue. + + + + + + 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. + + + + + + The client attempted to work with a server entity to which it has no access 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 requested a method that was not allowed because some precondition failed. + + + + + + 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. + + + + + + An invalid or illegal argument was passed to a method, and the operation could not proceed. + + + + + + + + XA return code: Normal execution completion (no error). + + + + + + XA return code: The rollback was caused for an unspecified reason. + + + + + + XA return code: A transaction branch took too long. + + + + + + XA return code: The transaction branch may have been heuristically completed. + + + + + + XA return code: The transaction branch has been heuristically committed. + + + + + + XA return code: The transaction branch has been heuristically rolled back. + + + + + + XA return code: The transaction branch has been heuristically committed and rolled back. + + + + + + XA return code: The transaction branch was read-only and has been committed. + + + + + + + + + + Octet of unspecified encoding + + + + + + 8-bit signed integral value (-128 - 127) + + + + + + 8-bit unsigned integral value (0 - 255) + + + + + + 8-bit representation of single character in the iso-8859-15 character set + + + + + + Boolean value (0 represents false, 1 represents true) + + + + + + + + Two octets of unspecified binary encoding + + + + + + 16-bit signed integral value + + + + + + 16-bit unsigned integral value + + + + + + + + Four octets of unspecified binary encoding + + + + + + 32-bit signed integral value + + + + + + 32-bit unsigned integral value + + + + + + Single precision IEEE 754 32-bit floating point + + + + + + Single unicode character in UTF-32 encoding + + + + + + + + Eight octets of unspecified binary encoding + + + + + + 64-bit signed integral value + + + + + + 64-bit unsigned integral value + + + + + + Double precision IEEE 754 floating point + + + + + + Datetime in POSIX time_t format + + + + + + + + Sixteen octets of unspecified binary encoding + + + + + + UUID as defined by RFC4122 + + + + + + + + Thirty two octets of unspecified binary encoding + + + + + + + + Sixty four octets of unspecified binary encoding + + + + + + + + One hundred and twenty eight octets of unspecified binary encoding + + + + + + + + A sequence of up to 255 octets representing opaque binary data + + + + + + A sequence of up to 255 characters in the iso-8859-15 character set + + + + + + A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most + 255 bytes + + + + + + A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most + 255 bytes + + + + + + A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most + 255 bytes (i.e. of 0-63 utf32 characters) + + + + + + + + A sequence of up to 65535 octets representing opaque binary data + + + + + + A sequence of up to 65535 characters in the iso-8859-15 character set + + + + + + A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most + 65535 bytes + + + + + + A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most + 65535 bytes + + + + + + A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most + 65535 bytes (i.e. of 0-16383 utf32 characters) + + + + + + + + A sequence of up to 4294967295 octets representing opaque binary data + + + + + + A sequence of up to 4294967295 characters in the iso-8859-15 character set + + + + + + A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most + 4294967295 bytes + + + + + + A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most + 4294967295 bytes + + + + + + A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most + 4294967295 bytes (i.e. of 0-1073741823 utf32 characters) + + + + + + A field table following the encoding specification given here + + + + + + A sequence is a series of consecutive type-value pairs; using the same type designators as the + field table + + + + + + An array represents a collection of values of the same type. The array is encoded as a single + octet type designator (using the same system as given here for the field table), followed by a + four-octet unsigned integer which represents the number of elements in the collection, + followed by the encoding of that number of values of the given type + + + + + + + + + + Five octets of unspecified binary encoding + + + + + + Encoded as an octet representing the number of decimal places followed by a signed 4 octet + integer. The 'decimals' octet is not signed + + + + + + + + Eight octets of unspecified binary encoding + + + + + + Encoded as an octet representing the number of decimal places followed by a signed 8 octet + integer. The 'decimals' octet is not signed + + + + + + + + + + The void type + + + + + + + + An access ticket granted by the server for a certain set of access rights within a specific + realm. Access tickets are valid within the session where they were created, and expire when + the session closes. + + + + + + + + + + + + + + + Identifier for the consumer, valid within the current connection. + + + + + + The server-assigned and session-specific delivery tag + + + + The delivery tag is valid only within the session from which the message was received. i.e. + A client MUST NOT receive a message on one session 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". + + + + + + + + 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. + + + + This regular expression checks that all characters are one of a-z (lower case), A-Z (upper + case), 0-9 (any digit) and the underscore character. There may be between 1 and 127 of these + characters. + + + + + + + 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. This field may be empty. + + + + + + Message-id is an optional property of UUID type which uniquly identifies a message within the + message system. The message producer is usually responsible for setting the message-id. Note + that the server may discard a message as a duplicate if the value of the message-id matches + that of a previously received message. + + + + A message MUST be unique within a given server instance. A message SHOULD be globally unique + (i.e. across different systems). + + + + + A message ID is immutable. Once set, a message-id MUST NOT be changed or reassigned, even if + the message is replicated, resent or sent to multiple queues. + + + + + + + If this field is set the server does not expect acknowledgements 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. + + + + + + If the no-local field is set the server will not send messages to the connection 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 queue name identifies the queue within the vhost. Queue names must have a length of + between 1 and 255 chatacters inclusive, must start with a digit, letter or underscores ('_') + character, and must be otherwise encoded in UTF-8. + + + + This regular expression checks that the first character is one of a-z (lower case), A-Z + (upper case), 0-9 (any digit) and the underscore character. Following may be between 0 and + 254 characters of any value. + + + + + + + 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. + + + Create a shared queue and publish a message to the queue. Consume the message using explicit + acknowledgements, but do not acknowledge the message. Close the connection, reconnect, and + consume from the queue again. The message should arrive with the redelivered flag set. + + + + + The client MUST NOT rely on the redelivered field but should 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 sessions. + + + + + + + Serial number defined in RFC1982 which defines the arithmatic, operators and ranges of such + numbers. + + + + + + The reply code. The AMQ reply codes are defined as constants at the start of this formal + specification. + + + + + + + The localised reply text. This text can be logged as an aid to resolving issues. + + + + + + + + + Duration of an event or process measured in milliseconds. + + + + + + Offset in bytes into a message body. + + + + + + Identifier to be used as a reference to a message body. + + + + + + Specifies the destination to which the message is to be transferred. The destination can be + empty, meaning the default exchange or consumer. + + + + + + Code specifying the reason for a message reject. + + + + The reject code must be one of 0 (generic) or 1 (immediate delivery was attempted but + failed). + + + + + + + String describing the reason for a message transfer rejection. + + + + + + A security token used for authentication, replay prevention, and encrypted message bodies. + + + + + + + + An xid uniquely identifies a transaction branch. + + + + + xid contains a format identifier, two length fields and a data field: + + format_id long + + gtrid_length octet + + bqual_length octet + + data gtrid_length + bqual_length + + + 4 1 1 g b + +---+---+---+---+---+---+---+- -+---+---+- -+---+ + | format_id | g | b | txn-id | br-id | + +---+---+---+---+---+---+---+- -+---+---+- -+---+ + 0 4 5 6 6+g 6+g+b + + + format_id: an implementation specific format identifier + + gtrid_length: how many bytes of this form the transaction id + + bqual_length: how many bytes of this form the branch id + + data: a sequence of octets of at most 128 bytes containing the txn id and the + branch id + + Note - The sum of the two lengths must equal the length of the data field. + + + + + + + + + Detached-lifetime is an integer encoded as follows: + + * the maximum representable value means unbounded - the maximum length permitted by the peer + + * otherwise, any other value (including zero) is the number of seconds the session's state + is retained during periods when no channel (or equivalent) is attached to the session + (DetachedLifetimeFinite above). + + + + + + + + + + + + + + + + + + + + Content of a message. It should be considered opaque binary data. The length of the message is + determined from the context of this type (the message length field of the message.transfer + method). + + + + + + Set of pairs of RFC-1982 numbers representing a discontinuous range. Each pair represents a + closed interval within the list. + + For example, the set (1,3), (6,6), (8,9) represents the sequence 1,2,3,6,8,9. + + + + + + + + + + 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 + + + + + + + + + + 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 server cannot support the protocol specified in the protocol header, it MUST close + the socket connection without sending any response method. + + + The client sends a protocol header containing an invalid protocol name. The server must + respond by closing the connection. + + + + + + The server MUST provide a protocol version that is lower than or equal to that requested + by the client in the protocol header. + + + The client requests a protocol version that is higher than any valid implementation, e.g. + 9.0. The server must respond with a current protocol version, e.g. 1.0. + + + + + + If the client cannot handle the protocol version suggested by the server it MUST close the + socket connection. + + + The server sends a protocol version that is lower than any valid implementation, e.g. 0.1. + The client must respond by closing the connection. + + + + + + + + + + The protocol version, major component, as transmitted in the AMQP protocol header. This, + combined with the protocol minor component fully describe the protocol version, which is + written in the format major-minor. Hence, with major=1, minor=3, the protocol version + would be "1-3". + + + + + + The protocol version, minor component, as transmitted in the AMQP protocol header. This, + combined with the protocol major component fully describe the protocol version, which is + written in the format major-minor. Hence, with major=1, minor=3, the protocol version + would be "1-3". + + + + + + + The properties SHOULD contain at least these fields: "host", specifying the server host + name or address, "product", giving the name of the server product, "version", giving the + name of the server version, "platform", giving the name of the operating system, + "copyright", if appropriate, and "information", giving other general information. + + + Client connects to server and inspects the server properties. It checks for the presence + of the required fields. + + + + + + + A list of the security mechanisms that the server supports, delimited by spaces. + + + + + + + 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. + + + + + The server MUST support at least the en_US locale. + + + Client connects to server and inspects the locales field. It checks for the presence of + the required locale(s). + + + + + + + + + + + + This method selects a SASL security mechanism. + + + + + + + + + The properties SHOULD contain at least these fields: "product", giving the name of the + client product, "version", giving the name of the client version, "platform", giving the + name of the operating system, "copyright", if appropriate, and "information", giving + other general information. + + + + + + + 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. + + + + + + If the mechanism field does not contain one of the security mechanisms proposed by the + server in the Start method, the server MUST close the connection without sending any + further data. + + + Client connects to server and sends an invalid security mechanism. The server must + respond by closing the connection (a socket close, with no connection close + negotiation). + + + + + + + + + A block of opaque data passed to the security mechanism. The contents of this data are + defined by the SASL security mechanism. + + + + + + + A single message locale selected by the client, which must be one of those specified by + the server. + + + + + + + + + + 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. + + + + + + + + + Challenge information, a block of opaque binary data passed to the security mechanism. + + + + + + + + + This method attempts to authenticate, passing a block of SASL data for the security + mechanism at the server side. + + + + + + + A block of opaque data passed to the security mechanism. The contents of this data are + defined by the SASL security mechanism. + + + + + + + + + + This method proposes a set of connection configuration values to the client. The client can + accept and/or adjust these. + + + + + + + + + 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. + + + + + + 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 + frame-min-size octets large, and the minimum negotiated value for frame-max is also + frame-min-size. + + + Client connects to server and sends a large properties field, creating a frame of + frame-min-size octets. The server must accept this frame. + + + + + + + + The delay, in seconds, of the connection heartbeat that the server wants. Zero means the + server does not want a heartbeat. + + + + + + + + + This method sends the client's connection tuning parameters to the server. Certain fields + are negotiated, others provide capability information. + + + + + + + The maximum total number of channels that the client will use per connection. + + + + + If the client specifies a channel max that is higher than the value provided by the + server, the server MUST close the connection without attempting a negotiated close. The + server may report the error in some fashion to assist implementors. + + + + + + + + + + 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 + frame-min-size octets large, and the minimum negotiated value for frame-max is also + frame-min-size. + + + + + + If the client specifies a frame max that is higher than the value provided by the + server, the server MUST close the connection without attempting a negotiated close. The + server may report the error in some fashion to assist implementors. + + + + + + + The delay, in seconds, of the connection heartbeat that the client wants. Zero means the + client does not want a heartbeat. + + + + + + + + + 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 server may apply + arbitrary limits per virtual host, such as the number of each type of entity that may be + used, per connection and/or in total. + + + + + + + + + + + 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 client can specify zero or more capability names, delimited by spaces. The server can + use this string to how to process the client's connection request. + + + + + + In a configuration with multiple collaborating 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 MUST NOT respond with a + Connection.Redirect method. If it cannot accept the client's connection request it + should respond by closing the connection with a suitable reply code. + + + + + + + + + + This method signals to the client that the connection is ready for use. + + + + + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + + + + + 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. + + + + + + + + + + + + + + When the close is provoked by a method exception, this is the class of the method. + + + + + + When the close is provoked by a method exception, this is the ID of the method. + + + + + + + + + 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. + + + + + + + + + + + + + + The session class provides methods for a client to establish a session with a server and for + both peers to operate the session thereafter. + + + + session = open-session + *use-session + close-session + open-session = C:OPEN S:ATTACHED + / C:RESUME S:ATTACHED + use-session = C:FLOW S:FLOW-OK + / S:FLOW C:FLOW-OK + / S:PING + / C:PONG + / C:PING + / S:PONG + close-session = C:SUSPEND S:DETACHED + / C:CLOSE S:CLOSED + / S:CLOSED + / S:CLOSE C:CLOSED + / C:CLOSED + + + + + + + + + + This method opens a session with the server. + + When the responding peer creates the session, it MUST create a new, appropriately-unique + name for the session and return this to the creator with the rest of the session details. + + Note that the timer controlling a session's automatic expiry, if any, counts down + immediately from the moment of its creation, unless simultaneously with that moment a + channel (or equivalent) is attached to the session. For this reason, it is recommended that + network protocol mappings create sessions simultaneously with the creation and attachment of + their channel-equivalents, since a zero lease time is perfectly valid and indicates that the + session should be destroyed as soon as it first finds itself inactive. + + During the period that a channel (or equivalent) is attached to a session, the session has + no deletion timer. Every time a channel is detached from a session such that the session is + left without any attached network-level entities, the timer is created, set to its declared + value and started. + + Note that if the peer decides that the requested detached-lifetime timeout is too long, + either because the replying peer does not support sessions with non-zero requested timeouts, + or because the requested timeout exceeds some peer-specific limitation, it may substitute an + acceptable value for the detached-lifetime parameter in its reply to the creation request. + An exception is not required. + + + + + Whether the detachment is explicit or implicit, as a result of application action or of + application error, the channel (or equivalent) is detached from its session and the + session timer MUST start counting down as defined in session.open. + + + + + + + The client MUST NOT send session.open on a channel that is already associated with a + session. A "channel busy" connection exception will occur if the channel down which the + open request was sent was already attached to a session. + + + Client sends session.open twice down the same channel. + + + + + + + + + + + + The number of seconds the session's state is retained during periods when no channel (or + equivalent) is attached to the session. + + + + + + + + + This method signals to the client that the session is ready for use. + + Once a session.attached is received by the client, everything is in place for normal + transmission of frames. However, depending on the network protocol mapping in use, the + frame-id be undefined until certain control frames have been sent. Please see the specific + details for each protocol mapping. + + If the attached session was freshly created, the session-id here will be a freshly-generated + UUID. + + Note that the actual session detached-lifetime value, as decided by the peer, is returned + using this method. The value returned may not be the same as that requested in the + corresponding session creation request. In particular, a request for an unbounded + detached-lifetime of may be fulfilled by creation of a session with a bounded actual + lifetime parameter. The requesting peer SHOULD take the lifetime value returned as + authoritative for its own session-related record-keeping. + + + + + + + The session identifier (a UUID) used to identify this session. + + + + + + The number of seconds the session's state is retained during periods when no channel (or + equivalent) is attached to the session. + + + + + + + + + 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 overflowing 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 disable flow method should finish + sending the current content frame, if any, then pause. + + + + + When a new session is opened, it is active (flow is active). Some applications assume that + sessions are inactive until started. To emulate this behaviour a client MAY open the + session, then pause it. + + + + + + When sending content frames, a peer SHOULD monitor the session for incoming methods and + respond to a Session.Flow as rapidly as possible. + + + + + + A peer MAY use the Session.Flow method to throttle incoming content data for internal + reasons, for example, when exchanging data over a slower connection. + + + + + + The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does + not respect the request. This is to prevent badly-behaved clients from overwhelming a + broker. + + + + + + + + + + + If true (1), the peer starts sending content frames. If false (0), the peer stops sending + content frames. + + + + + + + + + Confirms to the peer that a flow command was received and processed. + + + + + + + + Confirms the setting of the processed flow method: true (1) means the peer will start + sending or continue to send content frames; false (0) means it will not. + + + + + + + + + Requests that the receiving peer destroy a session, implicitly detaching any attached + channels or channel-equivalents. + + Note that the reply, session.closed, is also used for asynchronous exception notifications. + For normal closure, such as in response to a session.close request, reason code 200 ("ok") + is to be used. + + + + + + + + + + + + + Notifies the receiver that not only has the current channel been detached from its + underlying session, but that the session itself has been destroyed. + + This method confirms a session.close method and tells the recipient that it is safe to + release resources for the channel. + + Note also that for normal closure, reason code 200 ("ok") is to be used. + + + + + + + + The numeric reply code. + + + + + + The localised reply text. + + + + + + + + + Attaches to an already-existing session. + + + + + A "session busy" exception is returned if the session exists, but is not in a condition + where it can accept the requested attachment. Peers receiving this exception may wish to + retain their session state and retry the session.resume operation after a delay. + + + + + + + + + + The session identifier (a UUID) used to identify this session. + + + + + + + + + [WORK IN PROGRESS] Request that the recipient issue a pong request. + + + + + + + + + + + [WORK IN PROGRESS] Issued after a ping request is received. Note that this is a request + issued after receiving a ping, not a response to receiving a ping. + + + + + + + + + + + Indicates the sending peer wishes to detach from this session, but not necessarily to + destroy it. + + + + + + + + + + + + + Signal detachment from the session. + + + + + + + + + + + Signals receipt of all frames such that frame-id <= cumulative-seen-mark, or frame-id is + in the set defined by seen-frame-set. This can be sent spontaneously, or in response to + either session.solicit-ack or session.high-water-mark. + + Note that an encoded acknowledgement frame carried over the TCP network mapping (in the + absence of cross-protocol use of a session) will never have any entries in its + seen-frame-set. + + + + + + + In order to ensure a canonical wire representation, the value cumulative-seen-mark + + 1 must not be covered by the seen-frame-set. + + + + + + + + + The low-water mark for seen frame-ids. All ids below this mark have been seen; above this + mark, there are gaps containing unseen ids (i.e. discontinuous). By definition, the first + frame-id above this mark (if it exists) is an unseen id. + + + + + + This set contains a sequence of discontinuous seen-frame-ids above the low-water mark + (i.e. above the first gap of unseen ids). In some transports where out-of-order delivery + is not possible (such as TCP), this set will always be empty. + + + + + + + + + Carries information about the highest (most recent) frame-id number that the sending peer + has sent through this session so far. + + The receiver should issue a session.ack at the earliest possible opportunity. + + + + + + + + Highest frame-id sent by the sending peer through this session so far. + + + + + + + + + Requests a session.ack from the peer. The peer should issue one at the earliest possible + opportunity. + + + + + + + + + + + + + + + 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 + + + + + + + + + + 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-session resource. + + + + + + + + + Specifies the name of the realm to which the client is requesting access. The realm is a + configured server-side object that collects a set of resources (exchanges, queues, etc.). + If the session has already requested an access ticket onto this realm, the previous ticket + is destroyed and a new ticket is created with the requested access rights, if allowed. + + + + The client MUST specify a realm that is known to the server. The server makes an + identical response for undefined realms as it does for realms that are defined but + inaccessible to this client. + + + Client specifies an undefined realm. + + + + + + + Request exclusive access to the realm, meaning that this will be the only session that + uses the realm's resources. + + + + The client MUST NOT request exclusive access to a realm that has active access tickets, + unless the same session already had the only access ticket onto that realm. + + + Client opens two sessions and requests exclusive access to the same realm. + + + + + + + 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 message active access to the specified access realm. Active access lets a client + get create and delete resources in the realm. + + + + + + Request write access to the specified access realm. Write access lets a client publish + messages to all exchanges in the realm. + + + + + + Request read access to the specified access realm. Read access lets a client consume + messages from queues in the realm. + + + + + + + + + This method provides the client with an access ticket. The access ticket is valid within the + current session and for the lifespan of the session. + + + + + The client MUST NOT use access tickets except within the same session as originally + granted. + + + Client opens two sessions, requests a ticket on one session and then tries to use that + ticket in a second session. + + + + + + + + A valid access ticket to be used for gaining access to the server. + + + + + + + + + + + Exchanges match and distribute messages across queues. Exchanges can be configured in the + server or created at runtime. + + + + exchange = C:DECLARE + / C:DELETE + + + + + The server MUST implement these standard exchange types: fanout, direct. + + + Client attempts to declare an exchange with each of these standard types. + + + + + + The server SHOULD implement these standard exchange types: topic, headers. + + + Client attempts to declare an exchange with each of these standard types. + + + + + + The server MUST, in each virtual host, pre-declare an exchange instance for each standard + exchange type that it implements, where the name of the exchange instance, if defined, is + "amq." followed by the exchange type name. + + The server MUST, in each virtual host, pre-declare at least two direct exchange instances: + one named "amq.direct", the other with no public name that serves as a default exchange for + publish methods (such as message.transfer). + + + Client creates a temporary queue and attempts to bind to each required exchange instance + ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined). + + + + + + The server MUST pre-declare a direct exchange with no public name to act as the default + exchange for content publish methods (such as message.transfer) and for default queue + bindings. + + + Client checks that the default exchange is active by publishing a message with a suitable + routing key but without specifying the exchange name, then ensuring that the message arrives + in the queue correctly. + + + + + + The default exchange MUST NOT be accessible to the client except by specifying an empty + exchange name in a content publish method (such as message.transfer). That is, the server + must not let clients explicitly bind, unbind, delete, or make any other reference to this + exchange. + + + + + + The server MAY implement other exchange types as wanted. + + + + + + + + + + + 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. + + + + + The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose + no limit except as defined by available resources. + + + The client creates as many exchanges as it can until the server reports an error; the + number of exchanges successfully created must be at least sixteen. + + + + + + + + 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. + + + Client creates access ticket with wrong access rights and attempts to use in this + method. + + + + + + + + + + Exchange names starting with "amq." are reserved for pre-declared and standardised + exchanges. The client MUST NOT attempt to create an exchange starting with "amq.". + + + + + + The name of the exchange MUST NOT be a blank or empty string. + + + + + + + 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. + + + + + Exchanges cannot be redeclared with different types. The client MUST not attempt to + redeclare an existing exchange with a different type than used in the original + Exchange.Declare method. + + + + + + The client MUST NOT attempt to create an exchange with a type that the server does not + support. + + + + + + + + + In the event that a message cannot be routed, this is the name of the exchange to which + the message will be sent. + + + + + If alternate-exchange is not set (its name is an empty string), unroutable messages MUST + be dropped silently. + + + + + + If the alternate-exchange is not empty and if the exchange already exists with a + different alternate-exchange, then the declaration MUST result in a channel error. + + + + + + A message which is being routed to a alternate exchange, MUST NOT be re-routed to a + secondary alternate exchange if it fails to route in the primary alternate exchange. + After such a failure, the message MUST be dropped. This prevents looping. + + + + + + + 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. + + + + If set, and the exchange does not already exist, the server MUST raise a channel + exception with reply code 404 (not found). + + + + + + + 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. + + + + + The server MUST support both durable and transient exchanges. + + + + + + The server MUST ignore the durable field if the exchange already exists. + + + + + + + If set, the exchange is deleted when all queues have finished using it. + + + + The server MUST ignore the auto-delete field if the exchange already exists. + + + + + + + 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. + + + + + + + + + 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. + + + Client creates access ticket with wrong access rights and attempts to use in this + method. + + + + + + + + The client MUST NOT attempt to delete an exchange that does not exist. + + + + + + The name of the exchange MUST NOT be a blank or empty string. + + + + + + + + + + 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. + + + + + + + + + This method is used to request information on a particular exchange. That information is + conveyed by an query-ok method. + + + + + + + + + + The client MUST provide a valid access ticket giving "passive" access rights to the + exchange's access realm. + + + + + + + The name of the exchange for which information is requested. If not specified explicitly + the default exchange is implied. + + + + + + + + + This method is used in response to a query request and conveys information on a particular + exchange. + + + + + + + The type of the exchange. Will be empty if the exchange is not found. + + + + + + The durability of the exchange, i.e. if set the exchange is durable. Will not be set if + the exchange is not found. + + + + + + If set, the exchange for which information was requested is not known. + + + + + + A set of properties of the exchange whose syntax and semantics depends on the server + implementation. Will be empty if the exchange is not found. + + + + + + + + + + + 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 + / C:PURGE S:PURGE-OK + / C:DELETE S:DELETE-OK + / C:UNBIND + + + + + A server MUST allow any content class to be sent to any queue, in any mix, and queue and + deliver these content classes independently. Note that all methods that fetch content off + queues are specific to a given content class. + + + Client creates an exchange of each standard type and several queues that it binds to each + exchange. It must then successfully send each of the standard content types to each of the + available queues. + + + + + + + + + + + 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. + + + + + The server MUST create a default binding for a newly-created queue to the default + exchange, which is an exchange of type 'direct' and use the queue name as the routing key. + + + Client creates a new queue, and then without explicitly binding it to an exchange, + attempts to send a message through the default exchange binding, i.e. publish a message to + the empty exchange, with the queue name as routing key. + + + + + + The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no + limit except as defined by available resources. + + + Client attempts to create as many queues as it can until the server reports an error. The + resulting count must at least be 256. + + + + + + + + + + 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 MUST provide a valid access ticket giving "active" access to the realm in + which the queue exists or will be created. + + + Client creates access ticket with wrong access rights and attempts to use in this + method. + + + + + + + + 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. + + + Client attempts to create several queues with an empty name. The client then verifies + that the server-assigned names are unique and different. + + + + + + Queue names starting with "amq." are reserved for pre-declared and standardised server + queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq." + and the passive option set to zero. + + + A client attempts to create a queue with a name starting with "amq." and with the + passive option set to zero. + + + + + + + If a message is rejected by a queue, then it is sent to the alternate-exchange. A message + may be rejected by a queue for the following reasons: + 1. The queue is deleted when it is not empty; + 2. Immediate delivery of a message is requested, but there are no consumers connected to + the queue. + + + + + If alternate-exchange is not set (its name is an empty string), rejected messages MUST + be dropped silently. + + + + + + If the alternate-exchange is not empty and if the queue already exists with a different + alternate-exchange, then the declaration MUST result in a channel error. + + + + + + The alternate-exchange MUST NOT be deleted while a queue bound to it still exists. Such + an attempt MUST result in a channel exception. + + + + + + + If set, the server will not create the queue. This field allows the client to assert the + presence of a queue without modifying the server state. + + + + + The client MAY ask the server to assert that a queue exists without creating the queue + if not. If the queue does not exist, the server treats this as a failure. + + + Client declares an existing queue with the passive option and expects the server to + respond with a declare-ok. Client then attempts to declare a non-existent queue with the + passive option, and the server must close the channel with the correct reply-code. + + + + + + + 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. + + + + + The server MUST recreate the durable queue after a restart. + + + Client creates a durable queue; server is then restarted. Client then attempts to send + message to the queue. The message should be successfully delivered. + + + + + + The server MUST support both durable and transient queues. + + + A client creates two named queues, one durable and one transient. + + + + + + The server MUST ignore the durable field if the queue already exists. + + + A client creates two named queues, one durable and one transient. The client then + attempts to declare the two queues using the same names again, but reversing the value + of the durable flag in each case. Verify that the queues still exist with the original + durable flag values. + + + + + + + + Exclusive queues can only be used from one connection at a time. Once a connection + declares an exclusive queue, that queue cannot be used by any other connections until the + declaring connection closes. + + + + + The server MUST support both exclusive (private) and non-exclusive (shared) queues. + + + A client creates two named queues, one exclusive and one non-exclusive. + + + + + + If the server receives a declare, bind, consume or get request for a queue that has been + declared as exclusive by an existing client connection, it MUST raise a channel + exception. + + + A client declares an exclusive named queue. A second client on a different connection + attempts to declare a queue of the same name. + + + + + + + If this field is set and the exclusive field is also set, then the queue MUST be deleted + when the connection closes. + + If this field is set and the exclusive field is not set the queue is deleted when all + the 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. + + + + + The server MUST ignore the auto-delete field if the queue already exists. + + + A client creates two named queues, one as auto-delete and one explicit-delete. The + client then attempts to declare the two queues using the same names again, but reversing + the value of the auto-delete field in each case. Verify that the queues still exist with + the original auto-delete flag values. + + + + + + + + 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. + + + + + + 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. + + + + + + + + + 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. + + + + + + + Reports the number of messages in the queue, which will be zero for newly-created queues. + + + + + + Reports the number of active consumers for the queue. Note that consumers can suspend + activity (Session.Flow) in which case they do not appear in this count. + + + + + + + + + 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 direct + exchange and subscription queues are bound to a topic exchange. + + + + + 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. + + + A client binds a named queue to an exchange. The client then repeats the bind (with + identical arguments). + + + + + + + If a bind fails, the server MUST raise a connection exception. + + + + + + The server MUST NOT allow a durable queue to bind to a transient exchange. + + + A client creates a transient exchange. The client then declares a named durable queue and + then attempts to bind the transient exchange to the durable queue. + + + + + + Bindings for durable queues are automatically durable and the server SHOULD restore such + bindings after a server restart. + + + A server creates a named durable queue and binds it to a durable exchange. The server is + restarted. The client then attempts to use the queue/exchange combination. + + + + + + If the client attempts to bind to an exchange that was declared as internal, the server + MUST raise a connection exception with reply code 530 (not allowed). + + + A client attempts to bind a named queue to an internal exchange. + + + + + + The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit + except as defined by available resources. + + + A client creates a named queue and attempts to bind it to 4 different non-internal + exchanges. + + + + + + Where more than one binding exists between a particular exchange instance and a particular + queue instance any given message published to that exchange should be delivered to that + queue at most once, regardless of how many distinct bindings match. + + + A client creates a named queue and binds it to the same topic exchange at least three + times using intersecting routing keys (for example, "animals.*", "animals.dogs.*", + "animal.dogs.chihuahua"). Verify that a message matching all the bindings (using previous + example, routing key = "animal.dogs.chihuahua") is delivered once only. + + + + + + + + + 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 session, which is the last declared queue. + + + + + A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty queue + name) to an exchange. + + + A client attempts to bind with an unnamed (empty) queue name to an exchange. + + + + + + A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously declared) + to an exchange. + + + A client attempts to bind an undeclared queue name to an exchange. + + + + + + + + A client MUST NOT be allowed to bind a queue to a non-existent exchange. + + + A client attempts to bind a named queue to a undeclared exchange. + + + + + + The name of the exchange MUST NOT be a blank or empty string. + + + + + + + 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 queue name is empty, the server uses the last + queue declared on the session. If the routing key is also empty, the server uses this + queue name for the routing key as well. If the queue name is provided but the routing key + is empty, the server does the binding with that empty routing key. The meaning of empty + routing keys depends on the exchange implementation. + + + + If a message queue binds to a direct exchange using routing key K and a publisher sends + the exchange a message with routing key R, then the message MUST be passed to the + message queue if K = R. + + + + + + + A set of arguments for the binding. The syntax and semantics of these arguments depends on + the exchange class. + + + + + + + + + This method unbinds a queue from an exchange. + + + + + If a unbind fails, the server MUST raise a connection exception. + + + + + + + + + + The client provides a valid access ticket giving "active" access rights to the queue's + access realm. + + + + + + + Specifies the name of the queue to unbind. + + + + 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 unbind from. + + + + + If the exchange does not exist the server MUST raise a channel exception with reply code + 404 (not found). + + + + + + The name of the exchange MUST NOT be a blank or empty string. + + + + + + + Specifies the routing key of the binding to unbind. + + + + + + Specifies the arguments of the binding to unbind. + + + + + + + + + This method removes all messages from a queue. It does not cancel consumers. Purged messages + are deleted without any formal "undo" mechanism. + + + + + A call to purge MUST result in an empty queue. + + + + + + On transacted sessions the server MUST not purge messages that have already been sent to a + client but not yet acknowledged. + + + + + + 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 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 session, 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 MUST cause a channel + exception with reply code 404 (not found). + + + + + + + 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. + + + + + + + + + This method confirms the purge of a queue. + + + + + + + Reports the number of messages purged. + + + + + + + + + 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. + + + + + 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 session, 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. If the client attempts to delete a non-existing queue the server + MUST raise a channel exception with reply code 404 (not found). + + + + + + + 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. + + + + + The server MUST respect the if-unused flag when deleting a queue. + + + + + + + If set, the server will only delete the queue if it has no messages. + + + + If the queue is not empty the server MUST raise a channel exception with reply code 406 + (precondition failed). + + + + + + + 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. + + + + + + + + + This method confirms the deletion of a queue. + + + + + + + Reports the number of messages purged. + + + + + + + + + + + [DEPRECATED: replaced by message class.] The Basic class provides methods that support an + industry-standard messaging model. + + + + basic = C:QOS + / 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. + + + Send a persistent message to queue, stop server, restart server and then verify whether + message is still present. Assumes that queues are durable. Persistence without durable + queues makes no sense. + + + + + + The server MUST NOT discard a persistent basic message in case of a queue overflow. + + + Create a queue overflow situation with persistent messages and verify that messages do not + get lost (presumably the server will write them to disk). + + + + + + The server MAY use the Session.Flow method to slow or stop a basic message publisher when + necessary. + + + Create a queue overflow situation with non-persistent messages and verify whether the server + responds with Session.Flow or not. Repeat with persistent messages. + + + + + + The server MAY overflow non-persistent basic messages to persistent storage. + + + + + + + The server 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. + + + Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume + messages from the queue and verify that the first message received was priority 9. + + + + + + The server MAY implement up to 10 priority levels. + + + Send a number of messages with mixed priorities to a queue, so that all priority values from + 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume + from queue and verify how many priority levels emerge. + + + + + + The server MUST deliver messages of the same priority in order irrespective of their + individual persistence. + + + Send a set of messages with the same priority but different persistence settings to a queue. + Consume and verify that messages arrive in same order as originally published. + + + + + + The server MUST support automatic acknowledgements on Basic content, i.e. consumers with the + no-ack field set to FALSE. + + + Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to + the queue. Consume the messages and verify that all messages are received. + + + + + + The server MUST support explicit acknowledgements on Basic content, i.e. consumers with the + no-ack field set to TRUE. + + + Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to + the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, + and consume from the queue. Verify that the remaining messages are received. + + + + + + + + + + + + + + + + + + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] This method requests a specific quality of + service. The QoS can be specified for the current session or for all sessions 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. + + + + + + + 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 within the session. 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. + + + Define a QoS prefetch-size limit and send a single message that exceeds that limit. + Verify that the message arrives correctly. + + + + + + + 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 session 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. + + + Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send + multiple messages that exceed the prefetch size. Verify that no more than one message + arrives at once. + + + + + + + By default the QoS settings apply to the current session only. If this field is set, they + are applied to the entire connection. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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 session they were created on, or until the client cancels them. + + + + + The server SHOULD support at least 16 consumers per queue, and ideally, impose no limit + except as defined by available resources. + + + Create a queue and create consumers on that queue until the server closes the connection. + Verify that the number of consumers created was at least sixteen and report the total + number. + + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to the realm + for the queue from which the message will be consumed. + + + Attempt to create a consumer with an invalid (non-zero) access ticket. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, which is the last declared queue. + + + + If the queue name is empty the client MUST have previously declared a queue using this + session. + + + Attempt to create a consumer with an empty queue name and no previously declared queue + on the session. + + + + + + + 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 client MUST NOT specify a tag that refers to an existing consumer. + + + Attempt to create two consumers with the same non-empty tag. + + + + + + The consumer tag is valid only within the session from which the consumer was created. + i.e. A client MUST NOT create a consumer in one session and then use it in another. + + + Attempt to create a consumer in one session, then use in another session, in which + consumers have also been created (to test that the server uses unique consumer tags). + + + + + + + + + + + Request exclusive consumer access, meaning only this consumer can access the queue. + + + + + The client MUST NOT gain exclusive access to a queue that already has active consumers. + + + Open two connections to a server, and in one connection create a shared (non-exclusive) + queue and then consume from the queue. In the second connection attempt to consume from + the same queue using the exclusive option. + + + + + + + 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. + + + + + + A set of arguments for the consume. The syntax and semantics of these arguments depends on + the providers implementation. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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 arbitrary number of messages in + between sending the cancel method and receiving the cancel-ok reply. + + + + + If the queue does not exist the server MUST ignore the cancel method, so long as the + consumer tag is valid for that session. + + + + + + + + + + + + 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. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] This method confirms that the cancellation + was completed. + + + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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 "passive" access rights to the + realm for the exchange and "write" access rights to the realm for the queue to which the + message will be published. + + + + + + + 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). + + + + + + + Specifies the routing key for the message. The routing key is used for routing messages + depending on the exchange configuration. + + + + + + If the reject-unroutable flag is set, then at the time of publishing the broker + determines if the message will be routed to any queues. If it will not be routed to any + queue then the broker responds with a basic.reject. + + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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 from which the message will be obtained. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, 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). + + + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + 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. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] This method tells the client that the queue + has no messages available for the client. + + + + + + + + For use by cluster applications, should not be used by client applications. + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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. + + + + + + + + + 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 messages. + + + + + The server MUST validate that a non-zero delivery-tag refers to a delivered message, and + raise a channel exception if this is not the case. + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] 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 processing 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. + + + + + + + + + + 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 session. 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. + + + + + + + + + + [DEPRECATED: Basic replaced by message class.] This method asks the broker to redeliver all + unacknowledged messages on a specified session. Zero or more messages may be redelivered. + This method is only allowed on non-transacted sessions. + + + + + 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 session. + + + + + + + + + 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 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 session 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 Session.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. + + + + + + + + + + + + + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the current + session or for all sessions 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. + + + + + + + + + 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 within the session. 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. + + + + + + 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 session + 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. + + + + + + + By default the QoS settings apply to the current session only. If this field is set, they + are applied to the entire connection. + + + + + + + + + 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. + + + + + + + + + + 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 session 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 from which the message will be consumed. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, 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 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). + + + + + + + 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. + + + + + + A set of filters for the consume. The syntax and semantics of these filters depends on the + providers implementation. + + + + + + + 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. + + + + + + + + + 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. + + + + + + + + + + + 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. + + + + + + + + + This method confirms that the cancellation was completed. + + + + + + + + + + + + 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. + + + + + + + + + + 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.). + + + + + + 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. + + + + + + + + + + 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. + + + + + + + + + + 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. + + + + + + + + + + This method stages the message, sending the message content to the recipient from the octet + offset specified in the Open-Ok method. + + + + + + + + + + + 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 "passive" access rights to the + realm for the exchange and "write" access rights to the realm for the queue to which the + message will be published. + + + + + + + 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. + + + + + + + Specifies the routing key for the message. The routing key is used for routing messages + depending on the exchange configuration. + + + + + + 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. + + + + + + + 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. + + + + + + + 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. + + + + + + + + + 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. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + + 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. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + 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. + + + + + + + + + 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. + + + + + + + + + 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 messages. + + + + + 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. + + + + + + + + + + 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. + + + + + + + + + + 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 session. 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. + + + + + + + + + + + + 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 unacknowledged 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. + + + + + + + + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the current + session or for all sessions 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. + + + + + + + + + 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 within the session. 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. + + + + + + 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 session and connection level) allow it. + + + + + + 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. + + + + + + + By default the QoS settings apply to the current session only. If this field is set, they + are applied to the entire connection. + + + + + + + + + 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. + + + + + + + + + + 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 session 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 sessions 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 from which the message will be consumed. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, 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 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). + + + + + + + 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. + + + + + + A set of filters for the consume. The syntax and semantics of these filters depends on the + providers implementation. + + + + + + + + + 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. + + + + + + + + + This method cancels a consumer. Since message delivery is asynchronous the client may + continue to receive messages for a short while after cancelling a consumer. It may process + or discard these as appropriate. + + + + + + + + + + + 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. + + + + + + + + + This method confirms that the cancellation was completed. + + + + + + + + + + + + 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 "passive" access rights to the + realm for the exchange and "write" access rights to the realm for the queue to which the + message will be published. + + + + + + + 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. + + + + + + + Specifies the routing key for the message. The routing key is used for routing messages + depending on the exchange configuration. + + + + + + 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. + + + + + + + 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. + + + + + + + + + + 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. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + + 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 session can + start many consumers on different queues. + + + + + + + + + + + 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. + + + + tx = C:SELECT + / C:COMMIT + / C:ROLLBACK + + + + + 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. + + + + + + + + + + + This method sets the session to use standard transactions. The client must use this method + at least once on a session before using the Commit or Rollback methods. + + + + + + + + + This method commits all messages published and acknowledged in the current transaction. A + new transaction starts immediately after a commit. + + + + + + + + + This method abandons all messages published and acknowledged in the current transaction. A + new transaction starts immediately after a rollback. + + + + + + + + + + + + + This class is part of the X-Open XA distributed transaction protocol support. It allows a + session to be selected for use with distributed transactions and the transactional boundaries + for work on that session to be demarcated. + + + + dtx-demarcation = C:SELECT *demarcation + demarcation = C:START S:START-OK C:END S:END-OK + + + + + Access-tickets are propagated with XA association methods with the aim of restricting which + users are allowed to control which transactions. The server MAY restrict transaction + association to a particular identity. + + + + + + Enabling XA transaction support on a session implies that the server MUST manage + transactions demarcated by start-end blocks. That is to say that on this XA-enabled session, + work undergone within transactional blocks is performed on behalf a transaction branch + whereas work performed outside of transactional blocks is NOT transactional. + + + + + + + + + + + + This method sets the session to use distributed transactions. The client must use this + method at least once on a session before using XA demarcation operations. + + + + + + + + + + This method is called when messages should be produced and consumed on behalf a transaction + branch identified by xid. + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid) + + + + + + If neither join nor resume is specified is specified and the transaction branch specified + by xid has previously been seen then the server MUST raise a channel exception with reply + code 530 (not allowed). + + + + + + If join and resume are specified then the server MUST raise a channel exception with reply + code 503 (command invalid). + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch to be started. + + + + + If xid is already known by the broker then the server MUST raise a channel exception + with reply code 530 (not allowed). + + + + + + + + + Indicate whether this is joining an already associated xid. Indicate that the start + applies to joining a transaction previously seen. + + + + + If the broker does not support join the server MUST raise a channel exception with reply + code 540 (not implemented). + + + + + + + + + Indicate that the start applies to resuming a suspended transaction branch specified. + + + + + + + + + + + This method confirms to the client that the transaction branch is started or specify the + error condition. + + + + + + + The value of this field may be one of the following constants: + + xa-ok: Normal execution. + + xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified + reason. + + xa-rbtimeout: The work represented by this transaction branch took too long. + + + + + + + + + + + + This method is called when the work done on behalf a transaction branch finishes or needs to + be suspended. + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid). + + + + + + If suspend and fail are specified then the server MUST raise a channel exception with + reply code 503 (command invalid). + + + + + + If an error occurs in ending the transaction branch then the server MUST raise a channel + exception with reply code 541 (internal error). + + + + + + If neither fail nor suspend are specified then the portion of work has completed + successfully. + + + + + + When a session is closed then the currently associated transaction branches MUST be marked + rollback-only. + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch to be ended. + + + + + The channel MUST be currently associated with the given xid (through an earlier start + call with the same xid). + + + + + + + + + If set, indicates that this portion of work has failed; otherwise this portion of work has + completed successfully. + + + + + An implementation MAY elect to roll a transaction back if this failure notification is + recieved. Should an implementation elect to implement this behaviour, and this bit is + set, then then the transaction branch SHOULD be marked as rollback-only and the end-ok + response SHOULD have the xa-rbrollback response set. + + + + + + + + + Indicates that the transaction branch is temporarily suspended in an incomplete state. + + + + + The transaction context is in a suspended state and must be resumed via the start method + with resume specified. + + + + + + + + + + + + This method confirms to the client that the transaction branch is ended or specify the error + condition. + + + + + + + The value of this field may be one of the following constants: + + xa-ok: Normal execution. + + xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified + reason. If an implementation chooses to implement rollback-on-failure behaviour, then + this value should be selected if the dtx-demarcation.end.fail bit was set. + + xa-rbtimeout: The work represented by this transaction branch took too long. + + + + + + + + + + + + + + This class is part of the X-Open XA distributed transaction protocol support. It allows the + transaction manager to coordinate transaction outcomes. + + + + dtx-coordination = *coordination + coordination = command + / outcome + / recovery + command = C:SET-TIMEOUT + / C:GET-TIMEOUT S:GET-TIMEOUT-OK + outcome = one-phase-commit + / one-phase-rollback + / two-phase-commit + / two-phase-rollback + one-phase-commit = C:COMMIT S:COMMIT-OK + one-phase-rollback = C:ROLLBACK S:ROLLBACK-OK + two-phase-commit = C:PREPARE S:PREPARE-OK C:COMMIT S:COMMIT-OK + two-phase-rollback = C:PREPARE S:PREPARE-OK C:ROLLBACK S:ROLLBACK-OK + recovery = C:RECOVER S:RECOVER-OK *recovery-outcome + recovery-outcome = one-phase-commit + / one-phase-rollback + / C:FORGET + + + + + Access-tickets are propagated with XA demarcation methods with the aim of restricting which + users are allowed to control which transactions. The server MAY restrict transaction + coordination to a particular identity. + + + + + + + + + + + Commit the work done on behalf a transaction branch. This method commits the work associated + with xid. Any produced messages are made available and any consumed messages are discarded. + + + + + If an error occurs in committing the transaction branch then the server MUST raise a + channel exception with reply code 541 (internal error) + + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid) + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch to be committed. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + If this method is called when xid is still associated with a session then the server + MUST raise a channel exception with reply code 503 (command invalid) + + + + + + + + + When set then one-phase commit optimization is used. + + + + + This bit MUST be set if a commit is sent without a preceding prepare. + + + + + + This bit MUST NOT be set if a preceding prepare has been sent. + + + + + + + + + + + + This method confirms to the client that the transaction branch is committed or specify the + error condition. + + + + + + + The value of this field may be one of the following constants: + + xa-ok: Normal execution + + xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction + branch may have been heuristically completed. + + xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was committed. + + xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was rolled back. + + xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was partially committed and partially rolled back. + + xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified + reason. + + xa-rbtimeout: The work represented by this transaction branch took too long. + + + + + + + + + + This method is called to forget about a heuristically completed transaction branch. + + + + + If an error occurs in forgetting the transaction branch then the server MUST raise a + channel exception with reply code 541 (internal error) + + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid) + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch to be forgotten. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + If this method is called when xid is still associated with a session then the server + MUST raise a channel exception with reply code 503 (command invalid). + + + + + + + + + + + + This method obtains the current transaction timeout value in seconds. If set-timeout was not + used prior to invoking this method, the return value is the default timeout; otherwise, the + value used in the previous set-timeout call is returned. + + + + + If an error occurs in setting the transaction timeout then the server MUST raise a channel + exception with reply code 541 (internal error). + + + + + + + + + + Specifies the xid of the transaction branch for getting the timeout. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + + + + + + + Returns the value of the timeout last specified through set-timeout. + + + + + + + The current transaction timeout value in seconds. + + + + + + + + + + This method prepares for commitment any message produced or consumed on behalf of xid. + + + + + If an error occurs in preparing the transaction branch then the server MUST raise a + channel exception with reply code 541 (internal error). The specified xid may or may not + have been prepared. + + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid) + + + + + + Once this method successfully returns it is guaranteed that the transaction branch may be + either committed or rolled back regardless of failures. + + + + + + The knowledge of xid cannot be erased before commit or rollback complete the branch. + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch that can be prepared. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + If this method is called when xid is still associated with a session then the server + MUST raise a channel exception with reply code 503 (command invalid) + + + + + + + + + + + + This method confirms to the client that the transaction branch is prepared or specify the + error condition. + + + + + + + The value of this field may be one of the following constants: + + xa-ok: Normal execution. + + xa-rdonly: The transaction branch was read-only and has been committed. + + xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified + reason. + + xa-rbtimeout: The work represented by this transaction branch took too long. + + + + + + + + + + + This method is called to obtain a list of transaction branches that are in a prepared or + heuristically completed state. + + + + + If an error occurs in recovering then the server MUST raise a channel exception with reply + code 541 (internal error) + + + + + + If this endscan is used in conjunction with startscan then a single call starts and then + ends a scan. + + + + + + If none of endscan and startscan are set then a recovery scan must already be started + otherwise the server MUST raise a channel exception with reply code 503 (command invalid) + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Indicates that recovery scan should start. + + + + + If a recovery scan is already open, the effect is as if the recovery scan were ended and + then restarted. + + + + + + + + + Indicates that the recovery scan should end after returning the xids. + + + + + + + + + + Returns to the client a table with single item that is a sequence of transaction xids that + are in a prepared or heuristically completed state. + + + + + + + Table containing the sequence of xids to be recovered (xids that are in a prepared or + heuristically completed state). + + + + + The field table must contain a field called 'xids' of type sequence of longstrs + representing the xids that are in a prepared or heuristically completed state. + + + + + + + + + + + + This method rolls back the work associated with xid. Any produced messages are discarded and + any consumed messages are re-enqueued. + + + + + If an error occurs in rolling back the transaction branch then the server MUST raise a + channel exception with reply code 541 (internal error) + + + + + + If the method is invoked in an improper context (see class grammar) then the server MUST + raise a channel exception with reply code 503 (command invalid) + + + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch that can be rolled back. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + If this method is called when xid is still associated with a session then the server + MUST raise a channel exception with reply code 503 (command invalid) + + + + + + + + + + + + This method confirms to the client that the transaction branch is rolled back or specify the + error condition. + + + + + + + The value of this field may be one of the following constants: + + xa-ok: Normal execution + + xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction + branch may have been heuristically completed. + + xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was committed. + + xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was rolled back. + + xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified + transaction branch was partially committed and partially rolled back. + + xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified + reason. + + xa-rbtimeout: The work represented by this transaction branch took too long. + + + + + + + + + + Sets the specified transaction branch timeout value in seconds. + + + + + If an error occurs in setting the transaction timeout then the server MUST raise a channel + exception with reply code 541 (internal error) + + + + + + Once set, this timeout value is effective until this method is reinvoked with a different + value. + + + + + + A value of zero resets the timeout value to the default value. + + + + + + + + Access-ticket granted by the server for a specific realm. + + + + + The client MUST provide a valid access ticket giving "active" access rights to all the + realms touched by this transaction. + + + + + + + + + Specifies the xid of the transaction branch for setting the timeout. + + + + + If xid is unknown (the transaction branch has not been started or has already been + ended) then the server MUST raise a channel exception with reply code 404 (not found). + + + + + + + + + The transaction timeout value in seconds. + + + + + + + + + + + + + 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 + + + + + + + + + + + + + + + + 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. + + + + + + + This field table holds arbitrary meta-data that the sender needs to pass to the recipient. + + + + + + + + + + + The message class provides methods that support an industry-standard messaging model. + + + + message = C:QOS + / C:CONSUME + / C:CANCEL + / C:TRANSFER [ S:REJECT ] + / S:TRANSFER [ C:REJECT ] + / C:GET [ S:EMPTY ] + / C:RECOVER + / C:OPEN + / S:OPEN + / C:APPEND + / S:APPEND + / C:CLOSE + / S:CLOSE + / C:CHECKPOINT + / S:CHECKPOINT + / C:RESUME S:OFFSET + / S:RESUME C:OFFSET + + + + + The server SHOULD respect the persistent property of messages and SHOULD make a best-effort + to hold persistent mess ages on a reliable storage mechanism. + + + Send a persistent message to queue, stop server, restart server and then verify whether + message is still present. Assumes that queues are durable. Persistence without durable + queues makes no sense. + + + + + + The server MUST NOT discard a persistent message in case of a queue overflow. + + + Create a queue overflow situation with persistent messages and verify that messages do not + get lost (presumably the server will write them to disk). + + + + + + The server MAY use the Session.Flow method to slow or stop a message publisher when + necessary. + + + Create a queue overflow situation with non-persistent messages and verify whether the server + responds with Session.Flow or not. Repeat with persistent messages. + + + + + + The server MAY overflow non-persistent messages to persistent storage. + + + + + + The server MAY discard or dead-letter non-persistent messages on a priority basis if the + queue size exceeds some configured limit. + + + + + + The server MUST implement at least 2 priority levels for messages, where priorities 0-4 and + 5-9 are treated as two distinct levels. + + + Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume + messages from the queue and verify that the first message received was priority 9. + + + + + + The server MAY implement up to 10 priority levels. + + + Send a number of messages with mixed priorities to a queue, so that all priority values from + 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume + from queue and verify how many priority levels emerge. + + + + + + The server MUST deliver messages of the same priority in order irrespective of their + individual persistence. + + + Send a set of messages with the same priority but different persistence settings to a queue. + Consume and verify that messages arrive in same order as originally published. + + + + + + The server MUST support automatic acknowledgements on messages, i.e. consumers with the + no-ack field set to FALSE. + + + Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to + the queue. Consume the messages and verify that all messages are received. + + + + + + The server MUST support explicit acknowledgements on messages, i.e. consumers with the + no-ack field set to TRUE. + + + Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to + the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, + and consume from the queue. Verify that the remaining messages are received. + + + + + + + + + + + + + + + + + + This method transfers a message between two peers. When a client uses this method to publish + a message to a broker, the destination identifies a specific exchange. The message will then + be routed to queues as defined by the exchange configuration and distributed to any active + consumers when the transaction, if any, is committed. + + In the asynchronous message delivery model, the client starts a consumer using the Consume + method and passing in a destination, then the broker responds with transfer methods to the + specified destination as and when messages arrive for that consumer. + + If synchronous message delivery is required, the client may issue a get request which on + success causes a single message to be transferred to the specified destination. + + Message acknowledgement is signalled by the return result of this method. + + + + + The recipient MUST NOT return ok before the message has been processed as defined by the + QoS settings. + + + + + + + + + + + + + The client MUST provide a valid access ticket giving "passive" access rights to the + realm for the exchange and "write" access rights to the realm for the queue to which the + message will be published. + + + + + + + Specifies the destination to which the message is to be transferred. The destination can + be empty, meaning the default exchange or consumer. If the destination is specified, and + that exchange or consumer does not exist, the peer must raise a channel exception. + + + + + The server MUST accept a blank destination to mean the default exchange. + + + + + + If the destination refers to an internal exchange, the server MUST raise a channel + exception with a reply code 403 (access refused). + + + + + + A destination MAY refuse message content in which case it MUST raise a channel exception + with reply code 540 (not implemented). + + + + + + + This boolean flag indicates that the message has been previously delivered to this or + another client. + + + + + + If the reject-unroutable flag is set, then at the time of publishing the broker determines + if the message will be routed to any queues. If it will not be routed to any queue then + the broker responds with a message.reject. + + + + + + + + + If this is set to a non zero value then a message expiration time will be computed based + on the current time plus this value. Messages that live longer than their expiration time + will be discarded (or dead lettered). + + + + If a message is transfered between brokers before delivery to a final consumer the ttl + should be decremented before peer to peer transfer and both timestamp and expiration + should be cleared. + + + + + + + + Message priority, which can be between 0 and 9. Messages with higher priorities may be + delivered before those with lower priorities. + + + + + + The timestamp is set by the broker on arrival of the message. + + + + + + The delivery mode may be non-persistent (1) or persistent (2). A persistent message is one + which must be stored on a persistent medium (usually hard drive) at every stage of + delivery so that it will not be lost in event of failure (other than the medium itself). + This is normally accomplished with some additional overhead. A persistent message may be + delivered more than once if there is uncertainty about the state of its delivery after a + failure and recovery. + + Conversely, a non-persistent message may be lost in event of a failure, but the nature of + the communication is such that an occasional message loss is tolerable. This is the lowest + overhead mode. Non-persistent messages are delivered at most once only. + + + + + + The expiration header assigned by the broker. After receiving the message the broker sets + expiration to the sum of the ttl specified in the publish method and the current time. + (ttl=expiration - timestamp) + + + + + + The exchange name is a client-selected string that identifies the exchange for transfer + methods. Exchange names may consist of any mixture of digits, letters, and underscores. + Exchange names are scoped by the virtual host. + + + + + + The value of the key determines to which queue the exchange will send the message. The way + in which keys are used to make this routing decision depends on the type of exchange to + which the message is sent. For example, a direct exchange will route a message to a queue + if that queue is bound to the exchange with an identical key to that of the message. + + + + + + This is a unique identifier for the message that is guaranteed to be unique across + multiple instances, sessions and in time. This allows duplicate messages to be detected. + This may be a UUID. Note that this is usually set by the server when it first receives a + message. + + If a client wishes to identify a message, it should use the correlation-id instead. + + + + + + This is a client-specific id that may be used to mark or identify messages between + clients. The server ignores this field. + + + + + + The destination of any message that is sent in reply to this message. + + + + + + The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the + originating client. + + + + + + The encoding for character-based message content. This is set by the originating client. + Examples include UTF-8 and ISO-8859-16. + + + + + + The length of the message content in bytes. + + + + + + The JMS message type. + + + + + + The identity of the user responsible for producing the message. + + + + + + The identity of the client application responsible for producing the message. + + + + + + An identifier that links this message to a distributed transaction. + + + + + + A security token used for authentication, replay prevention, and encrypted message bodies. + + + + + + This is a collection of user-defined headers or properties which may be set by the + producing client and retrieved by the consuming client. Similar to JMS Properties. + + + + + + + Message content. This should be considered opaque data. + + + + + + + + + + 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 session they were created on, or until + the client cancels them. + + + + + The server SHOULD support at least 16 consumers per queue, and ideally, impose no limit + except as defined by available resources. + + + Create a queue and create consumers on that queue until the server closes the connection. + Verify that the number of consumers created was at least sixteen and report the total + number. + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to the realm + for the queue from which the message will be consumed. + + + Attempt to create a consumer with an invalid (non-zero) access ticket. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, which is the last declared queue. + + + + If the queue name is empty the client MUST have previously declared a queue using this + session. + + + Attempt to create a consumer with an empty queue name and no previously declared queue + on the session. + + + + + + + Specifies the destination for the consumer. The destination is local to a connection, so + two clients can use the same destination. + + + + + The client MUST NOT specify a destination that refers to an existing consumer. + + + Attempt to create two consumers with the same non-empty destination. + + + + + + The destination is valid only within the session from which the consumer was created. + i.e. A client MUST NOT create a consumer in one session and then use it in another. + + + Attempt to create a consumer in one session, then use in another session, in which + consumers have also been created (to test that the server uses unique destinations). + + + + + + + If the no-local field is set the server will not send messages to the connection that + published them. + + + + + + + If this field is set the server does not expect acknowledgements 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. + + + + + + Request exclusive consumer access, meaning only this consumer can access the queue. + + + + + The client MUST NOT gain exclusive access to a queue that already has active consumers. + + + Open two connections to a server, and in one connection create a shared (non-exclusive) + queue and then consume from the queue. In the second connection attempt to consume from + the same queue using the exclusive option. + + + + + + + A set of filters for the consume. The syntax and semantics of these filters depends on the + providers implementation. + + + + + + + + + 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 + arbitrary number of messages in between sending the cancel method and receiving the + cancel-ok reply. + + + + + If the queue does not exist the server MUST ignore the cancel method, so long as the + consumer tag is valid for that session. + + + + + + + + + + + + + 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 from which the message will be consumed. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, refers to the + current queue for the session, 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). + + + + + + + On normal completion of the get request (i.e. a response of ok). A message will be + transferred to the supplied destination. + + + + + + + + + + + This method asks the broker to redeliver all unacknowledged messages on a specified session. + Zero or more messages may be redelivered. This method is only allowed on non-transacted + sessions. + + + + + 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 session. + + + + + + + + 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. + + + + + + + + + This method creates a reference. A references provides a means to send a message body into a + temporary area at the recipient end and then deliver the message by referring to this + temporary area. This is how the protocol handles large message transfers. + + The scope of a ref is defined to be between calls to open (or resume) and close. Between + these points it is valid for a ref to be used from any content data type, and so the + receiver must hold onto its contents. Should the session be closed when a ref is still in + scope, the receiver may discard its contents (unless it is checkpointed). A ref that is in + scope is considered open. + + + + + + + + + The recipient MUST generate an error if the reference is currently open (in scope). + + + + + + + + + + This method signals the recipient that no more data will be appended to the reference. + + + + + A recipient MUST NOT acknowledge a message until its reference is closed (not in scope). + + + + + + + + + + The recipient MUST generate an error if the reference was not previously open (in + scope). + + + + + + + + + This method appends data to a reference. + + + + + + + + The recipient MUST generate an error if the reference is not open (not in scope). + + + + + + + + + + + + This method provides a means to checkpoint large message transfer. The sender may ask the + recipient to checkpoint the contents of a reference using the supplied identifier. The + sender may then resume the transfer at a later point. It is at the discretion of the + recipient how much data to save with the checkpoint, and the sender MUST honour the offset + returned by the resume method. + + + + + + + + + The recipient MUST generate an error if the reference is not open (not in scope). + + + + + + + This is the checkpoint identifier. This is an arbitrary string chosen by the sender. For + checkpointing to work correctly the sender must use the same checkpoint identifier when + resuming the message. A good choice for the checkpoint identifier would be the SHA1 hash + of the message properties data (including the original filename, revised time, etc.). + + + + + + + + + This method resumes a reference from the last checkpoint. A reference is considered to be + open (in scope) after a resume even though it will not have been opened via the open method + during this session. + + + + + + + + + + + The recipient MUST generate an error if the reference is currently open (in scope). + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the current + session or for all sessions 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. + + + + + + + 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 within the session. 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. + + + Define a QoS prefetch-size limit and send a single message that exceeds that limit. + Verify that the message arrives correctly. + + + + + + + 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 session 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. + + + Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send + multiple messages that exceed the prefetch size. Verify that no more than one message + arrives at once. + + + + + + + By default the QoS settings apply to the current session only. If this field is set, they + are applied to the entire connection. + + + + + + + + + Signals that a queue does not contain any messages; usually sent in response to the get + method. + + + + + + + + + + + This response rejects a message. A message may be rejected for a number of reasons. + + + + + + + + Code indicating the reason for message rejection. + + + + + + A string containing additional details on the reason for message rejection. + + + + + + + + + Returns the data offset into a reference body; usually sent in response to resume method. + + + + + + + + Offset in bytes into message body data. + + + + + + + + + + + This is a utility class for querying and exchange about its bindings to queues. + + + + + + + + + + This method is used to request information on the bindings to a particular exchange. That + information is conveyed in a query-ok method. + + + + + + + + + + The client MUST provide a valid access ticket giving "passive" access rights to the + exchange's access realm. + + + + + + + The name of the exchange for which binding information is being requested. If not + specified explicitly the default exchange is implied. + + + + + + If populated then determine whether the given queue is bound to the exchange. + + + + + + If populated defines the routing key of the binding of interest, if not populated the + request will ignore the routing key on bindings when searching for a match. + + + + + + If populated defines the arguments of the binding of interest if not populated the request + will ignore the arguments on bindings when searching for a match + + + + + + + + + This method is used in response to a query and conveys information on the bindings to a + particular exchange. + + + + + + + If set, the exchange for which information was requested is not known. + + + + + + If set, the queue specified is not known. + + + + + + A bit which if set indicates that no binding was found from the specified exchange to the + specified queue. + + + + + + A bit which if set indicates that no binding was found from the specified exchange with + the specified routing key. + + + + + + A bit which if set indicates that no binding was found from the specified exchange with + the specified arguments. + + + + + + + + + + This class allows for efficiently communicating information about completion of processing. + + + + + + + + + + Requests notification of all currently complete commands. The server should issue an + execution.complete at the earliest possible opportunity. + + + + + + + + + + + Signals completion of all commands such that command-id <= cumulative-execution-mark, or + command-id is in the set defined by ranged-execution-set. This can be sent spontaneously, + in response to a execution.flush, or as requested by use of the sync bit. + + + + + + + In order to ensure a canonical wire representation, the value cumulative-execution-mark + + 1 must not be covered by the ranged-execution-set. + + + + + + + + + The low-water mark for executed command-ids. All ids below this mark have been executed; + above this mark, there are gaps containing unexecuted command ids (i.e. discontinuous). By + definition, the first id above this mark (if it exists) is an unexecuted command-id. + + + + + + This set contains a sequence of discontinuous executed command-ids above the low-water + mark (i.e. above the first gap of unexecuted command ids). + + + + + + + + + + + + The channel class provides methods for a client to establish a channel to a + server and for both peers to operate the channel thereafter. + + + + channel = open-channel *use-channel close-channel + open-channel = C:OPEN S:OPEN-OK + / C:RESUME S:OK + use-channel = C:FLOW S:FLOW-OK + / S:FLOW C:FLOW-OK + / S:PING C:OK + / C:PONG S:OK + / C:PING S:OK + / S:PONG C:OK + / functional-class + close-channel = C:CLOSE S:CLOSE-OK + / S:CLOSE C:CLOSE-OK + + + + + + + + + + This method opens a channel to the server. + + + + The client MUST NOT use this method on an already-opened channel. + + + Client opens a channel and then reopens the same channel. + + + + + + + Configures out-of-band transfers on this channel. The syntax and meaning of this + field will be formally defined at a later date. + + + + + + + + This method signals to the client that the channel is ready for use. + + + + + + + + + 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 overflowing 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 disable flow + method should finish sending the current content frame, if any, then pause. + + + + + When a new channel is opened, it is active (flow 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 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 exchanging 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. This is to prevent badly-behaved clients + from overwhelming a broker. + + + + + + + + + + + If 1, the peer starts sending content frames. If 0, the peer stops sending + content frames. + + + + + + + Confirms to the peer that a flow command was received and processed. + + + + + + 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. + + + + + + + + + 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 the Close-OK method MUST + be discarded. + + + + + + + + + + + + + When the close is provoked by a method exception, this is the class of the + method. + + + + + + When the close is provoked by a method exception, this is the ID of the method. + + + + + + + This method confirms a Channel.Close method and tells the recipient that it is safe + to release resources for the channel. + + + + A peer that detects a socket closure without having received a Channel.Close-Ok + handshake method SHOULD log the error. + + + + + + + + -- cgit v1.2.1