The bin8 type consists of exactly one octet of opaque binary data. 1 OCTET +----------+ | bin8 | +----------+ bin8 = OCTET The int8 type is a signed integral value encoded using an 8-bit two's complement representation. 1 OCTET +----------+ | int8 | +----------+ int8 = OCTET The uint8 type is an 8-bit unsigned integral value. 1 OCTET +---------+ | uint8 | +---------+ uint8 = OCTET The char type encodes a single character from the iso-8859-15 character set. 1 OCTET +----------+ | char | +----------+ char = OCTET The boolean type is a single octet that encodes a true or false value. If the octet is zero, then the boolean is false. Any other value represents true. 1 OCTET +---------+ | boolean | +---------+ boolean = OCTET The bin16 type consists of two consecutive octets of opaque binary data. 1 OCTET 1 OCTET +-----------+-----------+ | octet-one | octet-two | +-----------+-----------+ bin16 = 2 OCTET The int16 type is a signed integral value encoded using a 16-bit two's complement representation in network byte order. 1 OCTET 1 OCTET +-----------+----------+ | high-byte | low-byte | +-----------+----------+ int16 = high-byte low-byte high-byte = OCTET low-byte = OCTET The uint16 type is a 16-bit unsigned integral value encoded in network byte order. 1 OCTET 1 OCTET +-----------+----------+ | high-byte | low-byte | +-----------+----------+ uint16 = high-byte low-byte high-byte = OCTET low-byte = OCTET The bin32 type consists of 4 consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-------------+------------+ | octet-one | octet-two | octet-three | octet-four | +-----------+-----------+-------------+------------+ bin32 = 4 OCTET The int32 type is a signed integral value encoded using a 32-bit two's complement representation in network byte order. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+------------+----------+----------+ | byte-four | byte-three | byte-two | byte-one | +-----------+------------+----------+----------+ MSB LSB int32 = byte-four byte-three byte-two byte-one byte-four = OCTET ; most significant byte (MSB) byte-three = OCTET byte-two = OCTET byte-one = OCTET ; least significant byte (LSB) The uint32 type is a 32-bit unsigned integral value encoded in network byte order. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+------------+----------+----------+ | byte-four | byte-three | byte-two | byte-one | +-----------+------------+----------+----------+ MSB LSB uint32 = byte-four byte-three byte-two byte-one byte-four = OCTET ; most significant byte (MSB) byte-three = OCTET byte-two = OCTET byte-one = OCTET ; least significant byte (LSB) The float type encodes a single precision 32-bit floating point number. The format and operations are defined by the IEEE 754 standard for 32-bit floating point numbers. 4 OCTETs +-----------------------+ | float | +-----------------------+ IEEE 754 32-bit float float = 4 OCTET ; IEEE 754 32-bit floating point number The char-utf32 type consists of a single unicode character in the UTF-32 encoding. 4 OCTETs +------------------+ | char-utf32 | +------------------+ UTF-32 character char-utf32 = 4 OCTET ; single UTF-32 character The sequence-no type encodes, in network byte order, a serial number as defined in RFC-1982. The arithmetic, operators, and ranges for numbers of this type are defined by RFC-1982. 4 OCTETs +------------------------+ | sequence-no | +------------------------+ RFC-1982 serial number sequence-no = 4 OCTET ; RFC-1982 serial number The bin64 type consists of eight consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+-------------+-------------+ | octet-one | octet-two | ... | octet-seven | octet-eight | +-----------+-----------+-----+-------------+-------------+ bin64 = 8 OCTET The int64 type is a signed integral value encoded using a 64-bit two's complement representation in network byte order. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +------------+------------+-----+----------+----------+ | byte-eight | byte-seven | ... | byte-two | byte-one | +------------+------------+-----+----------+----------+ MSB LSB int64 = byte-eight byte-seven byte-six byte-five byte-four byte-three byte-two byte-one byte-eight = 1 OCTET ; most significant byte (MSB) byte-seven = 1 OCTET byte-six = 1 OCTET byte-five = 1 OCTET byte-four = 1 OCTET byte-three = 1 OCTET byte-two = 1 OCTET byte-one = 1 OCTET ; least significant byte (LSB) The uint64 type is a 64-bit unsigned integral value encoded in network byte order. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +------------+------------+-----+----------+----------+ | byte-eight | byte-seven | ... | byte-two | byte-one | +------------+------------+-----+----------+----------+ MSB LSB uint64 = byte-eight byte-seven byte-six byte-five byte-four byte-three byte-two byte-one byte-eight = 1 OCTET ; most significant byte (MSB) byte-seven = 1 OCTET byte-six = 1 OCTET byte-five = 1 OCTET byte-four = 1 OCTET byte-three = 1 OCTET byte-two = 1 OCTET byte-one = 1 OCTET ; least significant byte (LSB) The double type encodes a double precision 64-bit floating point number. The format and operations are defined by the IEEE 754 standard for 64-bit double precision floating point numbers. 8 OCTETs +-----------------------+ | double | +-----------------------+ IEEE 754 64-bit float double = 8 OCTET ; double precision IEEE 754 floating point number The datetime type encodes a date and time using the 64 bit POSIX time_t format. 8 OCTETs +---------------------+ | datetime | +---------------------+ posix time_t format datetime = 8 OCTET ; 64 bit posix time_t format The bin128 type consists of 16 consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+---------------+---------------+ | octet-one | octet-two | ... | octet-fifteen | octet-sixteen | +-----------+-----------+-----+---------------+---------------+ bin128 = 16 OCTET The uuid type encodes a universally unique id as defined by RFC-4122. The format and operations for this type can be found in section 4.1.2 of RFC-4122. 16 OCTETs +---------------+ | uuid | +---------------+ RFC-4122 UUID uuid = 16 OCTET ; RFC-4122 section 4.1.2 The bin256 type consists of thirty two consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+------------------+------------------+ | octet-one | octet-two | ... | octet-thirty-one | octet-thirty-two | +-----------+-----------+-----+------------------+------------------+ bin256 = 32 OCTET The bin512 type consists of sixty four consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+-------------------+------------------+ | octet-one | octet-two | ... | octet-sixty-three | octet-sixty-four | +-----------+-----------+-----+-------------------+------------------+ bin512 = 64 OCTET The bin1024 type consists of one hundred and twenty eight octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+------------------------+------------------------+ | octet-one | octet-two | ... | octet-one-twenty-seven | octet-one-twenty-eight | +-----------+-----------+-----+------------------------+------------------------+ bin1024 = 128 OCTET The vbin8 type encodes up to 255 octets of opaque binary data. The number of octets is first encoded as an 8-bit unsigned integral value. This is followed by the actual data. 1 OCTET size OCTETs +---------+-------------+ | size | octets | +---------+-------------+ uint8 vbin8 = size octets size = uint8 octets = 0*255 OCTET ; size OCTETs The str8-latin type encodes up to 255 octets of iso-8859-15 characters. The number of octets is first encoded as an 8-bit unsigned integral value. This is followed by the actual characters. 1 OCTET size OCTETs +---------+------------------------+ | size | characters | +---------+------------------------+ uint16 iso-8859-15 characters str8-latin = size characters size = uint8 characters = 0*255 OCTET ; size OCTETs The str8 type encodes up to 255 octets worth of UTF-8 unicode. The number of octets of unicode is first encoded as an 8-bit unsigned integral value. This is followed by the actual UTF-8 unicode. Note that the encoded size refers to the number of octets of unicode, not necessarily the number of characters since the UTF-8 unicode may include multi-byte character sequences. 1 OCTET size OCTETs +---------+--------------+ | size | utf8-unicode | +---------+--------------+ uint8 str8 = size utf8-unicode size = uint8 utf8-unicode = 0*255 OCTET ; size OCTETs The str8-utf16 type encodes up to 255 octets worth of UTF-16 unicode. The number of octets of unicode is first encoded as an 8-bit unsigned integral value. This is followed by the actual UTF-16 unicode. Note that the encoded size refers to the number of octets of unicode, not the number of characters since the UTF-16 unicode will include at least two octets per unicode character. 1 OCTET size OCTETs +---------+---------------+ | size | utf16-unicode | +---------+---------------+ uint8 str8-utf16 = size utf16-unicode size = uint8 utf16-unicode = 0*255 OCTET ; size OCTETs The vbin16 type encodes up to 65535 octets of opaque binary data. The number of octets is first encoded as a 16-bit unsigned integral value in network byte order. This is followed by the actual data. 2 OCTETs size OCTETs +----------+-------------+ | size | octets | +----------+-------------+ uint16 vbin16 = size octets size = uint16 octets = 0*65535 OCTET ; size OCTETs The str16-latin type encodes up to 65535 octets of is-8859-15 characters. The number of octets is first encoded as a 16-bit unsigned integral value in network byte order. This is followed by the actual characters. 2 OCTETs size OCTETs +----------+------------------------+ | size | characters | +----------+------------------------+ uint16 iso-8859-15 characters str16-latin = size characters size = uint16 characters = 0*65535 OCTET ; size OCTETs The str16 type encodes up to 65535 octets worth of UTF-8 unicode. The number of octets is first encoded as a 16-bit unsigned integral value in network byte order. This is followed by the actual UTF-8 unicode. Note that the encoded size refers to the number of octets of unicode, not necessarily the number of unicode characters since the UTF-8 unicode may include multi-byte character sequences. 2 OCTETs size OCTETs +----------+--------------+ | size | utf8-unicode | +----------+--------------+ uint16 str16 = size utf8-unicode size = uint16 utf8-unicode = 0*65535 OCTET ; size OCTETs The str16-utf16 type encodes up to 65535 octets worth of UTF-16 unicode. The number of octets is first encoded as a 16-bit unsigned integral value in network byte order. This is followed by the actual UTF-16 unicode. Note that the encoded size refers to the number of octets of unicode, not the number of unicode characters since the UTF-16 unicode will include at least two octets per unicode character. 2 OCTETs size OCTETs +----------+---------------+ | size | utf16-unicode | +----------+---------------+ uint16 str16-utf16 = size utf16-unicode size = uint16 utf16-unicode = 0*65535 OCTET ; size OCTETs The byte-ranges type encodes up to 65535 octets worth of non-overlapping, non-touching, ascending byte ranges within a 64-bit sequence of bytes. Each range is represented as an inclusive lower and upper bound that identifies all the byte offsets included within a given range. The number of octets of data is first encoded as a 16-bit unsigned integral value in network byte order. This is then followed by the encoded representation of the ranges included in the set. These MUST be encoded in ascending order, and any two ranges included in a given set MUST NOT include overlapping or touching byte offsets. Each range is encoded as a pair of 64-bit unsigned integral values in network byte order respectively representing the lower and upper bounds for that range. Note that because each range is exactly 16 octets, the size in octets of the encoded ranges will always be 16 times the number of ranges in the set. +----= size OCTETs =----+ | | 2 OCTETs | 16 OCTETs | +----------+-----+-----------+-----+ | size | .../| range |\... | +----------+---/ +-----------+ \---+ uint16 / / \ \ / / \ \ / 8 OCTETs 8 OCTETs \ +-----------+-----------+ | lower | upper | +-----------+-----------+ uint64 uint64 byte-ranges = size *range size = uint16 range = lower upper lower = uint64 upper = uint64 The sequence-set type is a set of pairs of RFC-1982 numbers representing a discontinuous range within an RFC-1982 sequence. Each pair represents a closed interval within the list. Sequence-sets can be represented as lists of pairs of positive 32-bit numbers, each pair representing a closed interval that does not overlap or touch with any other interval in the list. For example, a set containing words 0, 1, 2, 5, 6, and 15 can be represented: [(0, 2), (5, 6), (15, 15)] 1) The list-of-pairs representation is sorted ascending (as defined by RFC 1982 (http://www.ietf.org/rfc/rfc1982.txt) ) by the first elements of each pair. 2) The list-of-pairs is flattened into a list-of-words. 3) Each word in the list is packed into ascending locations in memory with network byte ordering. 4) The size in bytes, represented as a 16-bit network-byte-order unsigned value, is prepended. For instance, the example from above would be encoded: [(0, 2), (5, 6), (15, 15)] -- already sorted. [0, 2, 5, 6, 15, 15] -- flattened. 000000000000000200000005000000060000000F0000000F -- bytes in hex 0018000000000000000200000005000000060000000F0000000F -- bytes in hex, length (24) prepended +----= size OCTETs =----+ | | 2 OCTETs | 8 OCTETs | +----------+-----+-----------+-----+ | size | .../| range |\... | +----------+---/ +-----------+ \---+ uint16 / / \ \ / / \ \ / / \ \ / / \ \ / 4 OCTETs 4 OCTETs \ +-------------+-------------+ | lower | upper | +-------------+-------------+ sequence-no sequence-no sequence-set = size *range size = uint16 ; length of variable portion in bytes range = lower upper ; inclusive lower = sequence-no upper = sequence-no The vbin32 type encodes up to 4294967295 octets of opaque binary data. The number of octets is first encoded as a 32-bit unsigned integral value in network byte order. This is followed by the actual data. 4 OCTETs size OCTETs +----------+-------------+ | size | octets | +----------+-------------+ uint32 vbin32 = size octets size = uint32 octets = 0*4294967295 OCTET ; size OCTETs A map is a set of distinct keys where each key has an associated (type,value) pair. The triple of the key, type, and value, form an entry within a map. Each entry within a given map MUST have a distinct key. A map is encoded as a size in octets, a count of the number of entries, followed by the encoded entries themselves. An encoded map may contain up to (4294967295 - 4) octets worth of encoded entries. The size is encoded as a 32-bit unsigned integral value in network byte order equal to the number of octets worth of encoded entries plus 4. (The extra 4 octets is added for the entry count.) The size is then followed by the number of entries encoded as a 32-bit unsigned integral value in network byte order. Finally the entries are encoded sequentially. An entry is encoded as the key, followed by the type, and then the value. The key is always a string encoded as a str8. The type is a single octet that may contain any valid AMQP type code. The value is encoded according to the rules defined by the type code for that entry. +------------= size OCTETs =-----------+ | | 4 OCTETs | 4 OCTETs | +----------+----------+-----+---------------+-----+ | size | count | .../| entry |\... | +----------+----------+---/ +---------------+ \---+ uint32 uint32 / / \ \ / / \ \ / / \ \ / / \ \ / / \ \ / k OCTETs 1 OCTET n OCTETs \ +-----------+---------+-----------+ | key | type | value | +-----------+---------+-----------+ str8 *type* map = size count *entry size = uint32 ; size of count and entries in octets count = uint32 ; number of entries in the map entry = key type value key = str8 type = OCTET ; type code of the value value = *OCTET ; the encoded value A list is an ordered sequence of (type, value) pairs. The (type, value) pair forms an item within the list. The list may contain items of many distinct types. A list is encoded as a size in octets, followed by a count of the number of items, followed by the items themselves encoded in their defined order. An encoded list may contain up to (4294967295 - 4) octets worth of encoded items. The size is encoded as a 32-bit unsigned integral value in network byte order equal to the number of octets worth of encoded items plus 4. (The extra 4 octets is added for the item count.) The size is then followed by the number of items encoded as a 32-bit unsigned integral value in network byte order. Finally the items are encoded sequentially in their defined order. An item is encoded as the type followed by the value. The type is a single octet that may contain any valid AMQP type code. The value is encoded according to the rules defined by the type code for that item. +---------= size OCTETs =---------+ | | 4 OCTETs | 4 OCTETs | +----------+----------+-----+----------+-----+ | size | count | .../| item |\... | +----------+----------+---/ +----------+ \---+ uint32 uint32 / / \ \ / / \ \ / 1 OCTET n OCTETs \ +----------+-----------+ | type | value | +----------+-----------+ *type* list = size count *item size = uint32 ; size of count and items in octets count = uint32 ; number of items in the list item = type value type = OCTET ; type code of the value value = *OCTET ; the encoded value An array is an ordered sequence of values of the same type. The array is encoded in as a size in octets, followed by a type code, then a count of the number values in the array, and finally the values encoded in their defined order. An encoded array may contain up to (4294967295 - 5) octets worth of encoded values. The size is encoded as a 32-bit unsigned integral value in network byte order equal to the number of octets worth of encoded values plus 5. (The extra 5 octets consist of 4 octets for the count of the number of values, and one octet to hold the type code for the items in the array.) The size is then followed by a single octet that may contain any valid AMQP type code. The type code is then followed by the number of values encoded as a 32-bit unsigned integral value in network byte order. Finally the values are encoded sequentially in their defined order according to the rules defined by the type code for the array. 4 OCTETs 1 OCTET 4 OCTETs (size - 5) OCTETs +----------+---------+----------+-------------------------+ | size | type | count | values | +----------+---------+----------+-------------------------+ uint32 uint32 *count* encoded *types* array = size type count values size = uint32 ; size of type, count, and values in octets type = OCTET ; the type of the encoded values count = uint32 ; number of items in the array values = 0*4294967290 OCTET ; (size - 5) OCTETs The struct32 type describes any coded struct with a 32-bit (4 octet) size. The type is restricted to be only coded structs with a 32-bit size, consequently the first six octets of any encoded value for this type MUST always contain the size, class-code, and struct-code in that order. The size is encoded as a 32-bit unsigned integral value in network byte order that is equal to the size of the encoded field-data, packing-flags, class-code, and struct-code. The class-code is a single octet that may be set to any valid class code. The struct-code is a single octet that may be set to any valid struct code within the given class-code. The first six octets are then followed by the packing flags and encoded field data. The presence and quantity of packing-flags, as well as the specific fields are determined by the struct definition identified with the encoded class-code and struct-code. 4 OCTETs 1 OCTET 1 OCTET pack-width OCTETs n OCTETs +----------+------------+-------------+-------------------+------------+ | size | class-code | struct-code | packing-flags | field-data | +----------+------------+-------------+-------------------+------------+ uint32 n = (size - 2 - pack-width) struct32 = size class-code struct-code packing-flags field-data size = uint32 class-code = OCTET ; zero for top-level structs struct-code = OCTET ; together with class-code identifies the struct ; definition which determines the pack-width and ; fields packing-flags = 0*4 OCTET ; pack-width OCTETs field-data = *OCTET ; (size - 2 - pack-width) OCTETs The bin40 type consists of five consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-------------+------------+------------+ | octet-one | octet-two | octet-three | octet-four | octet-five | +-----------+-----------+-------------+------------+------------+ bin40 = 5 OCTET The dec32 type is decimal value with a variable number of digits following the decimal point. It is encoded as an 8-bit unsigned integral value representing the number of decimal places. This is followed by the signed integral value encoded using a 32-bit two's complement representation in network byte order. The former value is referred to as the exponent of the divisor. The latter value is the mantissa. The decimal value is given by: mantissa / 10^exponent. 1 OCTET 4 OCTETs +----------+----------+ | exponent | mantissa | +----------+----------+ uint8 int32 dec32 = exponent mantissa exponent = uint8 mantissa = int32 The bin72 type consists of nine consecutive octets of opaque binary data. 1 OCTET 1 OCTET 1 OCTET 1 OCTET +-----------+-----------+-----+-------------+------------+ | octet-one | octet-two | ... | octet-eight | octet-nine | +-----------+-----------+-----+-------------+------------+ bin64 = 9 OCTET The dec64 type is decimal value with a variable number of digits following the decimal point. It is encoded as an 8-bit unsigned integral value representing the number of decimal places. This is followed by the signed integral value encoded using a 64-bit two's complement representation in network byte order. The former value is referred to as the exponent of the divisor. The latter value is the mantissa. The decimal value is given by: mantissa / 10^exponent. 1 OCTET 8 OCTETs +----------+----------+ | exponent | mantissa | +----------+----------+ uint8 int64 dec64 = exponent mantissa exponent = uint8 mantissa = int64 The void type is used within tagged data structures such as maps and lists to indicate an empty value. The void type has no value and is encoded as an empty sequence of octets. The bit type is used to indicate that a packing flag within a packed struct is being used to represent a boolean value based on the presence of an empty value. The bit type has no value and is encoded as an empty sequence of octets. During the initial connection negotiation, the two peers must agree upon a maximum frame size. This constant defines the minimum value to which the maximum frame size can be set. By defining this value, the peers can guarantee that they can send frames of up to this size until they have agreed a definitive maximum frame size for that connection. Segments are defined in . The segment domain defines the valid values that may be used for the segment indicator within the frame header. The frame type indicator for Control segments (see ). The frame type indicator for Command segments (see ). The frame type indicator for Header segments (see ). The frame type indicator for Body segments (see ). Tracks are defined in . The track domain defines the valid values that may used for the track indicator within the frame header The track used for all controls. All controls defined in this specification MUST be sent on track 0. The track used for all commands. All commands defined in this specification MUST be sent on track 1. An array of values of type str16. The connection class provides controls 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 The connection closed normally. 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. A valid frame header cannot be formed from the incoming byte stream. The amqp-url domain defines a format for identifying an AMQP Server. It is used to provide alternate hosts in the case where a client has to reconnect because of failure, or because the server requests the client to do so upon initial connection. port = number]]> Used to provide a list of alternate hosts. This control starts the connection negotiation process by telling the client the supported security mechanisms and locales from which the client can choose. If the server cannot support the protocol specified in the protocol header, it MUST close the socket connection without sending any response control. The client sends a protocol header containing an invalid protocol name. The server must respond by closing the connection. 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 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. A list of the message locales that the server supports. 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 control 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 control, 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 control challenges the client to provide more information. Challenge information, a block of opaque binary data passed to the security mechanism. This control 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 control 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. If this is not set it 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. If this is not set 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 max-frame-size has been negotiated, both peers MUST accept frames of up to MIN-MAX-FRAME-SIZE octets large, and the minimum negotiated value for max-frame-size is also MIN-MAX-FRAME-SIZE. Client connects to server and sends a large properties field, creating a frame of MIN-MAX-FRAME-SIZE octets. The server must accept this frame. The minimum delay, in seconds, of the connection heartbeat supported by the server. If this is not set it means the server does not support sending heartbeats. The maximum delay, in seconds, of the connection heartbeat supported by the server. If this is not set it means the server has no maximum. The heartbeat-max value must be greater than or equal to the value supplied in the heartbeat-min field. If no heartbeat-min is supplied, then the heartbeat-max field MUST remain empty. This control 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 implementers. If the client agrees to a channel-max of N channels, then the channels available for communication between client and server are precisely the channels numbered 0 to (N-1). The largest frame size that the client and server will use for the connection. If it is not set 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 max-frame-size limit applies principally to content frames, where large contents can be broken into frames of arbitrary size. Until the max-frame-size has been negotiated, both peers MUST accept frames of up to MIN-MAX-FRAME-SIZE octets large, and the minimum negotiated value for max-frame-size is also MIN-MAX-FRAME-SIZE. If the client specifies a max-frame-size 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 implementers. A peer MUST NOT send frames larger than the agreed-upon size. A peer that receives an oversized frame MUST close the connection with the framing-error close-code. The delay, in seconds, of the connection heartbeat chosen by the client. If it is not set it means the client does not want a heartbeat. The chosen heartbeat MUST be in the range supplied by the heartbeat-min and heartbeat-max fields of connection.tune. The heartbeat field MUST NOT be set if the heartbeat-min field of connection.tune was not set by the server. This control 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. The server can use this to determine how to process the client's connection request. In a configuration with multiple collaborating servers, the server may respond to a connection.open control 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 control. If it cannot accept the client's connection request it should respond by closing the connection with a suitable reply code. This control signals to the client that the connection is ready for use. Specifies an array of equivalent or alternative hosts that the server knows about, which will normally include the current server itself. Each entry in the array will be in the form of an IP address or DNS name, optionally followed by a colon and a port number. Clients can cache this information and use it when reconnecting to a server after a failure. This field may be empty. This control redirects the client to another server, based on the requested virtual host and/or capabilities. When getting the connection.redirect control, 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. An array of equivalent or alternative hosts that the server knows about. The heartbeat control may be used to generate artificial network traffic when a connection is idle. If a connection is idle for more than twice the negotiated heartbeat delay, the peers MAY be considered disconnected. This control indicates that the sender wants to close the connection. The reason for close is indicated with the reply-code and reply-text. The channel this control is sent on MAY be used to indicate which channel caused the connection to close. Indicates the reason for connection closure. This text can be logged as an aid to resolving issues. This control confirms a connection.close control 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 control SHOULD log the error. A session is a named interaction between two peers. Session names are chosen by the upper layers and may be used indefinitely. The model layer may associate long-lived or durable state with a given session name. The session layer provides transport of commands associated with this interaction. The controls defined within this class are specified in terms of the "sender" of commands and the "receiver" of commands. Since both client and server send and receive commands, the overall session dialog is symmetric, however the semantics of the session controls are defined in terms of a single sender/receiver pair, and it is assumed that the client and server will each contain both a sender and receiver implementation. The transport MUST be attached in order to use any control other than "attach", "attached", "detach", or "detached". A peer receiving any other control on a detached transport MUST discard it and send a session.detached with the "not-attached" reason code. The sender of commands. The receiver of commands. The session name uniquely identifies an interaction between two peers. It is scoped to a given authentication principal. The session was detached by request. The session is currently attached to another transport. The transport is currently attached to another session. The transport is not currently attached to any session. Command data was received prior to any use of the command-point control. The session header appears on commands after the class and command id, but prior to command arguments. Request notification of completion for this command. Requests that the current transport be attached to the named session. Success or failure will be indicated with an attached or detached response. This control is idempotent. A session MUST NOT be attached to more than one transport at a time. A transport MUST NOT be attached to more than one session at a time. Attaching a session to its current transport MUST succeed and result in an attached response. Attachment to the same session name from distinct authentication principals MUST succeed. Identifies the session to be attached to the current transport. If set then a busy session will be forcibly detached from its other transport and reattached to the current transport. Confirms successful attachment of the transport to the named session. Identifies the session now attached to the current transport. Detaches the current transport from the named session. Identifies the session to detach. Confirms detachment of the current transport from the named session. Identifies the detached session. Identifies the reason for detaching from the named session. This control may be sent by either the sender or receiver of commands. It requests that the execution timeout be changed. This is the minimum amount of time that a peer must preserve execution state for a detached session. The handler of this request MUST set his timeout to the maximum allowed value less than or equal to the requested timeout, and MUST convey the chosen timeout in the response. The requested timeout for execution state in seconds. If not set, this control requests that execution state is preserved indefinitely. This control may be sent by the either the sender or receiver of commands. It is a one-to-one reply to the request-timeout control that indicates the granted timeout for execution state. The timeout for execution state. If not set, then execution state is preserved indefinitely. This control is sent by the sender of commands and handled by the receiver of commands. This establishes the sequence numbers associated with all subsequent command data sent from the sender to the receiver. The subsequent command data will be numbered starting with the values supplied in this control and proceeding sequentially. This must be used at least once prior to sending any command data on newly attached transports. If command data is sent on a newly attached transport the session MUST be detached with an "unknown-id" reason-code. If the offset is zero, the next data frame MUST have the first-frame and first-segment flags set. Violation of this is a framing error. If the offset is nonzero, the next data frame MUST NOT have both the first-frame and first-segment flag set. Violation of this is a framing error. This control is sent by the receiver of commands and handled by the sender of commands. It informs the sender of what commands and command fragments are expected at the receiver. This control is only sent in response to a flush control with the expected flag set. The expected control is never sent spontaneously. The set of expected commands MUST include the next command after the highest seen command. The set of expected commands MUST have zero elements if and only if the sender holds no execution state for the session (i.e. it is a new session). If a command-id appears in the commands field, it MUST NOT appear in the fragments field. When choice is permitted, a command MUST appear in the commands field rather than the fragments field. This control is sent by the receiver of commands and handled by the sender of commands. This sends the set of commands that will definitely be completed by this peer to the sender. This excludes commands known by the receiver to be considered confirmed or complete at the sender. This control must be sent if the partner requests the set of confirmed commands using the session.flush control with the confirmed flag set. This control may be sent spontaneously. One reason for separating confirmation from completion is for large persistent messages, where the receipt (and storage to a durable store) of part of the message will result in less data needing to be replayed in the case of transport failure during transmission. A simple implementation of an AMQP client or server may be implemented to take no action on receipt of session.confirmed controls, and take action only when receiving session.completed controls. A simple implementation of an AMQP client or server may be implemented such that it never spontaneously sends session.confirmed and that when requested for the set of confirmed commands (via the session.flush control) it responds with the same set of commands as it would to when the set of completed commands was requested (trivially all completed commands are confirmed). If a command has durable implications, it MUST NOT be confirmed until the fact of the command has been recorded on durable media. If a command-id appears in the commands field, it MUST NOT appear in the fragments field. When choice is permitted, a command MUST appear in the commands field rather than the fragments field. Command-ids included in prior known-complete replies MUST be excluded from the set of all confirmed commands. This control is sent by the receiver of commands, and handled by the sender of commands. It informs the sender of all commands completed by the receiver. This excludes commands known by the receiver to be considered complete at the sender. The sender MUST eventually reply with a known-completed set that covers the completed ids. The known-complete reply MAY be delayed at the senders discretion if the timely-reply field is not set. Multiple replies may be merged by sending a single known-completed that includes the union of the merged command-id sets. The ids of all completed commands. This excludes commands known by the receiver to be considered complete at the sender. The sender MUST consider any completed commands to also be confirmed. Command-ids included in prior known-complete replies MUST be excluded from the set of all completed commands. If set, the sender is no longer free to delay the known-completed reply. This control is sent by the sender of commands, and handled by the receiver of commands. It is sent in reply to one or more completed controls from the receiver. It informs the receiver that commands are known to be completed by the sender. The sender need not keep state to generate this reply. It is sufficient to reply to any completed control with an exact echo of the completed ids. The set of completed commands for one or more session.completed controls. The receiver MUST treat any of the specified commands to be considered by the sender as confirmed as well as completed. This control is sent by the sender of commands and handled by the receiver of commands. It requests that the receiver produce the indicated command sets. The receiver should issue the indicated sets at the earliest possible opportunity. This control is sent by the sender of commands and handled by the receiver of commands. It sends command ranges for which there will be no further data forthcoming. The receiver should proceed with the next available commands that arrive after the gap. The command-ids covered by a session.gap MUST be added to the completed and confirmed sets by the receiver. If a session.gap covers a partially received command, the receiving peer MUST treat the command as aborted. If a session.gap covers a completed or confirmed command, the receiving peer MUST continue to treat the command as completed or confirmed. The set of command-ids that are contained in this gap. The execution class provides commands that carry execution information about other model level commands. 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 command that was not allowed because some precondition failed. A server entity the client is working with has been deleted. The peer sent a command that is not permitted in the current state of the session. The command segments could not be decoded. The client exceeded its resource allocation. The peer tried to use a command a manner that is inconsistent with the rules described in the specification. The command argument is malformed, i.e. it does not fall within the specified domain. The illegal-argument exception can be raised on execution of any command which has domain valued fields. The peer tried to use functionality that is not implemented in its partner. The peer could not complete the command because of an internal error. The peer may require intervention by an operator in order to resume normal operations. An invalid argument was passed to a command, and the operation could not proceed. An invalid argument is not illegal (see illegal-argument), i.e. it matches the domain definition; however the particular value is invalid in this context. This command is complete when all prior commands are completed. This command carries data resulting from the execution of a command. This command informs a peer of an execution exception. The command-id, when given, correlates the error to a specific command. The command-id of the command which caused the exception. If the exception was not caused by a specific command, this value is not set. The zero based index of the exceptional field within the arguments to the exceptional command. If the exception was not caused by a specific field, this value is not set. The description provided is implementation defined, but MUST be in the language appropriate for the selected locale. The intention is that this description is suitable for logging or alerting output. The message class provides commands that support an industry-standard messaging model. START: The message has yet to be sent to the recipient. NOT-ACQUIRED: The message has been sent to the recipient, but is not acquired by the recipient. ACQUIRED: The message has been sent to and acquired by the recipient. END: The transfer is complete. END]]> | /|\ | | +-------------------------------+ message = *:TRANSFER [ R:ACQUIRE ] [ R:ACCEPT / R:REJECT / R:RELEASE ] / *:RESUME / *:SET-FLOW-MODE / *:FLOW / *:STOP / C:SUBSCRIBE / C:CANCEL / C:FLUSH The server SHOULD respect the delivery-mode property of messages and SHOULD make a best-effort to hold persistent 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 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 message.flow command to slow or stop a message publisher when necessary. 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 and 9 are treated as two distinct levels. The server SHOULD implement distinct priority levels in the following manner: If the server implements n distinct priorities then priorities 0 to 5 - ceiling(n/2) should be treated equivalently and should be the lowest effective priority. The priorities 4 + floor(n/2) should be treated equivalently and should be the highest effective priority. The priorities (5 - ceiling(n/2)) to (4 + floor(n/2)) inclusive must be treated as distinct priorities. Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3 distinct priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and 3, 4 and 5 are distinct. This scheme ensures that if two priorities are distinct for a server which implements m separate priority levels they are also distinct for a server which implements n different priority levels where n > m. 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. Subscribe and verify that messages arrive in same order as originally published. Specifies the destination to which the message is to be transferred. Controls how the sender of messages is notified of successful transfer. Successful transfer is signaled by message.accept. An acquired message (whether acquisition was implicit as in pre-acquired mode or explicit as in not-acquired mode) is not considered transferred until a message.accept that includes the transfer command is received. Successful transfer is assumed when accept-mode is "pre-acquired". Messages transferred with an accept-mode of "not-acquired" cannot be acquired when accept-mode is "none". Indicates whether a transferred message can be considered as automatically acquired or whether an explicit request is necessary in order to acquire it. the message is acquired when the transfer starts the message is not acquired when it arrives, and must be explicitly acquired by the recipient Code specifying the reason for a message reject. Rejected for an unspecified reason. Delivery was attempted but there were no queues which the message could be routed to. The rejected message had the immediate flag set to true, but at the time of the transfer at least one of the queues to which it was to be routed did not have any subscriber able to take the message. A resume-id serves to identify partially transferred message content. The id is chosen by the sender, and must be unique to a given user. A resume-id is not expected to be unique across users. Used to set the reliability requirements for a message which is transferred to the server. 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. 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 of 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. Used to assign a priority to a message transfer. Priorities range from 0 (lowest) to 9 (highest). Lowest possible priority message. Very low priority message Low priority message. Below average priority message. Medium priority message. Above average priority message High priority message Higher priority message Very high priority message. Highest possible priority message. If set on a message that is not routable the broker can discard it. If not set, an unroutable message should be handled by reject when accept-mode is explicit; or by routing to the alternate-exchange if defined when accept-mode is none. If the immediate flag is set to true on a message transferred to a Server, then the message should be considered unroutable (and not delivered to any queues) if, for any queue that it is to be routed to according to the standard routing behavior, there is not a subscription on that queue able to receive the message. The treatment of unroutable messages is dependent on the value of the discard-unroutable flag. The immediate flag is ignored on transferred to a Client. This boolean flag indicates that the message may have been previously delivered to this or another client. If the redelivered flag is set on transfer to a Server, then any delivery of the message from that Server to a Client must also have the redelivered flag set to true. The server MUST try to signal redelivered messages when it can. When redelivering a message that was not successfully accepted, the server SHOULD deliver it to the original client if possible. Create a shared queue and publish a message to the queue. Subscribe using explicit accept-mode, but do not accept the message. Close the session, reconnect, and subscribe to the queue again. The message MUST arrive with the redelivered flag set. The client should not rely on the redelivered field to detect duplicate messages where publishers may themselves produce duplicates. A fully robust client should be able to track duplicate received messages on non-transacted, and locally-transacted sessions. Message priority, which can be between 0 and 9. Messages with higher priorities may be delivered before those with lower priorities. The delivery mode may be non-persistent or persistent. Duration in milliseconds for which the message should be considered "live". If this is set 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 transferred between brokers before delivery to a final subscriber the ttl should be decremented before peer to peer transfer and both timestamp and expiration should be cleared. The timestamp is set by the broker on arrival of the message. 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 command and the current time. (ttl=expiration - timestamp) Identifies the exchange specified in the destination field of the message.transfer used to publish the message. This MUST be set by the broker upon receipt of a message. 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 a binding-key identical to the routing-key of the message. When a resume-id is provided the recipient MAY use it to retain message data should the session expire while the message transfer is still incomplete. When a resume-ttl is provided the recipient MAY use it has a guideline for how long to retain the partially complete data when a resume-id is specified. If no resume-id is specified then this value should be ignored. These properties permit the transfer of message fragments. These may be used in conjunction with byte level flow control to limit the rate at which large messages are received. Only the first fragment carries the delivery-properties and message-properties. Syntactically each fragment appears as a complete message to the lower layers of the protocol, however the model layer is required to treat all the fragments as a single message. For example all fragments must be delivered to the same client. In pre-acquired mode, no message fragments can be delivered by the broker until the entire message has been received. True if this fragment contains the start of the message, false otherwise. True if this fragment contains the end of the message, false otherwise. This field may optionally contain the size of the fragment. The reply-to domain provides a simple address structure for replying to to a message to a destination within the same virtual-host. The length of the body segment in bytes. Message-id is an optional property of UUID type which uniquely identifies a message within the message system. The message producer is usually responsible for setting the message-id. The server MAY discard a message as a duplicate if the value of the message-id matches that of a previously received message. Duplicate messages MUST still be accepted if transferred with an accept-mode of "explicit". A message-id MUST be unique within a given server instance. A message-id 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. 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-15. The identity of the user responsible for producing the message. The client sets this value, and it is authenticated by the broker. The server MUST produce an unauthorized-access exception if the user-id field is set to a principle for which the client is not authenticated. The identity of the client application responsible for producing the message. This is a collection of user-defined headers or properties which may be set by the producing client and retrieved by the consuming client. Credit based flow control. Window based flow control. Indicates a value specified in messages. Indicates a value specified in bytes. This command transfers a message between two peers. When a client uses this command 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. The client may request a broker to transfer messages to it, from a particular queue, by issuing a subscribe command. The subscribe command specifies the destination that the broker should use for any resulting transfers. If a transfer to an exchange occurs within a transaction, then it is not available from the queue until the transaction commits. It is not specified whether routing takes place when the transfer is received or when the transaction commits. Specifies the destination to which the message is to be transferred. The server MUST accept a blank destination to mean the default exchange. If the destination refers to an exchange that does not exist, the peer MUST raise a session exception. Indicates whether message.accept, session.complete, or nothing at all is required to indicate successful transfer of the message. Indicates whether or not the transferred message has been acquired.

Accepts the message. Once a transfer is accepted, the command-id may no longer be referenced from other commands. The recipient MUST have acquired a message in order to accept it. Identifies the messages previously transferred that should be accepted. Indicates that the message transfers are unprocessable in some way. A server may reject a message if it is unroutable. A client may reject a message if it is invalid. A message may be rejected for other reasons as well. Once a transfer is rejected, the command-id may no longer be referenced from other commands. When a client rejects a message, the server MUST deliver that message to the alternate-exchange on the queue from which it was delivered. If no alternate-exchange is defined for that queue the broker MAY discard the message. The recipient MUST have acquired a message in order to reject it. If the message is not acquired any reject MUST be ignored. Identifies the messages previously transferred that should be rejected. Code describing the reason for rejection. Text describing the reason for rejection. Release previously transferred messages. When acquired messages are released, they become available for acquisition by any subscriber. Once a transfer is released, the command-id may no longer be referenced from other commands. Acquired messages that have been released MAY subsequently be delivered out of order. Implementations SHOULD ensure that released messages keep their position with respect to undelivered messages of the same priority. Indicates the messages to be released. By setting set-redelivered to true, any acquired messages released to a queue with this command will be marked as redelivered on their next transfer from that queue. If this flag is not set, then an acquired message will retain its original redelivered status on the queue. Messages that are not acquired are unaffected by the value of this flag. Acquires previously transferred messages for consumption. The acquired ids (if any) are sent via message.acquired. Each acquire MUST produce exactly one message.acquired even if it is empty. Indicates the messages to be acquired. Identifies a set of previously transferred messages that have now been acquired. Indicates the acquired messages. This command resumes an interrupted transfer. The recipient should return the amount of partially transferred data associated with the given resume-id, or zero if there is no data at all. If a non-zero result is returned, the recipient should expect to receive message fragment(s) containing the remainder of the interrupted message. The destination to which the remaining message fragments are transferred. If the destination does not exist, the recipient MUST close the session. The name of the transfer being resumed. If the resume-id is not known, the recipient MUST return an offset of zero. Indicates the amount of data already transferred. This command asks the server to start a "subscription", which is a request for messages from a specific queue. Subscriptions last as long as the session they were created on, or until the client cancels them. The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no limit except as defined by available resources. Create a queue and create subscriptions on that queue until the server closes the connection. Verify that the number of subscriptions created was at least sixteen and report the total number. The default flow mode for new subscriptions is window-mode. If the queue for this subscription is deleted, any subscribing sessions MUST be closed. This exception may occur at any time after the subscription has been completed. If the queue for this subscription does not exist, then the subscribing session MUST be closed. Immediately after a subscription is created, the initial byte and message credit for that destination is zero. Specifies the name of the subscribed queue. The client specified name for the subscription. This is used as the destination for all messages transferred from this subscription. The destination is scoped to the session. The client MUST NOT specify a destination that refers to an existing subscription on the same session. Attempt to create two subscriptions on the same session with the same non-empty destination. The accept-mode to use for messages transferred from this subscription. The acquire-mode to use for messages transferred from this subscription. Request an exclusive subscription. This prevents other subscribers from subscribing to the queue. The server MUST NOT grant an exclusive subscription to a queue that already has subscribers. Open two connections to a server, and in one connection create a shared (non-exclusive) queue and then subscribe to the queue. In the second connection attempt to subscribe to the same queue using the exclusive option. Requests that the broker use the supplied resume-id when transferring messages for this subscription. Requested duration in milliseconds for the broker use as resume-ttl when transferring messages for this subscription. The syntax and semantics of these arguments depends on the providers implementation. This command cancels a subscription. This does not affect already delivered messages, but it does mean the server will not send any more messages for that subscription. The client may receive an arbitrary number of messages in between sending the cancel command and receiving notification that the cancel command is complete. Canceling a subscription MUST NOT affect pending transfers. A transfer made prior to canceling transfers to the destination MUST be able to be accepted, released, acquired, or rejected after the subscription is canceled. If the subscription specified by the destination is not found, the server MUST close the session. Sets the mode of flow control used for a given destination to either window or credit based flow control. With credit based flow control, the sender of messages continually maintains its current credit balance with the recipient. The credit balance consists of two values, a message count, and a byte count. Whenever message data is sent, both counts must be decremented. If either value reaches zero, the flow of message data must stop. Additional credit is received via the message.flow command. The sender MUST NOT send partial assemblies. This means that if there is not enough byte credit available to send a complete message, the sender must either wait or use message fragmentation (see the fragment-properties header struct) to send the first part of the message data in a complete assembly. Window based flow control is identical to credit based flow control, however message transfer completion implicitly grants a single unit of message credit, and the size of the message in byte credits for each completed message transfer. Completion of the transfer command with session.completed is the only way credit is implicitly updated; message.accept, message.release, message.reject, tx.commit and tx.rollback have no effect on the outstanding credit balances. The byte count is decremented by the payload size of each transmitted frame with segment type header or body appearing within a message.transfer command. Note that the payload size is the frame size less the frame header size. Mode switching may only occur if both the byte and message credit balance are zero. There are three ways for a recipient of messages to be sure that the sender's credit balances are zero: 1) The recipient may send a message.stop command to the sender. When the recipient receives notification of completion for the message.stop command, it knows that the sender's credit is zero. 2) The recipient may perform the same steps described in (1) with the message.flush command substituted for the message.stop command. 3) Immediately after a subscription is created with message.subscribe, the credit for that destination is zero. Prior to receiving an explicit set-flow-mode command, a peer MUST consider the flow-mode to be window. The new flow control mode. This command controls the flow of message data to a given destination. It is used by the recipient of messages to dynamically match the incoming rate of message flow to its processing or forwarding capacity. Upon receipt of this command, the sender must add "value" number of the specified unit to the available credit balance for the specified destination. A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for the given unit until the credit balance is zeroed with message.stop or message.flush. The unit of value. If the value is not set then this indicates an infinite amount of credit. Forces the sender to exhaust his credit supply. The sender's credit will always be zero when this command completes. The command completes when immediately available message data has been transferred, or when the credit supply is exhausted. On receipt of this command, a producer of messages MUST set his credit to zero for the given destination. When notifying of completion, credit MUST be zero and no further messages will be sent until such a time as further credit is received. 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 command sets the session to use standard transactions. The client must use this command exactly once on a session before using the Commit or Rollback commands. A client MUST NOT select standard transactions on a session that is already transactional. A client MUST NOT select standard transactions on a session that is already enlisted in a distributed transaction. On a session on which tx.select has been issued, a client MUST NOT issue a message.subscribe command with the accept-mode property set to any value other than explicit. Similarly a tx.select MUST NOT be issued on a session on which a there is a non cancelled subscriber with accept-mode of none. This command commits all messages published and accepted in the current transaction. A new transaction starts immediately after a commit. In more detail, the commit acts on all messages which have been transferred from the Client to the Server, and on all acceptances of messages sent from Server to Client. Since the commit acts on commands sent in the same direction as the commit command itself, there is no ambiguity on the scope of the commands being committed. Further, the commit will not be completed until all preceding commands which it affects have been completed. Since transactions act on explicit accept commands, the only valid accept-mode for message subscribers is explicit. For transferring messages from Client to Server (publishing) all accept-modes are permitted. A client MUST NOT issue tx.commit on a session that has not been selected for standard transactions with tx.select. This command abandons the current transaction. In particular the transfers from Client to Server (publishes) and accepts of transfers from Server to Client which occurred in the current transaction are discarded. A new transaction starts immediately after a rollback. In more detail, when a rollback is issued, any the effects of transfers which occurred from Client to Server are discarded. The Server will issue completion notification for all such transfers prior to the completion of the rollback. Similarly the effects of any message.accept issued from Client to Server prior to the issuance of the tx.rollback will be discarded; and notification of completion for all such commands will be issued before the issuance of the completion for the rollback. After the completion of the rollback, the client will still hold the messages which it has not yet accepted (including those for which accepts were previously issued within the transaction); i.e. the messages remain "acquired". If the Client wishes to release those messages back to the Server, then appropriate message.release commands must be issued. A client MUST NOT issue tx.rollback on a session that has not been selected for standard transactions with tx.select. This provides the X-Open XA distributed transaction protocol support. It allows a session to be selected for use with distributed transactions, the transactional boundaries for work on that session to be demarcated and allows the transaction manager to coordinate transaction outcomes. dtx-demarcation = C:SELECT *demarcation demarcation = C:START C:END dtx-coordination = *coordination coordination = command / outcome / recovery command = C:SET-TIMEOUT / C:GET-TIMEOUT outcome = one-phase-commit / one-phase-rollback / two-phase-commit / two-phase-rollback one-phase-commit = C:COMMIT one-phase-rollback = C:ROLLBACK two-phase-commit = C:PREPARE C:COMMIT two-phase-rollback = C:PREPARE C:ROLLBACK recovery = C:RECOVER *recovery-outcome recovery-outcome = one-phase-commit / one-phase-rollback / C:FORGET Enabling XA transaction support on a session requires 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. Normal execution completion (no error). The rollback was caused for an unspecified reason. A transaction branch took too long. The transaction branch may have been heuristically completed. The transaction branch has been heuristically committed. The transaction branch has been heuristically rolled back. The transaction branch has been heuristically committed and rolled back. The transaction branch was read-only and has been committed. An xid uniquely identifies a transaction branch. This command sets the session to use distributed transactions. The client must use this command at least once on a session before using XA demarcation operations. This command is called when messages should be produced and consumed on behalf a transaction branch identified by xid. If the command is invoked in an improper context (see class grammar) then the server MUST send a session exception. 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 an exception. If join and resume are specified then the server MUST raise an exception. Specifies the xid of the transaction branch to be started. If xid is already known by the broker then the server MUST raise an exception. 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 an exception. Indicate that the start applies to resuming a suspended transaction branch specified. This 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 command is called when the work done on behalf a transaction branch finishes or needs to be suspended. If the command is invoked in an improper context (see class grammar) then the server MUST raise an exception. If suspend and fail are specified then the server MUST raise an exception. 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. Specifies the xid of the transaction branch to be ended. The session 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 received. Should an implementation elect to implement this behavior, and this bit is set, then then the transaction branch SHOULD be marked as rollback-only and the end result SHOULD have the xa-rbrollback status 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 command with resume specified. This command 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 behavior, then this value should be selected if the dtx.end.fail bit was set. xa-rbtimeout: The work represented by this transaction branch took too long. Commit the work done on behalf a transaction branch. This command commits the work associated with xid. Any produced messages are made available and any consumed messages are discarded. If the command is invoked in an improper context (see class grammar) then the server MUST raise an exception. 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 an exception. If this command is called when xid is still associated with a session then the server MUST raise an exception. Used to indicate whether one-phase or two-phase commit is used. The one-phase bit MUST be set if a commit is sent without a preceding prepare. The one-phase bit MUST NOT be set if the commit has been preceded by prepare. This 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 command is called to forget about a heuristically completed transaction branch. If the command is invoked in an improper context (see class grammar) then the server MUST raise an exception. 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 an exception. If this command is called when xid is still associated with a session then the server MUST raise an exception. This command obtains the current transaction timeout value in seconds. If set-timeout was not used prior to invoking this command, the return value is the default timeout; otherwise, the value used in the previous set-timeout call is returned. 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 an exception. Returns the value of the timeout last specified through set-timeout. The current transaction timeout value in seconds. This command prepares for commitment any message produced or consumed on behalf of xid. If the command is invoked in an improper context (see class grammar) then the server MUST raise an exception. Once this command 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. 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 an exception. If this command is called when xid is still associated with a session then the server MUST raise an exception. This command 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 command is called to obtain a list of transaction branches that are in a prepared or heuristically completed state. 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. Array containing the xids to be recovered (xids that are in a prepared or heuristically completed state). This command rolls back the work associated with xid. Any produced messages are discarded and any consumed messages are re-enqueued. If the command is invoked in an improper context (see class grammar) then the server MUST raise an exception. 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 an exception. If this command is called when xid is still associated with a session then the server MUST raise an exception. This command 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. Once set, this timeout value is effective until this command is reinvoked with a different value. A value of zero resets the timeout value to the default value. 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 an exception. The transaction timeout value in seconds. Exchanges match and distribute messages across queues. Exchanges can be configured in the server or created at runtime. exchange = C:DECLARE / C:DELETE / C:QUERY 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 commands (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 commands (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 command (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. The exchange name is a client-selected string that identifies the exchange for publish commands. Exchange names may consist of any mixture of digits, letters, and underscores. Exchange names are scoped by the virtual host. This command 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. Exchange names starting with "amq." are reserved for pre-declared and standardized 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 command. If the client attempts to create an exchange which the server does not recognize, an exception MUST be sent. In the event that a message cannot be routed, this is the name of the exchange to which the message will be sent. Messages transferred using message.transfer will be routed to the alternate-exchange only if they are sent with the "none" accept-mode, and the discard-unroutable delivery property is set to false, and there is no queue to route to for the given message according to the bindings on this exchange. If alternate-exchange is not set (its name is an empty string), unroutable messages that would be sent to the alternate-exchange 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 an exception. 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 an exception. 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 automatically when there remain no bindings between the exchange and any queue. Such an exchange will not be automatically deleted until at least one binding has been made to prevent the immediate deletion of the exchange upon creation. 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. If the arguments field contains arguments which are not understood by the server, it MUST raise an exception. This command deletes an exchange. When an exchange is deleted all queue bindings on the exchange are cancelled. The client MUST NOT attempt to delete an exchange that does not exist. The name of the exchange MUST NOT be a missing or empty string. An exchange MUST NOT be deleted if it is in use as an alternate-exchange by a queue or by another exchange. 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 an exception instead. If the exchange has queue bindings, and the if-unused flag is set, the server MUST NOT delete the exchange, but MUST raise and exception. This command is used to request information on a particular exchange. The name of the exchange for which information is requested. If not specified explicitly the default exchange is implied. This is sent 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. This command 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 ignore duplicate bindings - that is, two or more bind commands with the same exchange, queue, and binding-key - without treating these as an error. The value of the arguments used for the binding MUST NOT be altered by subsequent binding requests. A client binds a named queue to an exchange. The client then repeats the bind (with identical exchange, queue, and binding-key). The second binding should use a different value for the arguments field. Bindings between durable queues and durable exchanges are automatically durable and the server MUST 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. 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 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 binding-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. Specifies the name of the queue to bind. 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. The binding-key uniquely identifies a binding between a given (exchange, queue) pair. Depending on the exchange configuration, the binding key may be matched against the message routing key in order to make routing decisions. The match algorithm depends on the exchange type. Some exchange types may ignore the binding key when making routing decisions. Refer to the specific exchange type documentation. The meaning of an empty binding key depends on the exchange implementation. A set of arguments for the binding. The syntax and semantics of these arguments depends on the exchange class. If the arguments field contains arguments which are not understood by the server, it MUST raise an exception. This command unbinds a queue from an exchange. Specifies the name of the queue to unbind. If the queue does not exist the server MUST raise an exception. The name of the exchange to unbind from. If the exchange does not exist the server MUST raise an exception. The name of the exchange MUST NOT be a blank or empty string. Specifies the binding-key of the binding to unbind. If there is no matching binding-key the server MUST raise an exception. This command is used to request information on the bindings to a particular exchange. 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 binding-key of the binding of interest, if not populated the request will ignore the binding-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 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 binding-key. A bit which if set indicates that no binding was found from the specified exchange with the specified arguments. 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 / C:BIND / C:PURGE / C:DELETE / C:QUERY / 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 commands 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. The queue name identifies the queue within the virtual host. Queue names must have a length of between 1 and 255 characters inclusive, must start with a digit, letter or underscores ('_') character, and must be otherwise encoded in UTF-8. This command 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 binding-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 binding-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. Queue names starting with "amq." are reserved for pre-declared and standardized 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. The alternate-exchange field specifies how messages on this queue should be treated when they are rejected by a subscriber, or when they are orphaned by queue deletion. When present, rejected or orphaned messages MUST be routed to the alternate-exchange. In all cases the messages MUST be removed from the queue. If the alternate-exchange is not empty and if the queue already exists with a different alternate-exchange, then the declaration MUST result in an exception. if the alternate-exchange does not match the name of any existing exchange on the server, then an exception must be raised. 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 command to succeed. Client then attempts to declare a non-existent queue with the passive option, and the server must close the session with the correct exception. 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 queue definition MUST survive the server losing all transient memory, e.g. a machine 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 session at a time. Once a session declares an exclusive queue, that queue cannot be used by any other session until the declaring session 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 session, it MUST raise an exception. A client declares an exclusive named queue. A second client on a different session 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 session 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 session 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. 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. If the arguments field contains arguments which are not understood by the server, it MUST raise an exception. This command deletes a queue. When a queue is deleted any pending messages are sent to the alternate-exchange if defined, or discarded if it is not. Specifies the name of the queue to delete. If the queue name in this command is empty, the server MUST raise an exception. The queue must exist. If the client attempts to delete a non-existing queue the server MUST raise an exception. 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 an 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 an exception. This command removes all messages from a queue. It does not cancel subscribers. Purged messages are deleted without any formal "undo" mechanism. A call to purge MUST result in an empty queue. The server MUST NOT purge messages that have already been sent to a client but not yet accepted. 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. Specifies the name of the queue to purge. If the the queue name in this command is empty, the server MUST raise an exception. The queue MUST exist. Attempting to purge a non-existing queue MUST cause an exception. This command requests information about a queue. This is sent in response to queue.query, and conveys the requested information about a queue. If no queue with the specified name exists then none of the fields within the returned result struct will be populated. Reports the name of the queue. Reports the number of messages in the queue. Reports the number of subscribers for the queue. The file class provides commands 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 commands; these are not compatible with the staging model. Applications that need browsable file transfer should use Message content and the Message class. file = C:QOS S:QOS-OK / C:CONSUME S:CONSUME-OK / C:CANCEL / 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 command 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. The return code. The AMQP return codes are defined by this enum. The client attempted to transfer content larger than the server could accept. The exchange cannot route a message, most likely due to an invalid routing key. Only when the mandatory flag is set. 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. This command 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 command always depend on the content class semantics. Though the qos command 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. Pre-fetching gives a performance improvement. This field specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific limit". Note that other pre-fetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. Specifies a pre-fetch 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 pre-fetch 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 pre-fetch 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 command 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 command 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. Specifies the name of the queue to consume from. If the queue name in this command is empty, the server MUST raise an exception. Specifies the identifier for the consumer. The consumer tag is local to a connection, so two clients can use the same consumer tags. 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 an exception. The client MUST NOT specify a tag that is empty or blank. Attempt to create a consumers with an empty tag. 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. If the server cannot grant exclusive access to the queue when asked, - because there are other consumers active - it MUST raise an exception. If set, the server will not respond to the command. The client should not wait for a reply command. If the server could not complete the command it will raise an exception. A set of arguments for the consume. The syntax and semantics of these arguments depends on the providers implementation. This command provides the client with a consumer tag which it MUST use in commands that work with the consumer. Holds the consumer tag specified by the client or provided by the server. This command 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 identifier of the consumer to be cancelled. This command 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 command 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 commands. This command stages the message, sending the message content to the recipient from the octet offset specified in the Open-Ok command.

This command 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. 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 an exception. The server MUST accept a blank exchange name to mean the default exchange. The exchange MAY refuse file content in which case it MUST send an 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 command. 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 command. 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 command asynchronously without waiting for staging to finish. This command 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. This text can be logged as an aid to resolving issues. 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 command 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 command, then the server responds with Deliver commands 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 non-processable (possibly causing client applications to abort), and move the message to a dead letter queue. The server-assigned and session-specific delivery tag The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, meaning "all messages so far received". This boolean flag indicates that the message may have been previously delivered to this or another client. 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 command asynchronously without waiting for staging to finish. This command acknowledges one or more messages delivered via the Deliver command. The client can ask to confirm a single message or a set of messages up to and including a specific message. The identifier of the message being acknowledged 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. 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 command. 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 an exception if this is not the case. This command 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 command to interrupt delivery of a large message. The server SHOULD interpret this command as meaning that the client is unable to process the message at this time. A client MUST NOT use this command as a means of selecting messages to process. A rejected message MAY be discarded or dead-lettered, not necessarily passed to another client. the identifier of the message to be rejected 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 reject it on another. 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 commands 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 favor of high priority messages. stream = C:QOS S:QOS-OK / C:CONSUME S:CONSUME-OK / C:CANCEL / 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 command, the server must remove it from the queue. The return code. The AMQP return codes are defined by this enum. The client attempted to transfer content larger than the server could accept. The exchange cannot route a message, most likely due to an invalid routing key. Only when the mandatory flag is set. 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. This command 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 command always depend on the content class semantics. Though the qos command 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. Pre-fetching gives a performance improvement. This field specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific limit". Note that other pre-fetch limits may still apply. Specifies a pre-fetch 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 pre-fetch 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 pre-fetch 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 favor 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 command 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 command 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. Specifies the name of the queue to consume from. If the queue name in this command is empty, the server MUST raise an exception. Specifies the identifier for the consumer. The consumer tag is local to a connection, so two clients can use the same consumer tags. 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 an exception. The client MUST NOT specify a tag that is empty or blank. Attempt to create a consumers with an empty tag. If the no-local field is set the server will not send messages to the connection that published them. 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 an exception with return code 405 (resource locked). If set, the server will not respond to the command. The client should not wait for a reply command. If the server could not complete the command it will raise an exception. A set of arguments for the consume. The syntax and semantics of these arguments depends on the providers implementation. This command provides the client with a consumer tag which it may use in commands that work with the consumer. Holds the consumer tag specified by the client or provided by the server. This command 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. This command 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. 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 an exception. The server MUST accept a blank exchange name to mean the default exchange. The exchange MAY refuse stream content in which case it MUST respond with an 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 command. 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 command. 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 command 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. The localized reply text. This text can be logged as an aid to resolving issues. 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 command delivers a message to the client, via a consumer. In the asynchronous message delivery model, the client starts a consumer using the Consume command, then the server responds with Deliver commands as and when messages arrive for that consumer. 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. 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.