Return-Path: Delivered-To: apmail-incubator-qpid-commits-archive@locus.apache.org Received: (qmail 79052 invoked from network); 21 Aug 2008 03:01:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Aug 2008 03:01:02 -0000 Received: (qmail 38722 invoked by uid 500); 21 Aug 2008 03:01:00 -0000 Delivered-To: apmail-incubator-qpid-commits-archive@incubator.apache.org Received: (qmail 38684 invoked by uid 500); 21 Aug 2008 03:01:00 -0000 Mailing-List: contact qpid-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: qpid-dev@incubator.apache.org Delivered-To: mailing list qpid-commits@incubator.apache.org Received: (qmail 38675 invoked by uid 99); 21 Aug 2008 03:01:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Aug 2008 20:01:00 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Aug 2008 02:59:55 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 4CDED23889BA; Wed, 20 Aug 2008 19:59:55 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r687540 [2/3] - in /incubator/qpid/branches/qpid.rnr: java/common/ java/common/src/main/java/org/apache/qpid/transport/ java/common/src/main/java/org/apache/qpid/transport/network/ specs/ Date: Thu, 21 Aug 2008 02:59:54 -0000 To: qpid-commits@incubator.apache.org From: rhs@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20080821025955.4CDED23889BA@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml URL: http://svn.apache.org/viewvc/incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml?rev=687540&view=auto ============================================================================== --- incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml (added) +++ incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml Wed Aug 20 19:59:53 2008 @@ -0,0 +1,5102 @@ + + + + + + + + + + + + + + + + + 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 channel type identifies both a direction and a 15 bit channel number packed into a 16 bit + value. The channel number may be computed by treating the channel identifier as a uint16 and + masking off the most significant bit. The most significant bit of the channel identifier + indicates the direction of the channel. If this bit is zero, the channel identifier refers to + a channel number where the initiator of the network connection (i.e. the network client) is + the AMQP client. If this bit is one, the channel identifier refers to a channel number where + the initiator of the network connection (i.e. the network client) is the AMQP server. + + + + 1 BIT 15 BITs + +-----------+----------------+ + | direction | channel-number | + +-----------+----------------+ + MSB LSB + + + + channel = direction channel-number + direction = 1 BIT + channel-number = 15 BIT + + + + + + + + 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 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 ). + + + + + + + + + An array of values of type str16. + + + + + + + + + + The connection class provides controls for two peers to establish a network connection, and + for both peers to operate the connection thereafter. Either peer may operate in the server or + client roles. + + + + connection = open-connection + *use-connection + close-connection + open-connection = C:protocol-header + S:OPEN C:OPEN + [ sasl-exchange ] + sasl-exchange = C:SASL-INIT *( S:SASL-CHALLENGE C:SASL-RESPONSE ) C:SASL-DONE + use-connection = *channel + close-connection = S:CLOSE C:CLOSE + + + + + + + + + + The connection closed normally. + + + + + + An operator intervened to close the connection for some reason. The client may retry at + some later date. + + + + + + The SASL authentication exchange failed. + + + + + + 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. + + + + + + + + The connection was successfully authenticated. + + + + + Connection authentication failed. + + + + + + + + + + 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. + + + + + + + + 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 name of the virtual host to which the connection is being opened. The default virtual + host is the virtual host with name of length zero. It is not mandatory to provide such a + virtual host. + + + + + If the server supports multiple virtual hosts, it MUST enforce a full isolation 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 largest frame size that the peer proposes for the connection. If this is not set means + that the server does not impose any specific limit. + + + + + The max-frame-size established for the connection is the minimum of the two proposed + values. If neither peer sets a max-frame-size the established max-frame-size is + (2^16)-1. + + + + + + Until the max-frame-size has been negotiated, both peers MUST accept frames of up to + MIN-MAX-FRAME-SIZE octets large. + + + + + + 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 maximum number of channels available for session attachment by the recipient. For a + typical client this would be zero. For a typical server this would be the maximum number + of supported channels. + + + + + The channel-max value may never exceed 2^15. + + + + + + If a peer advertises a channel-max of N channels, then the channels available for + session attachment are precisely the channels numbered 0 to (N-1). + + + + + + + The proposed interval, in seconds, of the connection heartbeat desired by the sender. A + value of zero means heartbeats are not supported. If the value is not set, the sender + supports all heartbeat intervals. + + + + + The heartbeat-interval established is the minimum of the two proposed + heartbeat-intervals. If neither value is set, there is no heartbeat. + + + + + + + A list of the sasl security mechanisms supported by the sending peer. If the sending peer + does not require its partner to authenticate with it, this array may be empty or absent. + The server mechanisms are ordered in decreasing level of preference. + + + + + + A list of the locales that the peer supports. The locale defines the language in which the + peer will send protocol level error messages. This includes connection close text, reject + text, and session exception text. The default is the en_US locale. + + + + + The peer MUST support at least the en_US locale. Since this value is always supported, + it need not be supplied in the supported-locales array. + + + + + + + A list of locales that the sending peer will accept. This list is ordered in decreasing + level of preference. The receiving partner will chose the most preferred locale from its + supported-locales list. If none of the preferred locales are supported, en_US will be + chosen. Note that en_US need not be supplied in this list as it always the fallback. + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + + + Selects the sasl mechanism and provides the initial response if needed. + + + + + + + The name of the SASL mechanism used for the SASL exchange. + + + + + The mechanism chosen must be the one of the supported mechanisms supplied by the peer. + + + + + + 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 connection.open control, the server MUST close the connection without + sending any further data. + + + + + + + + A block of opaque data passed to the security mechanism. The contents of this data are + defined by the SASL security mechanism. + + + + + + + + + + + + + + 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 terminates the sasl dialog. + + + + + + + A reply-code indicating the disposition of the sasl dialog. + + + + + + + + + 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. + + + + + + + + + + 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. + + + | C1 C2 C3 C4 | C5 C6 | + +--------------+--------------------------+ +-----------------+-----------+ + complete replay queue complete work queue + + C1, C2, C3: completed at the receiver, known to be completed by the sender + C4: completed at the receiver, *not* known to be completed by the sender + C5, C6: received by the sender, but not yet completed + C7, C8, C9: transmitted by the sender, but not yet received + + Sender state: + last-completed: marks the tail of replay queue + last-sent: marks the head of replay queue + + Receiver state: + last-completed: marks the tail of the work queue + last-received: marks the head of work queue + + State exchanged periodically between the two endpoints of a full + duplex session. Each endpoint has both a sender and a receiver: + + (sender-completed, receiver-completed) + /|\ /|\ + | | + | allows the sender to shrink replay queue + | + allows the receiver to know that sender won't replay + + State exchanged between the two endpoints on open/resume: + + (last-sent, last-received) + /|\ /|\ + | | + | tells sender where to resume from + | (null for open) + | + tells receiver where to start counting command-ids on open + (null for resume)]]> + + + + 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. + + + + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + + + + + The id of the first command the peer can resend, this may be null. + + + + + + This field carries the id of the last command received by this peer for the session. This + field MUST be set if and only if the session has received commands. + + + + + + The requested timeout for execution state in seconds. If not set, this control requests + that execution state is preserved for the maximum duration permitted by the receiving + peer. + + + + + + + + + Signals the end of communication on this channel for this session in this direction. + + + + + + + + Identifies the detached session. + + + + + Identifies the reason for detaching from the named session. + + + + + + + + + + + This control carries ongoing session state between the two session endpoints. + + + + + + + + If set, the peer must respond with the state if its own session endpoint. + + + + + + The id of the last incoming command completed by the receiver. + + + + + + The id of the last outgoing command known by the sender to be complete. + + + + + + + + + + + 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. + + + + + + + + + + + + + + + + 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 [... 2785 lines stripped ...]