From 0b7a80ae60839ed3f907369dd75d099a3fb7a33d Mon Sep 17 00:00:00 2001 From: "Rafael H. Schloming" Date: Tue, 18 May 2010 19:31:50 +0000 Subject: removed external spec dependency git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@945839 13f79535-47bb-0310-9956-ffa450edef68 --- ruby/Rakefile | 5 +- ruby/lib/qpid/config.rb | 3 +- ruby/lib/qpid/specs/amqp.0-10-qpid-errata.xml | 6654 +++++++++++++++++++++++++ ruby/lib/qpid/specs/amqp.0-10.dtd | 246 + 4 files changed, 6904 insertions(+), 4 deletions(-) create mode 100644 ruby/lib/qpid/specs/amqp.0-10-qpid-errata.xml create mode 100644 ruby/lib/qpid/specs/amqp.0-10.dtd (limited to 'ruby') diff --git a/ruby/Rakefile b/ruby/Rakefile index a5159210a3..ba6e54448e 100644 --- a/ruby/Rakefile +++ b/ruby/Rakefile @@ -88,8 +88,9 @@ end PKG_FILES = FileList[ "LICENSE.txt", "NOTICE.txt", "Rakefile", "RELEASE_NOTES", - "lib/**/*.rb", "lib/*/spec_cache/*.rb*", "tests/**/*", "examples/**", "ext/**/*.[ch]", - "ext/**/MANIFEST", "ext/**/extconf.rb" + "lib/**/*.rb", "lib/**/*.xml", "lib/**/*.dtd", "lib/*/spec_cache/*.rb*", + "tests/**/*", "examples/**", "ext/**/*.[ch]", "ext/**/MANIFEST", + "ext/**/extconf.rb" ] DIST_FILES = FileList[ diff --git a/ruby/lib/qpid/config.rb b/ruby/lib/qpid/config.rb index 1a0942d5d5..b5b79cd309 100644 --- a/ruby/lib/qpid/config.rb +++ b/ruby/lib/qpid/config.rb @@ -21,8 +21,7 @@ module Qpid module Config def self.amqp_spec - dirs = [File::expand_path(File::join(File::dirname(__FILE__), "../../../specs")), - "/usr/share/amqp"] + dirs = [File::expand_path(File::join(File::dirname(__FILE__), "specs"))] dirs.each do |d| spec = File::join(d, "amqp.0-10-qpid-errata.xml") return spec if File::exists? spec diff --git a/ruby/lib/qpid/specs/amqp.0-10-qpid-errata.xml b/ruby/lib/qpid/specs/amqp.0-10-qpid-errata.xml new file mode 100644 index 0000000000..365928ea4e --- /dev/null +++ b/ruby/lib/qpid/specs/amqp.0-10-qpid-errata.xml @@ -0,0 +1,6654 @@ + + + + + + + + + + + + + + + + + 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. + + + + +
+ +
+ + + + + + + diff --git a/ruby/lib/qpid/specs/amqp.0-10.dtd b/ruby/lib/qpid/specs/amqp.0-10.dtd new file mode 100644 index 0000000000..2be198525a --- /dev/null +++ b/ruby/lib/qpid/specs/amqp.0-10.dtd @@ -0,0 +1,246 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.1