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. <