From a71fc76d0f605d1faa76f8aec7b4498c168aec46 Mon Sep 17 00:00:00 2001 From: Kim van der Riet Date: Fri, 22 Dec 2006 18:26:40 +0000 Subject: File tidy-up for AMQP version code: Removed old XSLT files; moved cluster.asl into spec directory; renamed spec files to better reflect version notation; updated java, c++ and python files to reference new names. git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid@489715 13f79535-47bb-0310-9956-ffa450edef68 --- cpp/gen/Makefile.am | 2 +- java/common/pom.xml | 3 +- java/common/protocol-version.xml | 8 - .../main/versions/ProtocolVersionList.java.tmpl | 40 - java/common/src/main/xsl/cluster.asl | 59 - java/common/src/main/xsl/framing.xsl | 64 - java/common/src/main/xsl/java.xsl | 248 - java/common/src/main/xsl/prepare1.xsl | 114 - java/common/src/main/xsl/prepare2.xsl | 69 - java/common/src/main/xsl/prepare3.xsl | 65 - java/common/src/main/xsl/readme.txt | 52 - java/common/src/main/xsl/registry.template | 25 - java/common/src/main/xsl/registry.xsl | 32 - java/common/src/main/xsl/utils.xsl | 207 - python/amqp-doc | 2 +- python/qpid/testlib.py | 2 +- specs/amqp-8.0.xml | 3987 --------------- specs/amqp.0-8.xml | 3987 +++++++++++++++ specs/amqp.0-9.xml | 5185 ++++++++++++++++++++ specs/cluster.0-8.xml | 59 + specs/cluster.0-9.xml | 59 + 21 files changed, 9294 insertions(+), 4975 deletions(-) delete mode 100644 java/common/src/main/versions/ProtocolVersionList.java.tmpl delete mode 100644 java/common/src/main/xsl/cluster.asl delete mode 100644 java/common/src/main/xsl/framing.xsl delete mode 100644 java/common/src/main/xsl/java.xsl delete mode 100644 java/common/src/main/xsl/prepare1.xsl delete mode 100644 java/common/src/main/xsl/prepare2.xsl delete mode 100644 java/common/src/main/xsl/prepare3.xsl delete mode 100644 java/common/src/main/xsl/readme.txt delete mode 100644 java/common/src/main/xsl/registry.template delete mode 100644 java/common/src/main/xsl/registry.xsl delete mode 100644 java/common/src/main/xsl/utils.xsl delete mode 100644 specs/amqp-8.0.xml create mode 100644 specs/amqp.0-8.xml create mode 100644 specs/amqp.0-9.xml create mode 100644 specs/cluster.0-8.xml create mode 100644 specs/cluster.0-9.xml diff --git a/cpp/gen/Makefile.am b/cpp/gen/Makefile.am index b0a324978a..e8edb35c6f 100644 --- a/cpp/gen/Makefile.am +++ b/cpp/gen/Makefile.am @@ -16,7 +16,7 @@ if CAN_GENERATE_CODE gentools_dir = $(srcdir)/../../gentools spec_dir = $(srcdir)/../../specs -spec = $(spec_dir)/amqp-8.0.xml +spec = $(spec_dir)/amqp.0-8.xml gentools_srcdir = $(gentools_dir)/src/org/apache/qpid/gentools $(BUILT_SOURCES) timestamp: $(spec) $(java_sources) $(cxx_templates) diff --git a/java/common/pom.xml b/java/common/pom.xml index 053fb5fafb..f30d81f739 100644 --- a/java/common/pom.xml +++ b/java/common/pom.xml @@ -57,8 +57,7 @@ - - + ${generated.path} diff --git a/java/common/protocol-version.xml b/java/common/protocol-version.xml index 6a92dfbe2b..ff5e8b0f70 100644 --- a/java/common/protocol-version.xml +++ b/java/common/protocol-version.xml @@ -20,14 +20,6 @@ --> - - diff --git a/java/common/src/main/versions/ProtocolVersionList.java.tmpl b/java/common/src/main/versions/ProtocolVersionList.java.tmpl deleted file mode 100644 index f0e202dac9..0000000000 --- a/java/common/src/main/versions/ProtocolVersionList.java.tmpl +++ /dev/null @@ -1,40 +0,0 @@ -/** - * - * Licensed to the Apache Software Foundation (ASF) under one - * or more contributor license agreements. See the NOTICE file - * distributed with this work for additional information - * regarding copyright ownership. The ASF licenses this file - * to you under the Apache License, Version 2.0 (the - * "License"); you may not use this file except in compliance - * with the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. - * - */ - -/** - * This class is autogenerated, do not modify. - */ - -package org.apache.qpid.framing; - -/** - * NOTE: Don't remove the line containing the token VER or VER1 - these are - * markers for code generation. - */ - -public interface ProtocolVersionList -{ - public final int PROTOCOL_MAJOR = 0; - public final int PROTOCOL_MINOR = 1; - public final byte pv[][] = { - // !VER1! - }; -} diff --git a/java/common/src/main/xsl/cluster.asl b/java/common/src/main/xsl/cluster.asl deleted file mode 100644 index 09e8ca0787..0000000000 --- a/java/common/src/main/xsl/cluster.asl +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - - - - An extension that allows brokers to communicate in order to - provide a clustered service to clients. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/framing.xsl b/java/common/src/main/xsl/framing.xsl deleted file mode 100644 index b8ae20aaf5..0000000000 --- a/java/common/src/main/xsl/framing.xsl +++ /dev/null @@ -1,64 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/java.xsl b/java/common/src/main/xsl/java.xsl deleted file mode 100644 index 948415fc18..0000000000 --- a/java/common/src/main/xsl/java.xsl +++ /dev/null @@ -1,248 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - wrote - - - - - - - - - - - - -package org.apache.qpid.framing; - -import org.apache.mina.common.ByteBuffer; -import org.apache.qpid.framing.AMQFrame; -import org.apache.qpid.framing.AMQFrameDecodingException; -import org.apache.qpid.framing.AMQMethodBody; -import org.apache.qpid.framing.EncodableAMQDataBlock; - -/** - * This class is autogenerated, do not modify. [From ] - */ -public class extends AMQMethodBody implements EncodableAMQDataBlock -{ - public static final int CLASS_ID = ; - public static final int METHOD_ID = ; - - - public - - ; - - - protected int getClazz() - { - return ; - } - - protected int getMethod() - { - return ; - } - - protected int getBodySize() - { - - - return - - + - - - - ; - - return 0; - - } - - protected void writeMethodPayload(ByteBuffer buffer) - { - - - ; - - - EncodingUtils.writeBooleans(buffer, new boolean[]{ - }); - - - } - - public void populateMethodBodyFromBuffer(ByteBuffer buffer) throws AMQFrameDecodingException - { - - ; - - } - - public String toString() - { - StringBuffer buf = new StringBuffer(super.toString()); - - buf.append(" : ").append(); - - return buf.toString(); - } - - public static AMQFrame createAMQFrame(int channelId, ) - { - body = new (); - - ; - - AMQFrame frame = new AMQFrame(); - frame.channel = channelId; - frame.bodyFrame = body; - return frame; - } -} - - - - Matching root for registry mode! - - - - - -Wrote MethodBodyDecoderRegistry.java - - - -package org.apache.qpid.framing; - -import java.util.Map; -import java.util.HashMap; -import org.apache.log4j.Logger; -import org.apache.qpid.AMQException; -import org.apache.qpid.framing.AMQFrameDecodingException; -import org.apache.qpid.framing.AMQMethodBody; - -/** - * This class is autogenerated, do not modify. - */ -public final class MethodBodyDecoderRegistry -{ - private static final Logger _log = Logger.getLogger(MethodBodyDecoderRegistry.class); - - private static final Map _classMethodProductToMethodBodyMap = new HashMap(); - - static - { - - ; - - } - - public static AMQMethodBody get(int clazz, int method) throws AMQFrameDecodingException - { - Class bodyClass = (Class) _classMethodProductToMethodBodyMap.get(new Integer(clazz * 1000 + method)); - if (bodyClass != null) - { - try - { - return (AMQMethodBody) bodyClass.newInstance(); - } - catch (Exception e) - { - throw new AMQFrameDecodingException(_log, - "Unable to instantiate body class for class " + clazz + " and method " + method + ": " + e, e); - } - } - else - { - throw new AMQFrameDecodingException(_log, - "Unable to find a suitable decoder for class " + clazz + " and method " + method); - } - } -} - - - - - - - - wrote - - - -package org.apache.qpid.framing; - -import java.util.Map; - -/** - * This class is autogenerated, do not modify. [From ] - */ -class -{ - static void register(Map map) - { - - map.put(new Integer( - - * 1000 + - - ), - ); - - } -} - - - - - - diff --git a/java/common/src/main/xsl/prepare1.xsl b/java/common/src/main/xsl/prepare1.xsl deleted file mode 100644 index 03e1fa7634..0000000000 --- a/java/common/src/main/xsl/prepare1.xsl +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - - - - - - - - - - - - - - - ( - major= - , minor= - ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Could not inherit from ; file not found. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/prepare2.xsl b/java/common/src/main/xsl/prepare2.xsl deleted file mode 100644 index 14f4f33841..0000000000 --- a/java/common/src/main/xsl/prepare2.xsl +++ /dev/null @@ -1,69 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/prepare3.xsl b/java/common/src/main/xsl/prepare3.xsl deleted file mode 100644 index f8cf0c8932..0000000000 --- a/java/common/src/main/xsl/prepare3.xsl +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - true - - - - - - - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/readme.txt b/java/common/src/main/xsl/readme.txt deleted file mode 100644 index b373055df9..0000000000 --- a/java/common/src/main/xsl/readme.txt +++ /dev/null @@ -1,52 +0,0 @@ -This directory contains the xsl stylesheets used to generate the code from the -AMQP protocol specification. They require an XSLT2.0 processor, currently -Saxon 8 is used. - -The generation process is controlled by the framing.xsl stylesheet. This performs -several phases of transformation, using the other stylesheets. The transformation -in each phase is defined in a separate file, and these are designed to also allow -then to be run individually. - -The generation takes the amq.asl as input, it also requires that the path to the -directory where the base asl definitions reside (those definitions that the main -amq.asl defintion inherits from) be passed in via a paramter called asl_base. - -The files involved are as follows: - - framing.xsl The control file for the entire generation process - - prepare1.xsl Resolves the separate files that make up the protocol - definition, building a single tree containing all the - information as a set of 'frame' elements, each of which - has attributes for its name, and ids for the class and - method it refers to and contains zero or more field - elements. - - A method id is generated based on the order of the - method elements within the class elements in the original - specification. The class id is taken from the enclosing - class element. - - prepare2.xsl Resolves domains into their corresponding types. (This is - much easier when all the information is in a single tree, - hence the separate frame). - - prepare3.xsl Converts names into valid java names and augments the - tree to include information that makes the subsequent - generation phase simpler e.g. the index of boolean - fields as several boolean flags are combined into a - single byte. (This is easier once the domains have been - resolved, hence the separate phase). - - java.xsl Generates java classes for each frame, and a registry of - all the frames to a 'magic' number generated from their - class and method id. - - utils.xsl Contains some utility methods for e.g. producing valid - java names. - -For debugging the framing.xsl can output the intermediary files. This can be -enabled by uncommenting the relevant lines (a comment explaining this is -provided inline). - - \ No newline at end of file diff --git a/java/common/src/main/xsl/registry.template b/java/common/src/main/xsl/registry.template deleted file mode 100644 index 87c5afcb7b..0000000000 --- a/java/common/src/main/xsl/registry.template +++ /dev/null @@ -1,25 +0,0 @@ - - - - - - diff --git a/java/common/src/main/xsl/registry.xsl b/java/common/src/main/xsl/registry.xsl deleted file mode 100644 index c70dbe21a5..0000000000 --- a/java/common/src/main/xsl/registry.xsl +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - - - - - - - - diff --git a/java/common/src/main/xsl/utils.xsl b/java/common/src/main/xsl/utils.xsl deleted file mode 100644 index 95e15c6e38..0000000000 --- a/java/common/src/main/xsl/utils.xsl +++ /dev/null @@ -1,207 +0,0 @@ - - - - - - - -/** -* -* Licensed to the Apache Software Foundation (ASF) under one -* or more contributor license agreements. See the NOTICE file -* distributed with this work for additional information -* regarding copyright ownership. The ASF licenses this file -* to you under the Apache License, Version 2.0 (the -* "License"); you may not use this file except in compliance -* with the License. You may obtain a copy of the License at -* -* http://www.apache.org/licenses/LICENSE-2.0 -* -* Unless required by applicable law or agreed to in writing, -* software distributed under the License is distributed on an -* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY -* KIND, either express or implied. See the License for the -* specific language governing permissions and limitations -* under the License. -* -*/ - - - - - - - char - short - int - String - byte[] - boolean - long - long - FieldTable - Object /*WARNING: undefined type*/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* WARNING: COULD NOT DETERMINE FIELD SIZE */ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* WARNING: COULD NOT DETERMINE ENCODER */ - - - - - - - - - - boolean[] bools = EncodingUtils.readBooleans(buffer); - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* WARNING: COULD NOT DETERMINE DECODER */ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/python/amqp-doc b/python/amqp-doc index 60a12c2838..0e7f9e862a 100755 --- a/python/amqp-doc +++ b/python/amqp-doc @@ -42,7 +42,7 @@ except GetoptError, e: die(str(e)) regexp = False -spec = "../specs/amqp-8.0.xml" +spec = "../specs/amqp.0-8.xml" for k, v in opts: if k == "-e" or k == "--regexp": regexp = True if k == "-s" or k == "--spec": spec = v diff --git a/python/qpid/testlib.py b/python/qpid/testlib.py index d35c38e4ad..39bad75b86 100644 --- a/python/qpid/testlib.py +++ b/python/qpid/testlib.py @@ -80,7 +80,7 @@ Options: def __init__(self): # Defaults self.setBroker("localhost") - self.spec = "../specs/amqp-8.0.xml" + self.spec = "../specs/amqp.0-8.xml" self.verbose = 1 self.ignore = [] diff --git a/specs/amqp-8.0.xml b/specs/amqp-8.0.xml deleted file mode 100644 index b84751c398..0000000000 --- a/specs/amqp-8.0.xml +++ /dev/null @@ -1,3987 +0,0 @@ - - - - - - - - AMQ Protocol 0.80 - - - - - - - - - - - - - - Indicates that the method completed successfully. This reply code is - reserved for future use - the current protocol design does not use - positive confirmation and reply codes are sent only in case of an - error. - - - The client asked for a specific message that is no longer available. - The message was delivered to another client, or was purged from the - queue for some other reason. - - - The client attempted to transfer content larger than the server - could accept at the present time. The client may retry at a later - time. - - - 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 or cluster. - - - The client attempted to work with a server entity to which it has - no 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 sent a malformed frame that the server could not decode. - This strongly implies a programming error in the client. - - - The client sent a frame that contained illegal values for one or more - fields. This strongly implies a programming error in the client. - - - The client sent an invalid sequence of frames, attempting to perform - an operation that was considered invalid by the server. This usually - implies a programming error in the client. - - - The client attempted to work with a channel that had not been - correctly opened. This most likely indicates a fault in the client - layer. - - - The server could not complete the method because it lacked sufficient - resources. This may be due to the client creating too many of some - type of entity. - - - The client tried to work with some entity in a manner that is - prohibited by the server, due to security settings or by some other - criteria. - - - The client tried to use functionality that is not implemented in the - server. - - - The server could not complete the method because of an internal error. - The server may require intervention by an operator in order to resume - normal operations. - - - - access ticket granted by server - - An access ticket granted by the server for a certain set of access - rights within a specific realm. Access tickets are valid within the - channel where they were created, and expire when the channel closes. - - - - - - consumer tag - - Identifier for the consumer, valid within the current connection. - - - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in - one channel and then use it in another. - - - - server-assigned delivery tag - - The server-assigned and channel-specific delivery tag - - - The delivery tag is valid only within the channel from which the - message was received. I.e. a client MUST NOT receive a message on - one channel and then acknowledge it on another. - - - The server MUST NOT use a zero value for delivery tags. Zero is - reserved for client use, meaning "all messages so far received". - - - - exchange name - - The exchange name is a client-selected string that identifies - the exchange for publish methods. Exchange names may consist - of any mixture of digits, letters, and underscores. Exchange - names are scoped by the virtual host. - - - - -list of known hosts - -Specifies the list of equivalent or alternative hosts that the server -knows about, which will normally include the current server itself. -Clients can cache this information and use it when reconnecting to a -server after a failure. - - -The server MAY leave this field empty if it knows of no other -hosts than itself. - - - - - no acknowledgement needed - - If this field is set the server does not expect acknowledgments - 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. - - - - do not deliver own messages - - If the no-local field is set the server will not send messages to - the client that published them. - - - - - Must start with a slash "/" and continue with path names - separated by slashes. A path name consists of any combination - of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. - - - - - - - -This string provides a set of peer properties, used for -identification, debugging, and general information. - - -The properties SHOULD contain these fields: -"product", giving the name of the peer product, "version", giving -the name of the peer version, "platform", giving the name of the -operating system, "copyright", if appropriate, and "information", -giving other general information. - - - - queue name - - The queue name identifies the queue within the vhost. Queue - names may consist of any mixture of digits, letters, and - underscores. - - - - - message is being redelivered - - This indicates that the message has been previously delivered to - this or another client. - - - The server SHOULD try to signal redelivered messages when it can. - When redelivering a message that was not successfully acknowledged, - the server SHOULD deliver it to the original client if possible. - - - The client MUST NOT rely on the redelivered field but MUST take it - as a hint that the message may already have been processed. A - fully robust client must be able to track duplicate received messages - on non-transacted, and locally-transacted channels. - - - -reply code from server - - The reply code. The AMQ reply codes are defined in AMQ RFC 011. - - - - -localised reply text - - The localised reply text. This text can be logged as an aid to - resolving issues. - - - - - - work with socket connections - - The connection class provides methods for a client to establish a - network connection to a server, and for both peers to operate the - connection thereafter. - - - connection = open-connection *use-connection close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - - - - - - start connection negotiation - - This method starts the connection negotiation process by telling - the client the protocol version that the server proposes, along - with a list of security mechanisms which the client can use for - authentication. - - - If the client cannot handle the protocol version suggested by the - server it MUST close the socket connection. - - - The server MUST provide a protocol version that is lower than or - equal to that requested by the client in the protocol header. If - the server cannot support the specified protocol it MUST NOT send - this method, but MUST close the socket connection. - - - - - protocol major version - - The protocol major version that the server agrees to use, which - cannot be higher than the client's major version. - - - - protocol major version - - The protocol minor version that the server agrees to use, which - cannot be higher than the client's minor version. - - - - server properties - - - available security mechanisms - - A list of the security mechanisms that the server supports, delimited - by spaces. Currently ASL supports these mechanisms: PLAIN. - - - - - - available message locales - - A list of the message locales that the server supports, delimited - by spaces. The locale defines the language in which the server - will send reply texts. - - - All servers MUST support at least the en_US locale. - - - - - - select security mechanism and locale - - This method selects a SASL security mechanism. ASL uses SASL - (RFC2222) to negotiate authentication and encryption. - - - - client properties - - - selected security mechanism - - 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. - - - The mechanism field MUST contain one of the security mechanisms - proposed by the server in the Start method. If it doesn't, the - server MUST close the socket. - - - - - security response data - - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. For the - PLAIN security mechanism this is defined as a field table holding - two fields, LOGIN and PASSWORD. - - - - - selected message locale - - A single message local selected by the client, which must be one - of those specified by the server. - - - - - - - security mechanism challenge - - The SASL protocol works by exchanging challenges and responses until - both peers have received sufficient information to authenticate each - other. This method challenges the client to provide more information. - - - - - security challenge data - - Challenge information, a block of opaque binary data passed to - the security mechanism. - - - - - - security mechanism response - - This method attempts to authenticate, passing a block of SASL data - for the security mechanism at the server side. - - - - security response data - - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. - - - - - - - propose connection tuning parameters - - This method proposes a set of connection configuration values - to the client. The client can accept and/or adjust these. - - - - - proposed maximum channels - - The maximum total number of channels that the server allows - per connection. Zero means that the server does not impose a - fixed limit, but the number of allowed channels may be limited - by available server resources. - - - - proposed maximum frame size - - The largest frame size that the server proposes for the - connection. The client can negotiate a lower value. Zero means - that the server does not impose any specific limit but may reject - very large frames if it cannot allocate resources for them. - - - Until the frame-max has been negotiated, both peers MUST accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - - - - desired heartbeat delay - - The delay, in seconds, of the connection heartbeat that the server - wants. Zero means the server does not want a heartbeat. - - - - - negotiate connection tuning parameters - - This method sends the client's connection tuning parameters to the - server. Certain fields are negotiated, others provide capability - information. - - - - negotiated maximum channels - - The maximum total number of channels that the client will use - per connection. May not be higher than the value specified by - the server. - - - The server MAY ignore the channel-max value or MAY use it for - tuning its resource allocation. - - - - - - negotiated maximum frame size - - The largest frame size that the client and server will use for - the connection. Zero means that the client does not impose any - specific limit but may reject very large frames if it cannot - allocate resources for them. Note that the frame-max limit - applies principally to content frames, where large contents - can be broken into frames of arbitrary size. - - - Until the frame-max has been negotiated, both peers must accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - - - - desired heartbeat delay - - The delay, in seconds, of the connection heartbeat that the client - wants. Zero means the client does not want a heartbeat. - - - - - - open connection to virtual host - - This method opens a connection to a virtual host, which is a - collection of resources, and acts to separate multiple application - domains within a server. - - - The client MUST open the context before doing any work on the - connection. - - - - - - virtual host name - - - 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 server MAY configure arbitrary limits per virtual host, such - as the number of each type of entity that may be used, per - connection and/or in total. - - - - required capabilities - - The client may specify a number of capability names, delimited by - spaces. The server can use this string to how to process the - client's connection request. - - - - insist on connecting to server - - In a configuration with multiple load-sharing servers, the server - may respond to a Connection.Open method with a Connection.Redirect. - The insist option tells the server that the client is insisting on - a connection to the specified server. - - - When the client uses the insist option, the server SHOULD accept - the client connection unless it is technically unable to do so. - - - - - signal that the connection is ready - - This method signals to the client that the connection is ready for - use. - - - - - - asks the client to use a different server - - This method redirects the client to another server, based on the - requested virtual host and/or capabilities. - - - When getting the Connection.Redirect method, the client SHOULD - reconnect to the host specified, and if that host is not present, - to any of the hosts specified in the known-hosts list. - - - - server to connect to - - Specifies the server to connect to. This is an IP address or a - DNS name, optionally followed by a colon and a port number. If - no port number is specified, the client should use the default - port number for the protocol. - - - - - - - - request a connection close - - This method indicates that the sender wants to close the connection. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - - - After sending this method any received method except the Close-OK - method MUST be discarded. - - - The peer sending this method MAY use a counter or timeout to - detect failure of the other peer to respond correctly with - the Close-OK method. - - - When a server receives the Close method from a client it MUST - delete all server-side resources associated with the client's - context. A client CANNOT reconnect to a context after sending - or receiving a Close method. - - - - - - - - failing method class - - When the close is provoked by a method exception, this is the - class of the method. - - - - failing method ID - - When the close is provoked by a method exception, this is the - ID of the method. - - - - - confirm a connection close - - This method confirms a Connection.Close method and tells the - recipient that it is safe to release resources for the connection - and close the socket. - - - A peer that detects a socket closure without having received a - Close-Ok handshake method SHOULD log the error. - - - - - - - - work with channels - - The channel class provides methods for a client to establish a virtual - connection - a channel - to a server and for both peers to operate the - virtual connection thereafter. - - - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:ALERT - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - - - - - - open a channel for use - - This method opens a virtual connection (a channel). - - - This method MUST NOT be called when the channel is already open. - - - - - out-of-band settings - - Configures out-of-band transfers on this channel. The syntax and - meaning of this field will be formally defined at a later date. - - - - - - signal that the channel is ready - - This method signals to the client that the channel is ready for use. - - - - - - enable/disable flow from peer - - This method asks the peer to pause or restart the flow of content - data. This is a simple flow-control mechanism that a peer can use - to avoid oveflowing its queues or otherwise finding itself receiving - more messages than it can process. Note that this method is not - intended for window control. The peer that receives a request to - stop sending content should finish sending the current content, if - any, and then wait until it receives a Flow restart method. - - - When a new channel is opened, it is active. Some applications - assume that channels are inactive until started. To emulate this - behaviour a client MAY open the channel, then pause it. - - - When sending content data in multiple frames, a peer SHOULD monitor - the channel for incoming methods and respond to a Channel.Flow as - rapidly as possible. - - - A peer MAY use the Channel.Flow method to throttle incoming content - data for internal reasons, for example, when exchangeing data over a - slower connection. - - - The peer that requests a Channel.Flow method MAY disconnect and/or - ban a peer that does not respect the request. - - - - - - start/stop content frames - - If 1, the peer starts sending content frames. If 0, the peer - stops sending content frames. - - - - - confirm a flow method - - Confirms to the peer that a flow command was received and processed. - - - - - current flow setting - - Confirms the setting of the processed flow method: 1 means the - peer will start sending or continue to send content frames; 0 - means it will not. - - - - - - send a non-fatal warning message - - This method allows the server to send a non-fatal warning to the - client. This is used for methods that are normally asynchronous - and thus do not have confirmations, and for which the server may - detect errors that need to be reported. Fatal errors are handled - as channel or connection exceptions; non-fatal errors are sent - through this method. - - - - - - detailed information for warning - - A set of fields that provide more information about the - problem. The meaning of these fields are defined on a - per-reply-code basis (TO BE DEFINED). - - - - - - request a channel close - - This method indicates that the sender wants to close the channel. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - - - After sending this method any received method except - Channel.Close-OK MUST be discarded. - - - The peer sending this method MAY use a counter or timeout to detect - failure of the other peer to respond correctly with Channel.Close-OK.. - - - - - - - - failing method class - - When the close is provoked by a method exception, this is the - class of the method. - - - - failing method ID - - When the close is provoked by a method exception, this is the - ID of the method. - - - - - confirm a channel close - - This method confirms a Channel.Close method and tells the recipient - that it is safe to release resources for the channel and close the - socket. - - - A peer that detects a socket closure without having received a - Channel.Close-Ok handshake method SHOULD log the error. - - - - - - - - work with access tickets - - The protocol control access to server resources using access tickets. - A client must explicitly request access tickets before doing work. - An access ticket grants a client the right to use a specific set of - resources - called a "realm" - in specific ways. - - - access = C:REQUEST S:REQUEST-OK - - - - - - request an access ticket - - This method requests an access ticket for an access realm. - The server responds by granting the access ticket. If the - client does not have access rights to the requested realm - this causes a connection exception. Access tickets are a - per-channel resource. - - - The realm name MUST start with either "/data" (for application - resources) or "/admin" (for server administration resources). - If the realm starts with any other path, the server MUST raise - a connection exception with reply code 403 (access refused). - - - The server MUST implement the /data realm and MAY implement the - /admin realm. The mapping of resources to realms is not - defined in the protocol - this is a server-side configuration - issue. - - - - - name of requested realm - - If the specified realm is not known to the server, the server - must raise a channel exception with reply code 402 (invalid - path). - - - - request exclusive access - - Request exclusive access to the realm. If the server cannot grant - this - because there are other active tickets for the realm - it - raises a channel exception. - - - - request passive access - - Request message passive access to the specified access realm. - Passive access lets a client get information about resources in - the realm but not to make any changes to them. - - - - request active access - - Request message active access to the specified access realm. - Acvtive access lets a client get create and delete resources in - the realm. - - - - request write access - - Request write access to the specified access realm. Write access - lets a client publish messages to all exchanges in the realm. - - - - request read access - - Request read access to the specified access realm. Read access - lets a client consume messages from queues in the realm. - - - - - grant access to server resources - - This method provides the client with an access ticket. The access - ticket is valid within the current channel and for the lifespan of - the channel. - - - The client MUST NOT use access tickets except within the same - channel as originally granted. - - - The server MUST isolate access tickets per channel and treat an - attempt by a client to mix these as a connection exception. - - - - - - - - work with exchanges - - Exchanges match and distribute messages across queues. Exchanges can be - configured in the server or created at runtime. - - - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK - - - - - amq_exchange_19 - The server MUST implement the direct and fanout exchange types, and - predeclare the corresponding exchanges named amq.direct and amq.fanout - in each virtual host. The server MUST also predeclare a direct - exchange to act as the default exchange for content Publish methods - and for default queue bindings. - - - amq_exchange_20 - The server SHOULD implement the topic exchange type, and predeclare - the corresponding exchange named amq.topic in each virtual host. - - - amq_exchange_21 - The server MAY implement the system exchange type, and predeclare the - corresponding exchanges named amq.system in each virtual host. If the - client attempts to bind a queue to the system exchange, the server - MUST raise a connection exception with reply code 507 (not allowed). - - - amq_exchange_22 - The default exchange MUST be defined as internal, and be inaccessible - to the client except by specifying an empty exchange name in a content - Publish method. That is, the server MUST NOT let clients make explicit - bindings to this exchange. - - - - declare exchange, create if needed - - This method creates an exchange if it does not already exist, and if the - exchange exists, verifies that it is of the correct and expected class. - - - amq_exchange_23 - The server SHOULD support a minimum of 16 exchanges per virtual host - and ideally, impose no limit except as defined by available resources. - - - - - - When a client defines a new exchange, this belongs to the access realm - of the ticket used. All further work done with that exchange must be - done with an access ticket for the same realm. - - - The client MUST provide a valid access ticket giving "active" access - to the realm in which the exchange exists or will be created, or - "passive" access if the if-exists flag is set. - - - - - amq_exchange_15 - Exchange names starting with "amq." are reserved for predeclared - and standardised exchanges. If the client attempts to create an - exchange starting with "amq.", the server MUST raise a channel - exception with reply code 403 (access refused). - - - - - exchange type - - 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. - - - amq_exchange_16 - If the exchange already exists with a different type, the server - MUST raise a connection exception with a reply code 507 (not allowed). - - - amq_exchange_18 - If the server does not support the requested exchange type it MUST - raise a connection exception with a reply code 503 (command invalid). - - - - - do not create exchange - - 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. - - - amq_exchange_05 - If set, and the exchange does not already exist, the server MUST - raise a channel exception with reply code 404 (not found). - - - - request a durable exchange - - 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. - - - amq_exchange_24 - The server MUST support both durable and transient exchanges. - - - The server MUST ignore the durable field if the exchange already - exists. - - - - auto-delete when unused - - If set, the exchange is deleted when all queues have finished - using it. - - - amq_exchange_02 - The server SHOULD allow for a reasonable delay between the point - when it determines that an exchange is not being used (or no longer - used), and the point when it deletes the exchange. At the least it - must allow a client to create an exchange and then bind a queue to - it, with a small but non-zero delay between these two actions. - - - amq_exchange_25 - The server MUST ignore the auto-delete field if the exchange already - exists. - - - - create internal exchange - - If set, the exchange may not be used directly by publishers, but - only when bound to other exchanges. Internal exchanges are used to - construct wiring that is not visible to applications. - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - arguments for declaration - - 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. - - - - - confirms an exchange declaration - - This method confirms a Declare method and confirms the name of the - exchange, essential for automatically-named exchanges. - - - - - - delete an exchange - - This method deletes an exchange. When an exchange is deleted all queue - bindings on the exchange are cancelled. - - - - - - The client MUST provide a valid access ticket giving "active" - access rights to the exchange's access realm. - - - - - amq_exchange_11 - The exchange MUST exist. Attempting to delete a non-existing exchange - causes a channel exception. - - - - - delete only if unused - - If set, the server will only delete the exchange if it has no queue - bindings. If the exchange has queue bindings the server does not - delete it but raises a channel exception instead. - - - amq_exchange_12 - If set, the server SHOULD delete the exchange but only if it has - no queue bindings. - - - amq_exchange_13 - If set, the server SHOULD raise a channel exception if the exchange is in - use. - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm deletion of an exchange - - This method confirms the deletion of an exchange. - - - - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - - - - - - - - - - - - work with queues - - - Queues store and forward messages. Queues can be configured in the server - or created at runtime. Queues must be attached to at least one exchange - in order to receive messages from publishers. - - - queue = C:DECLARE S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK - - - - - amq_queue_33 - A server MUST allow any content class to be sent to any queue, in any - mix, and queue and delivery these content classes independently. Note - that all methods that fetch content off queues are specific to a given - content class. - - - - declare queue, create if needed - - This method creates or checks a queue. When creating a new queue - the client can specify various properties that control the durability - of the queue and its contents, and the level of sharing for the queue. - - - amq_queue_34 - The server MUST create a default binding for a newly-created queue - to the default exchange, which is an exchange of type 'direct'. - - - amq_queue_35 - The server SHOULD support a minimum of 256 queues per virtual host - and ideally, impose no limit except as defined by available resources. - - - - - - When a client defines a new queue, this belongs to the access realm - of the ticket used. All further work done with that queue must be - done with an access ticket for the same realm. - - - The client provides a valid access ticket giving "active" access - to the realm in which the queue exists or will be created, or - "passive" access if the if-exists flag is set. - - - - - amq_queue_10 - The queue name MAY be empty, in which case the server MUST create - a new queue with a unique generated name and return this to the - client in the Declare-Ok method. - - - amq_queue_32 - Queue names starting with "amq." are reserved for predeclared and - standardised server queues. If the queue name starts with "amq." - and the passive option is zero, the server MUST raise a connection - exception with reply code 403 (access refused). - - - - - do not create queue - - If set, the server will not create the queue. The client can use - this to check whether a queue exists without modifying the server - state. - - - amq_queue_05 - If set, and the queue does not already exist, the server MUST - respond with a reply code 404 (not found) and raise a channel - exception. - - - - request a durable queue - - 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. - - - amq_queue_03 - The server MUST recreate the durable queue after a restart. - - - amq_queue_36 - The server MUST support both durable and transient queues. - - - amq_queue_37 - The server MUST ignore the durable field if the queue already - exists. - - - - request an exclusive queue - - Exclusive queues may only be consumed from by the current connection. - Setting the 'exclusive' flag always implies 'auto-delete'. - - - amq_queue_38 - The server MUST support both exclusive (private) and non-exclusive - (shared) queues. - - - amq_queue_04 - The server MUST raise a channel exception if 'exclusive' is specified - and the queue already exists and is owned by a different connection. - - - - auto-delete queue when unused - - If set, the queue is deleted when all consumers have finished - using it. Last consumer can be cancelled either explicitly or because - its channel is closed. If there was no consumer ever on the queue, it - won't be deleted. - - - amq_queue_02 - The server SHOULD allow for a reasonable delay between the point - when it determines that a queue is not being used (or no longer - used), and the point when it deletes the queue. At the least it - must allow a client to create a queue and then create a consumer - to read from it, with a small but non-zero delay between these - two actions. The server should equally allow for clients that may - be disconnected prematurely, and wish to re-consume from the same - queue without losing messages. We would recommend a configurable - timeout, with a suitable default value being one minute. - - - amq_queue_31 - The server MUST ignore the auto-delete field if the queue already - exists. - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - arguments for declaration - - 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. - - - - - confirms a queue definition - - This method confirms a Declare method and confirms the name of the - queue, essential for automatically-named queues. - - - - - Reports the name of the queue. If the server generated a queue - name, this field contains that name. - - - - - number of messages in queue - - Reports the number of messages in the queue, which will be zero - for newly-created queues. - - - - number of consumers - - Reports the number of active consumers for the queue. Note that - consumers can suspend activity (Channel.Flow) in which case they - do not appear in this count. - - - - - - bind queue to an exchange - - This method binds a queue to an exchange. Until a queue is - bound it will not receive any messages. In a classic messaging - model, store-and-forward queues are bound to a dest exchange - and subscription queues are bound to a dest_wild exchange. - - - amq_queue_25 - A server MUST allow ignore duplicate bindings - that is, two or - more bind methods for a specific queue, with identical arguments - - without treating these as an error. - - - amq_queue_39 - If a bind fails, the server MUST raise a connection exception. - - - amq_queue_12 - The server MUST NOT allow a durable queue to bind to a transient - exchange. If the client attempts this the server MUST raise a - channel exception. - - - amq_queue_13 - Bindings for durable queues are automatically durable and the - server SHOULD restore such bindings after a server restart. - - - amq_queue_17 - If the client attempts to an exchange that was declared as internal, - the server MUST raise a connection exception with reply code 530 - (not allowed). - - - amq_queue_40 - The server SHOULD support at least 4 bindings per queue, and - ideally, impose no limit except as defined by available resources. - - - - - - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - - - - - - Specifies the name of the queue to bind. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - - - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - - - If the queue does not exist the server MUST raise a channel exception - with reply code 404 (not found). - - - - - The name of the exchange to bind to. - - amq_queue_14 - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - - - - message routing key - - Specifies the routing key for the binding. The routing key is - used for routing messages depending on the exchange configuration. - Not all exchanges use a routing key - refer to the specific - exchange documentation. If the routing key is empty and the queue - name is empty, the routing key will be the current queue for the - channel, which is the last declared queue. - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - arguments for binding - - A set of arguments for the binding. The syntax and semantics of - these arguments depends on the exchange class. - - - - - confirm bind successful - - This method confirms that the bind was successful. - - - - - - purge a queue - - This method removes all messages from a queue. It does not cancel - consumers. Purged messages are deleted without any formal "undo" - mechanism. - - - amq_queue_15 - A call to purge MUST result in an empty queue. - - - amq_queue_41 - On transacted channels the server MUST not purge messages that have - already been sent to a client but not yet acknowledged. - - - amq_queue_42 - The server MAY implement a purge queue or log that allows system - administrators to recover accidentally-purged messages. The server - SHOULD NOT keep purged messages in the same storage spaces as the - live messages since the volumes of purged messages may get very - large. - - - - - - The access ticket must be for the access realm that holds the - queue. - - - The client MUST provide a valid access ticket giving "read" access - rights to the queue's access realm. Note that purging a queue is - equivalent to reading all messages and discarding them. - - - - - Specifies the name of the queue to purge. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - - - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - - - The queue must exist. Attempting to purge a non-existing queue - causes a channel exception. - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - confirms a queue purge - - This method confirms the purge of a queue. - - - - number of messages purged - - Reports the number of messages purged. - - - - - - delete a queue - - This method deletes a queue. When a queue is deleted any pending - messages are sent to a dead-letter queue if this is defined in the - server configuration, and all consumers on the queue are cancelled. - - - amq_queue_43 - The server SHOULD use a dead-letter queue to hold messages that - were pending on a deleted queue, and MAY provide facilities for - a system administrator to move these messages back to an active - queue. - - - - - - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - - - - - - Specifies the name of the queue to delete. If the queue name is - empty, refers to the current queue for the channel, which is the - last declared queue. - - - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - - - The queue must exist. Attempting to delete a non-existing queue - causes a channel exception. - - - - - delete only if unused - - If set, the server will only delete the queue if it has no - consumers. If the queue has consumers the server does does not - delete it but raises a channel exception instead. - - - amq_queue_29 - amq_queue_30 - The server MUST respect the if-unused flag when deleting a queue. - - - - delete only if empty - amq_queue_27 - - If set, the server will only delete the queue if it has no - messages. If the queue is not empty the server raises a channel - exception. - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm deletion of a queue - - This method confirms the deletion of a queue. - - - - number of messages purged - - Reports the number of messages purged. - - - - - - - work with basic content - - The Basic class provides methods that support an industry-standard - messaging model. - - - - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT - - - - - - - The server SHOULD respect the persistent property of basic messages - and SHOULD make a best-effort to hold persistent basic messages on a - reliable storage mechanism. - - - The server MUST NOT discard a persistent basic message in case of a - queue overflow. The server MAY use the Channel.Flow method to slow - or stop a basic message publisher when necessary. - - - The server MAY overflow non-persistent basic messages to persistent - storage and MAY discard or dead-letter non-persistent basic messages - on a priority basis if the queue size exceeds some configured limit. - - - The server MUST implement at least 2 priority levels for basic - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. - - - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. - - - The server MUST support both automatic and explicit acknowledgements - on Basic content. - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - Non-persistent (1) or persistent (2) - - - The message priority, 0 to 9 - - - The application correlation identifier - - - The destination to reply to - - - Message expiration specification - - - The application message identifier - - - The message timestamp - - - The message type name - - - The creating user id - - - The creating application id - - - Intra-cluster routing identifier - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - - - - - - prefetch window in octets - - 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 - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. The - server will send a message in advance if it is equal to or - smaller in size than the available prefetch size (and also falls - into other prefetch limits). May be set to zero, meaning "no - specific limit", although other prefetch limits may still apply. - The prefetch-size is ignored if the no-ack option is set. - - - The server MUST ignore this setting when the client is not - processing any messages - i.e. the prefetch size does not limit - the transfer of single messages to a client, only the sending in - advance of more messages while the client still has one or more - unacknowledged messages. - - - - - prefetch window in messages - - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - - - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - - - - - - - - start a queue consumer - - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - - - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - - - - - - - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - - - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - - - - - - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - - - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - - - - - - - - - request exclusive access - - Request exclusive consumer access, meaning only this consumer can - access the queue. - - - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 403 (access refused). - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - A set of arguments for the consume. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - - - - - - confirm a new consumer - - The server provides the client with a consumer tag, which is used - by the client for methods called on the consumer at a later stage. - - - - - - Holds the consumer tag specified by the client or provided by - the server. - - - - - - - - - end a queue consumer - - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. The client may receive an - abitrary number of messages in between sending the cancel method - and receiving the cancel-ok reply. - - - If the queue no longer exists when the client sends a cancel command, - or the consumer has been cancelled for other reasons, this command - has no effect. - - - - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - publish a message - - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers when the transaction, if any, - is committed. - - - - - - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - - - - - - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - - - The server MUST accept a blank exchange name to mean the default - exchange. - - - If the exchange was declared as an internal exchange, the server - MUST raise a channel exception with a reply code 403 (access - refused). - - - The exchange MAY refuse basic content in which case it MUST raise - a channel exception with reply code 540 (not implemented). - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - - - The server SHOULD implement the mandatory flag. - - - - - request immediate delivery - - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - - - The server SHOULD implement the immediate flag. - - - - - - return a failed message - - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - - - - - - - - - Specifies the name of the exchange that the message was - originally published to. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - - - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - - - - - - - - - - - - Specifies the name of the exchange that the message was - originally published to. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - direct access to a queue - - This method provides a direct access to the messages in a queue - using a synchronous dialogue that is designed for specific types of - application where synchronous functionality is more important than - performance. - - - - - - - - The client MUST provide a valid access ticket giving "read" - access rights to the realm for the queue. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - - - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - - - - - - - - provide client with a message - - This method delivers a message to the client following a get - method. A message delivered by 'get-ok' must be acknowledged - unless the no-ack option was set in the get method. - - - - - - - - - - Specifies the name of the exchange that the message was originally - published to. If empty, the message was published to the default - exchange. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - number of messages pending - - This field reports the number of messages pending on the queue, - excluding the message being delivered. Note that this figure is - indicative, not reliable, and can change arbitrarily as messages - are added to the queue and removed by other clients. - - - - - - - indicate no messages available - - This method tells the client that the queue has no messages - available for the client. - - - - - Cluster id - - For use by cluster applications, should not be used by - client applications. - - - - - - - - acknowledge one or more messages - - This method acknowledges one or more messages delivered via the - Deliver or Get-Ok methods. The client can ask to confirm a - single message or a set of messages up to and including a specific - message. - - - - - - acknowledge multiple messages - - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - - - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - - - - - - - - reject an incoming message - - This method allows a client to reject a message. It can be used to - interrupt and cancel large incoming messages, or return untreatable - messages to their original queue. - - - The server SHOULD be capable of accepting and process the Reject - method while sending message content with a Deliver or Get-Ok - method. I.e. the server should read and process incoming methods - while sending output frames. To cancel a partially-send content, - the server sends a content body frame of size 1 (i.e. with no data - except the frame-end octet). - - - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - - - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - - - - - - - requeue the message - - 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 channel. 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. - - - - - - redeliver unacknowledged messages - - This method asks the broker to redeliver all unacknowledged messages on a - specified channel. Zero or more messages may be redelivered. This method - is only allowed on non-transacted channels. - - - - - requeue the message - - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the - message, potentially then delivering it to an alternative subscriber. - - - - The server MUST set the redelivered flag on all messages that are resent. - - - The server MUST raise a channel exception if this is called on a - transacted channel. - - - - - - - - - work with file content - - The file class provides methods that support reliable file transfer. - File messages have a specific set of properties that are required for - interoperability with file transfer applications. File messages and - acknowledgements are subject to channel transactions. Note that the - file class does not provide message browsing methods; these are not - compatible with the staging model. Applications that need browsable - file transfer should use Basic content and the Basic class. - - - - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - - - - - - - The server MUST make a best-effort to hold file messages on a - reliable storage mechanism. - - - The server MUST NOT discard a file message in case of a queue - overflow. The server MUST use the Channel.Flow method to slow or stop - a file message publisher when necessary. - - - The server MUST implement at least 2 priority levels for file - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. - - - The server MUST support both automatic and explicit acknowledgements - on file content. - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - The message priority, 0 to 9 - - - The destination to reply to - - - The application message identifier - - - The message filename - - - The message timestamp - - - Intra-cluster routing identifier - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - - - - - - prefetch window in octets - - 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 - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. The prefetch-size is ignored - if the no-ack option is set. - - - - - prefetch window in messages - - Specifies a prefetch window in terms of whole messages. This - is compatible with some file API implementations. This field - may be used in combination with the prefetch-size field; a - message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - - - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - - - - - - - - start a queue consumer - - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - - - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - - - - - - - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - - - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - - - - - - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - - - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - - - - - - - - - request exclusive access - - Request exclusive consumer access, meaning only this consumer can - access the queue. - - - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm a new consumer - - This method provides the client with a consumer tag which it MUST - use in methods that work with the consumer. - - - - - - Holds the consumer tag specified by the client or provided by - the server. - - - - - - - - - end a queue consumer - - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. - - - - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - request to start staging - - This method requests permission to start staging a message. Staging - means sending the message into a temporary area at the recipient end - and then delivering the message by referring to this temporary area. - Staging is how the protocol handles partial file transfers - if a - message is partially staged and the connection breaks, the next time - the sender starts to stage it, it can restart from where it left off. - - - - - - - staging identifier - - 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.). - - - - - message content size - - 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. - - - - - - confirm staging ready - - This method confirms that the recipient is ready to accept staged - data. If the message was already partially-staged at a previous - time the recipient will report the number of octets already staged. - - - - - - - already staged amount - - The amount of previously-staged content in octets. For a new - message this will be zero. - - - The sender MUST start sending data from this octet offset in the - message, counting from zero. - - - The recipient MAY decide how long to hold partially-staged content - and MAY implement staging by always discarding partially-staged - content. However if it uses the file content type it MUST support - the staging methods. - - - - - - - - stage message content - - This method stages the message, sending the message content to the - recipient from the octet offset specified in the Open-Ok method. - - - - - - - - - - publish a message - - This method publishes a staged file message to a specific exchange. - The file message will be routed to queues as defined by the exchange - configuration and distributed to any active consumers when the - transaction, if any, is committed. - - - - - - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - - - - - - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - - - The server MUST accept a blank exchange name to mean the default - exchange. - - - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - - - The exchange MAY refuse file content in which case it MUST respond - with a reply code 540 (not implemented) and raise a channel - exception. - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - - - The server SHOULD implement the mandatory flag. - - - - - request immediate delivery - - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - - - The server SHOULD implement the immediate flag. - - - - - staging identifier - - This is the staging identifier of the message to publish. The - message must have been staged. Note that a client can send the - Publish method asynchronously without waiting for staging to - finish. - - - - - - return a failed message - - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - - - - - - - - - Specifies the name of the exchange that the message was - originally published to. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - This method delivers a staged file message to the client, via a - consumer. In the asynchronous message delivery model, the client - starts a consumer using the Consume method, then the server - responds with Deliver methods as and when messages arrive for - that consumer. - - - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - - - - - - - - - - - - Specifies the name of the exchange that the message was originally - published to. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - staging identifier - - This is the staging identifier of the message to deliver. The - message must have been staged. Note that a server can send the - Deliver method asynchronously without waiting for staging to - finish. - - - - - - - - - acknowledge one or more messages - - This method acknowledges one or more messages delivered via the - Deliver method. The client can ask to confirm a single message or - a set of messages up to and including a specific message. - - - - - - acknowledge multiple messages - - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - - - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - - - - - - - - - reject an incoming message - - This method allows a client to reject a message. It can be used to - return untreatable messages to their original queue. Note that file - content is staged before delivery, so the client will not use this - method to interrupt delivery of a large message. - - - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - - - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - - - - - - - requeue the message - - 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 channel. 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. - - - - - - - - - work with streaming content - - - The stream class provides methods that support multimedia streaming. - The stream class uses the following semantics: one message is one - packet of data; delivery is unacknowleged and unreliable; the consumer - can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favour of high - priority messages. - - - - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - - - - - - - The server SHOULD discard stream messages on a priority basis if - the queue size exceeds some configured limit. - - - The server MUST implement at least 2 priority levels for stream - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. - - - The server MUST implement automatic acknowledgements on stream - content. That is, as soon as a message is delivered to a client - via a Deliver method, the server must remove it from the queue. - - - - - - - MIME content type - - - MIME content encoding - - - Message header field table - - - The message priority, 0 to 9 - - - The message timestamp - - - - - - - specify quality of service - - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - - - - - - prefetch window in octets - - 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 - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. - - - - - prefetch window in messages - - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - - - - - transfer rate in octets/second - - Specifies a desired transfer rate in octets per second. This is - usually determined by the application that uses the streaming - data. A value of zero means "no limit", i.e. as rapidly as - possible. - - - The server MAY ignore the prefetch values and consume rates, - depending on the type of stream and the ability of the server - to queue and/or reply it. The server MAY drop low-priority - messages in favour of high-priority messages. - - - - - apply to entire connection - - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - - - - - - confirm the requested qos - - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - - - - - - - - start a queue consumer - - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel 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 channels to select - different streaming resolutions. AMQP makes no provision for - filtering and/or transforming streams except on the basis of - priority-based selective delivery of individual messages. - - - - - - - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - - - - - - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - - - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - - - - - - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - - - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - - - - - - - request exclusive access - - Request exclusive consumer access, meaning only this consumer can - access the queue. - - - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - - confirm a new consumer - - This method provides the client with a consumer tag which it may - use in methods that work with the consumer. - - - - - - Holds the consumer tag specified by the client or provided by - the server. - - - - - - - - end a queue consumer - - This method cancels a consumer. Since message delivery is - asynchronous the client may continue to receive messages for - a short while after canceling a consumer. It may process or - discard these as appropriate. - - - - - - - - do not send a reply method - - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - - - - - - confirm a cancelled consumer - - This method confirms that the cancellation was completed. - - - - - - - - - - - publish a message - - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers as appropriate. - - - - - - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - - - - - - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - - - The server MUST accept a blank exchange name to mean the default - exchange. - - - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - - - The exchange MAY refuse stream content in which case it MUST - respond with a reply code 540 (not implemented) and raise a - channel exception. - - - - - Message routing key - - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - - - - - indicate mandatory routing - - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - - - The server SHOULD implement the mandatory flag. - - - - - request immediate delivery - - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - - - The server SHOULD implement the immediate flag. - - - - - - return a failed message - - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - - - - - - - - - Specifies the name of the exchange that the message was - originally published to. - - - - - Message routing key - - Specifies the routing key name specified when the message was - published. - - - - - - - - - notify the client of a consumer message - - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - - - - - - - - - - Specifies the name of the exchange that the message was originally - published to. - - - - - - Specifies the name of the queue that the message came from. Note - that a single channel can start many consumers on different - queues. - - - - - - - - - work with standard transactions - - - 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. - - - 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. - - - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK - - - - - -select standard transaction mode - - This method sets the channel to use standard transactions. The - client must use this method at least once on a channel before - using the Commit or Rollback methods. - - - - - -confirm transaction mode - - This method confirms to the client that the channel was successfully - set to use standard transactions. - - - - - -commit the current transaction - - This method commits all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a commit. - - - - - -confirm a successful commit - - This method confirms to the client that the commit succeeded. - Note that if a commit fails, the server raises a channel exception. - - - - - -abandon the current transaction - - This method abandons all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a rollback. - - - - - -confirm a successful rollback - - This method confirms to the client that the rollback succeeded. - Note that if an rollback fails, the server raises a channel exception. - - - - - - - work with distributed transactions - - - Distributed transactions provide so-called "2-phase commit". The - AMQP distributed transaction model supports the X-Open XA - architecture and other distributed transaction implementations. - The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. - - - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK - - - - - -select standard transaction mode - - This method sets the channel to use distributed transactions. The - client must use this method at least once on a channel before - using the Start method. - - - - - -confirm transaction mode - - This method confirms to the client that the channel was successfully - set to use distributed transactions. - - - - - - start a new distributed transaction - - This method starts a new distributed transaction. This must be - the first method on a new channel that uses the distributed - transaction mode, before any methods that publish or consume - messages. - - - - - transaction identifier - - The distributed transaction key. This identifies the transaction - so that the AMQP server can coordinate with the distributed - transaction coordinator. - - - - - - confirm the start of a new distributed transaction - - This method confirms to the client that the transaction started. - Note that if a start fails, the server raises a channel exception. - - - - - - - methods for protocol tunneling. - - - The tunnel methods are used to send blocks of binary data - which - can be serialised AMQP methods or other protocol frames - between - AMQP peers. - - - tunnel = C:REQUEST - / S:REQUEST - - - - - Message header field table - - - The identity of the tunnelling proxy - - - The name or type of the message being tunnelled - - - The message durability indicator - - - The message broadcast mode - - - - sends a tunnelled method - - This method tunnels a block of binary data, which can be an - encoded AMQP method or other data. The binary data is sent - as the content for the Tunnel.Request method. - - - - meta data for the tunnelled block - - This field table holds arbitrary meta-data that the sender needs - to pass to the recipient. - - - - - - - test functional primitives of the implementation - - - The test class provides methods for a peer to test the basic - operational correctness of another peer. The test methods are - intended to ensure that all peers respect at least the basic - elements of the protocol, such as frame and content organisation - and field types. We assume that a specially-designed peer, a - "monitor client" would perform such tests. - - - test = C:INTEGER S:INTEGER-OK - / S:INTEGER C:INTEGER-OK - / C:STRING S:STRING-OK - / S:STRING C:STRING-OK - / C:TABLE S:TABLE-OK - / S:TABLE C:TABLE-OK - / C:CONTENT S:CONTENT-OK - / S:CONTENT C:CONTENT-OK - - - - - - test integer handling - - This method tests the peer's capability to correctly marshal integer - data. - - - - - - octet test value - - An octet integer test value. - - - - short test value - - A short integer test value. - - - - long test value - - A long integer test value. - - - - long-long test value - - A long long integer test value. - - - - operation to test - - The client must execute this operation on the provided integer - test fields and return the result. - - - return sum of test values - return lowest of test values - return highest of test values - - - - - report integer test result - - This method reports the result of an Integer method. - - - - - result value - - The result of the tested operation. - - - - - - test string handling - - This method tests the peer's capability to correctly marshal string - data. - - - - - - short string test value - - An short string test value. - - - - long string test value - - A long string test value. - - - - operation to test - - The client must execute this operation on the provided string - test fields and return the result. - - - return concatentation of test strings - return shortest of test strings - return longest of test strings - - - - - report string test result - - This method reports the result of a String method. - - - - - result value - - The result of the tested operation. - - - - - - test field table handling - - This method tests the peer's capability to correctly marshal field - table data. - - - - - - field table of test values - - A field table of test values. - - - - operation to test on integers - - The client must execute this operation on the provided field - table integer values and return the result. - - - return sum of numeric field values - return min of numeric field values - return max of numeric field values - - - - operation to test on strings - - The client must execute this operation on the provided field - table string values and return the result. - - - return concatenation of string field values - return shortest of string field values - return longest of string field values - - - - - report table test result - - This method reports the result of a Table method. - - - - - integer result value - - The result of the tested integer operation. - - - - string result value - - The result of the tested string operation. - - - - - - test content handling - - This method tests the peer's capability to correctly marshal content. - - - - - - - report content test result - - This method reports the result of a Content method. It contains the - content checksum and echoes the original content as provided. - - - - - content hash - - The 32-bit checksum of the content, calculated by adding the - content into a 32-bit accumulator. - - - - - diff --git a/specs/amqp.0-8.xml b/specs/amqp.0-8.xml new file mode 100644 index 0000000000..b84751c398 --- /dev/null +++ b/specs/amqp.0-8.xml @@ -0,0 +1,3987 @@ + + + + + + + + AMQ Protocol 0.80 + + + + + + + + + + + + + + Indicates that the method completed successfully. This reply code is + reserved for future use - the current protocol design does not use + positive confirmation and reply codes are sent only in case of an + error. + + + The client asked for a specific message that is no longer available. + The message was delivered to another client, or was purged from the + queue for some other reason. + + + The client attempted to transfer content larger than the server + could accept at the present time. The client may retry at a later + time. + + + 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 or cluster. + + + The client attempted to work with a server entity to which it has + no 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 sent a malformed frame that the server could not decode. + This strongly implies a programming error in the client. + + + The client sent a frame that contained illegal values for one or more + fields. This strongly implies a programming error in the client. + + + The client sent an invalid sequence of frames, attempting to perform + an operation that was considered invalid by the server. This usually + implies a programming error in the client. + + + The client attempted to work with a channel that had not been + correctly opened. This most likely indicates a fault in the client + layer. + + + The server could not complete the method because it lacked sufficient + resources. This may be due to the client creating too many of some + type of entity. + + + The client tried to work with some entity in a manner that is + prohibited by the server, due to security settings or by some other + criteria. + + + The client tried to use functionality that is not implemented in the + server. + + + The server could not complete the method because of an internal error. + The server may require intervention by an operator in order to resume + normal operations. + + + + access ticket granted by server + + An access ticket granted by the server for a certain set of access + rights within a specific realm. Access tickets are valid within the + channel where they were created, and expire when the channel closes. + + + + + + consumer tag + + Identifier for the consumer, valid within the current connection. + + + The consumer tag is valid only within the channel from which the + consumer was created. I.e. a client MUST NOT create a consumer in + one channel and then use it in another. + + + + server-assigned delivery tag + + The server-assigned and channel-specific delivery tag + + + The delivery tag is valid only within the channel from which the + message was received. I.e. a client MUST NOT receive a message on + one channel and then acknowledge it on another. + + + The server MUST NOT use a zero value for delivery tags. Zero is + reserved for client use, meaning "all messages so far received". + + + + exchange name + + The exchange name is a client-selected string that identifies + the exchange for publish methods. Exchange names may consist + of any mixture of digits, letters, and underscores. Exchange + names are scoped by the virtual host. + + + + +list of known hosts + +Specifies the list of equivalent or alternative hosts that the server +knows about, which will normally include the current server itself. +Clients can cache this information and use it when reconnecting to a +server after a failure. + + +The server MAY leave this field empty if it knows of no other +hosts than itself. + + + + + no acknowledgement needed + + If this field is set the server does not expect acknowledgments + 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. + + + + do not deliver own messages + + If the no-local field is set the server will not send messages to + the client that published them. + + + + + Must start with a slash "/" and continue with path names + separated by slashes. A path name consists of any combination + of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. + + + + + + + +This string provides a set of peer properties, used for +identification, debugging, and general information. + + +The properties SHOULD contain these fields: +"product", giving the name of the peer product, "version", giving +the name of the peer version, "platform", giving the name of the +operating system, "copyright", if appropriate, and "information", +giving other general information. + + + + queue name + + The queue name identifies the queue within the vhost. Queue + names may consist of any mixture of digits, letters, and + underscores. + + + + + message is being redelivered + + This indicates that the message has been previously delivered to + this or another client. + + + The server SHOULD try to signal redelivered messages when it can. + When redelivering a message that was not successfully acknowledged, + the server SHOULD deliver it to the original client if possible. + + + The client MUST NOT rely on the redelivered field but MUST take it + as a hint that the message may already have been processed. A + fully robust client must be able to track duplicate received messages + on non-transacted, and locally-transacted channels. + + + +reply code from server + + The reply code. The AMQ reply codes are defined in AMQ RFC 011. + + + + +localised reply text + + The localised reply text. This text can be logged as an aid to + resolving issues. + + + + + + work with socket connections + + The connection class provides methods for a client to establish a + network connection to a server, and for both peers to operate the + connection thereafter. + + + connection = open-connection *use-connection close-connection + open-connection = C:protocol-header + S:START C:START-OK + *challenge + S:TUNE C:TUNE-OK + C:OPEN S:OPEN-OK | S:REDIRECT + challenge = S:SECURE C:SECURE-OK + use-connection = *channel + close-connection = C:CLOSE S:CLOSE-OK + / S:CLOSE C:CLOSE-OK + + + + + + start connection negotiation + + This method starts the connection negotiation process by telling + the client the protocol version that the server proposes, along + with a list of security mechanisms which the client can use for + authentication. + + + If the client cannot handle the protocol version suggested by the + server it MUST close the socket connection. + + + The server MUST provide a protocol version that is lower than or + equal to that requested by the client in the protocol header. If + the server cannot support the specified protocol it MUST NOT send + this method, but MUST close the socket connection. + + + + + protocol major version + + The protocol major version that the server agrees to use, which + cannot be higher than the client's major version. + + + + protocol major version + + The protocol minor version that the server agrees to use, which + cannot be higher than the client's minor version. + + + + server properties + + + available security mechanisms + + A list of the security mechanisms that the server supports, delimited + by spaces. Currently ASL supports these mechanisms: PLAIN. + + + + + + available message locales + + A list of the message locales that the server supports, delimited + by spaces. The locale defines the language in which the server + will send reply texts. + + + All servers MUST support at least the en_US locale. + + + + + + select security mechanism and locale + + This method selects a SASL security mechanism. ASL uses SASL + (RFC2222) to negotiate authentication and encryption. + + + + client properties + + + selected security mechanism + + 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. + + + The mechanism field MUST contain one of the security mechanisms + proposed by the server in the Start method. If it doesn't, the + server MUST close the socket. + + + + + security response data + + A block of opaque data passed to the security mechanism. The contents + of this data are defined by the SASL security mechanism. For the + PLAIN security mechanism this is defined as a field table holding + two fields, LOGIN and PASSWORD. + + + + + selected message locale + + A single message local selected by the client, which must be one + of those specified by the server. + + + + + + + security mechanism challenge + + The SASL protocol works by exchanging challenges and responses until + both peers have received sufficient information to authenticate each + other. This method challenges the client to provide more information. + + + + + security challenge data + + Challenge information, a block of opaque binary data passed to + the security mechanism. + + + + + + security mechanism response + + This method attempts to authenticate, passing a block of SASL data + for the security mechanism at the server side. + + + + security response data + + A block of opaque data passed to the security mechanism. The contents + of this data are defined by the SASL security mechanism. + + + + + + + propose connection tuning parameters + + This method proposes a set of connection configuration values + to the client. The client can accept and/or adjust these. + + + + + proposed maximum channels + + The maximum total number of channels that the server allows + per connection. Zero means that the server does not impose a + fixed limit, but the number of allowed channels may be limited + by available server resources. + + + + proposed maximum frame size + + The largest frame size that the server proposes for the + connection. The client can negotiate a lower value. Zero means + that the server does not impose any specific limit but may reject + very large frames if it cannot allocate resources for them. + + + Until the frame-max has been negotiated, both peers MUST accept + frames of up to 4096 octets large. The minimum non-zero value for + the frame-max field is 4096. + + + + desired heartbeat delay + + The delay, in seconds, of the connection heartbeat that the server + wants. Zero means the server does not want a heartbeat. + + + + + negotiate connection tuning parameters + + This method sends the client's connection tuning parameters to the + server. Certain fields are negotiated, others provide capability + information. + + + + negotiated maximum channels + + The maximum total number of channels that the client will use + per connection. May not be higher than the value specified by + the server. + + + The server MAY ignore the channel-max value or MAY use it for + tuning its resource allocation. + + + + + + negotiated maximum frame size + + The largest frame size that the client and server will use for + the connection. Zero means that the client does not impose any + specific limit but may reject very large frames if it cannot + allocate resources for them. Note that the frame-max limit + applies principally to content frames, where large contents + can be broken into frames of arbitrary size. + + + Until the frame-max has been negotiated, both peers must accept + frames of up to 4096 octets large. The minimum non-zero value for + the frame-max field is 4096. + + + + desired heartbeat delay + + The delay, in seconds, of the connection heartbeat that the client + wants. Zero means the client does not want a heartbeat. + + + + + + open connection to virtual host + + This method opens a connection to a virtual host, which is a + collection of resources, and acts to separate multiple application + domains within a server. + + + The client MUST open the context before doing any work on the + connection. + + + + + + virtual host name + + + 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 server MAY configure arbitrary limits per virtual host, such + as the number of each type of entity that may be used, per + connection and/or in total. + + + + required capabilities + + The client may specify a number of capability names, delimited by + spaces. The server can use this string to how to process the + client's connection request. + + + + insist on connecting to server + + In a configuration with multiple load-sharing servers, the server + may respond to a Connection.Open method with a Connection.Redirect. + The insist option tells the server that the client is insisting on + a connection to the specified server. + + + When the client uses the insist option, the server SHOULD accept + the client connection unless it is technically unable to do so. + + + + + signal that the connection is ready + + This method signals to the client that the connection is ready for + use. + + + + + + asks the client to use a different server + + This method redirects the client to another server, based on the + requested virtual host and/or capabilities. + + + When getting the Connection.Redirect method, the client SHOULD + reconnect to the host specified, and if that host is not present, + to any of the hosts specified in the known-hosts list. + + + + server to connect to + + Specifies the server to connect to. This is an IP address or a + DNS name, optionally followed by a colon and a port number. If + no port number is specified, the client should use the default + port number for the protocol. + + + + + + + + request a connection close + + This method indicates that the sender wants to close the connection. + This may be due to internal conditions (e.g. a forced shut-down) or + due to an error handling a specific method, i.e. an exception. When + a close is due to an exception, the sender provides the class and + method id of the method which caused the exception. + + + After sending this method any received method except the Close-OK + method MUST be discarded. + + + The peer sending this method MAY use a counter or timeout to + detect failure of the other peer to respond correctly with + the Close-OK method. + + + When a server receives the Close method from a client it MUST + delete all server-side resources associated with the client's + context. A client CANNOT reconnect to a context after sending + or receiving a Close method. + + + + + + + + failing method class + + When the close is provoked by a method exception, this is the + class of the method. + + + + failing method ID + + When the close is provoked by a method exception, this is the + ID of the method. + + + + + confirm a connection close + + This method confirms a Connection.Close method and tells the + recipient that it is safe to release resources for the connection + and close the socket. + + + A peer that detects a socket closure without having received a + Close-Ok handshake method SHOULD log the error. + + + + + + + + work with channels + + The channel class provides methods for a client to establish a virtual + connection - a channel - to a server and for both peers to operate the + virtual connection thereafter. + + + channel = open-channel *use-channel close-channel + open-channel = C:OPEN S:OPEN-OK + use-channel = C:FLOW S:FLOW-OK + / S:FLOW C:FLOW-OK + / S:ALERT + / functional-class + close-channel = C:CLOSE S:CLOSE-OK + / S:CLOSE C:CLOSE-OK + + + + + + open a channel for use + + This method opens a virtual connection (a channel). + + + This method MUST NOT be called when the channel is already open. + + + + + out-of-band settings + + Configures out-of-band transfers on this channel. The syntax and + meaning of this field will be formally defined at a later date. + + + + + + signal that the channel is ready + + This method signals to the client that the channel is ready for use. + + + + + + enable/disable flow from peer + + This method asks the peer to pause or restart the flow of content + data. This is a simple flow-control mechanism that a peer can use + to avoid oveflowing its queues or otherwise finding itself receiving + more messages than it can process. Note that this method is not + intended for window control. The peer that receives a request to + stop sending content should finish sending the current content, if + any, and then wait until it receives a Flow restart method. + + + When a new channel is opened, it is active. Some applications + assume that channels are inactive until started. To emulate this + behaviour a client MAY open the channel, then pause it. + + + When sending content data in multiple frames, a peer SHOULD monitor + the channel for incoming methods and respond to a Channel.Flow as + rapidly as possible. + + + A peer MAY use the Channel.Flow method to throttle incoming content + data for internal reasons, for example, when exchangeing data over a + slower connection. + + + The peer that requests a Channel.Flow method MAY disconnect and/or + ban a peer that does not respect the request. + + + + + + start/stop content frames + + If 1, the peer starts sending content frames. If 0, the peer + stops sending content frames. + + + + + confirm a flow method + + Confirms to the peer that a flow command was received and processed. + + + + + current flow setting + + Confirms the setting of the processed flow method: 1 means the + peer will start sending or continue to send content frames; 0 + means it will not. + + + + + + send a non-fatal warning message + + This method allows the server to send a non-fatal warning to the + client. This is used for methods that are normally asynchronous + and thus do not have confirmations, and for which the server may + detect errors that need to be reported. Fatal errors are handled + as channel or connection exceptions; non-fatal errors are sent + through this method. + + + + + + detailed information for warning + + A set of fields that provide more information about the + problem. The meaning of these fields are defined on a + per-reply-code basis (TO BE DEFINED). + + + + + + request a channel close + + This method indicates that the sender wants to close the channel. + This may be due to internal conditions (e.g. a forced shut-down) or + due to an error handling a specific method, i.e. an exception. When + a close is due to an exception, the sender provides the class and + method id of the method which caused the exception. + + + After sending this method any received method except + Channel.Close-OK MUST be discarded. + + + The peer sending this method MAY use a counter or timeout to detect + failure of the other peer to respond correctly with Channel.Close-OK.. + + + + + + + + failing method class + + When the close is provoked by a method exception, this is the + class of the method. + + + + failing method ID + + When the close is provoked by a method exception, this is the + ID of the method. + + + + + confirm a channel close + + This method confirms a Channel.Close method and tells the recipient + that it is safe to release resources for the channel and close the + socket. + + + A peer that detects a socket closure without having received a + Channel.Close-Ok handshake method SHOULD log the error. + + + + + + + + work with access tickets + + The protocol control access to server resources using access tickets. + A client must explicitly request access tickets before doing work. + An access ticket grants a client the right to use a specific set of + resources - called a "realm" - in specific ways. + + + access = C:REQUEST S:REQUEST-OK + + + + + + request an access ticket + + This method requests an access ticket for an access realm. + The server responds by granting the access ticket. If the + client does not have access rights to the requested realm + this causes a connection exception. Access tickets are a + per-channel resource. + + + The realm name MUST start with either "/data" (for application + resources) or "/admin" (for server administration resources). + If the realm starts with any other path, the server MUST raise + a connection exception with reply code 403 (access refused). + + + The server MUST implement the /data realm and MAY implement the + /admin realm. The mapping of resources to realms is not + defined in the protocol - this is a server-side configuration + issue. + + + + + name of requested realm + + If the specified realm is not known to the server, the server + must raise a channel exception with reply code 402 (invalid + path). + + + + request exclusive access + + Request exclusive access to the realm. If the server cannot grant + this - because there are other active tickets for the realm - it + raises a channel exception. + + + + request passive access + + Request message passive access to the specified access realm. + Passive access lets a client get information about resources in + the realm but not to make any changes to them. + + + + request active access + + Request message active access to the specified access realm. + Acvtive access lets a client get create and delete resources in + the realm. + + + + request write access + + Request write access to the specified access realm. Write access + lets a client publish messages to all exchanges in the realm. + + + + request read access + + Request read access to the specified access realm. Read access + lets a client consume messages from queues in the realm. + + + + + grant access to server resources + + This method provides the client with an access ticket. The access + ticket is valid within the current channel and for the lifespan of + the channel. + + + The client MUST NOT use access tickets except within the same + channel as originally granted. + + + The server MUST isolate access tickets per channel and treat an + attempt by a client to mix these as a connection exception. + + + + + + + + work with exchanges + + Exchanges match and distribute messages across queues. Exchanges can be + configured in the server or created at runtime. + + + exchange = C:DECLARE S:DECLARE-OK + / C:DELETE S:DELETE-OK + + + + + amq_exchange_19 + The server MUST implement the direct and fanout exchange types, and + predeclare the corresponding exchanges named amq.direct and amq.fanout + in each virtual host. The server MUST also predeclare a direct + exchange to act as the default exchange for content Publish methods + and for default queue bindings. + + + amq_exchange_20 + The server SHOULD implement the topic exchange type, and predeclare + the corresponding exchange named amq.topic in each virtual host. + + + amq_exchange_21 + The server MAY implement the system exchange type, and predeclare the + corresponding exchanges named amq.system in each virtual host. If the + client attempts to bind a queue to the system exchange, the server + MUST raise a connection exception with reply code 507 (not allowed). + + + amq_exchange_22 + The default exchange MUST be defined as internal, and be inaccessible + to the client except by specifying an empty exchange name in a content + Publish method. That is, the server MUST NOT let clients make explicit + bindings to this exchange. + + + + declare exchange, create if needed + + This method creates an exchange if it does not already exist, and if the + exchange exists, verifies that it is of the correct and expected class. + + + amq_exchange_23 + The server SHOULD support a minimum of 16 exchanges per virtual host + and ideally, impose no limit except as defined by available resources. + + + + + + When a client defines a new exchange, this belongs to the access realm + of the ticket used. All further work done with that exchange must be + done with an access ticket for the same realm. + + + The client MUST provide a valid access ticket giving "active" access + to the realm in which the exchange exists or will be created, or + "passive" access if the if-exists flag is set. + + + + + amq_exchange_15 + Exchange names starting with "amq." are reserved for predeclared + and standardised exchanges. If the client attempts to create an + exchange starting with "amq.", the server MUST raise a channel + exception with reply code 403 (access refused). + + + + + exchange type + + 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. + + + amq_exchange_16 + If the exchange already exists with a different type, the server + MUST raise a connection exception with a reply code 507 (not allowed). + + + amq_exchange_18 + If the server does not support the requested exchange type it MUST + raise a connection exception with a reply code 503 (command invalid). + + + + + do not create exchange + + 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. + + + amq_exchange_05 + If set, and the exchange does not already exist, the server MUST + raise a channel exception with reply code 404 (not found). + + + + request a durable exchange + + 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. + + + amq_exchange_24 + The server MUST support both durable and transient exchanges. + + + The server MUST ignore the durable field if the exchange already + exists. + + + + auto-delete when unused + + If set, the exchange is deleted when all queues have finished + using it. + + + amq_exchange_02 + The server SHOULD allow for a reasonable delay between the point + when it determines that an exchange is not being used (or no longer + used), and the point when it deletes the exchange. At the least it + must allow a client to create an exchange and then bind a queue to + it, with a small but non-zero delay between these two actions. + + + amq_exchange_25 + The server MUST ignore the auto-delete field if the exchange already + exists. + + + + create internal exchange + + If set, the exchange may not be used directly by publishers, but + only when bound to other exchanges. Internal exchanges are used to + construct wiring that is not visible to applications. + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + arguments for declaration + + 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. + + + + + confirms an exchange declaration + + This method confirms a Declare method and confirms the name of the + exchange, essential for automatically-named exchanges. + + + + + + delete an exchange + + This method deletes an exchange. When an exchange is deleted all queue + bindings on the exchange are cancelled. + + + + + + The client MUST provide a valid access ticket giving "active" + access rights to the exchange's access realm. + + + + + amq_exchange_11 + The exchange MUST exist. Attempting to delete a non-existing exchange + causes a channel exception. + + + + + delete only if unused + + If set, the server will only delete the exchange if it has no queue + bindings. If the exchange has queue bindings the server does not + delete it but raises a channel exception instead. + + + amq_exchange_12 + If set, the server SHOULD delete the exchange but only if it has + no queue bindings. + + + amq_exchange_13 + If set, the server SHOULD raise a channel exception if the exchange is in + use. + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm deletion of an exchange + + This method confirms the deletion of an exchange. + + + + + + + + Message routing key + + Specifies the routing key for the message. The routing key is + used for routing messages depending on the exchange configuration. + + + + + + + + + + + + + + + + work with queues + + + Queues store and forward messages. Queues can be configured in the server + or created at runtime. Queues must be attached to at least one exchange + in order to receive messages from publishers. + + + queue = C:DECLARE S:DECLARE-OK + / C:BIND S:BIND-OK + / C:PURGE S:PURGE-OK + / C:DELETE S:DELETE-OK + + + + + amq_queue_33 + A server MUST allow any content class to be sent to any queue, in any + mix, and queue and delivery these content classes independently. Note + that all methods that fetch content off queues are specific to a given + content class. + + + + declare queue, create if needed + + This method creates or checks a queue. When creating a new queue + the client can specify various properties that control the durability + of the queue and its contents, and the level of sharing for the queue. + + + amq_queue_34 + The server MUST create a default binding for a newly-created queue + to the default exchange, which is an exchange of type 'direct'. + + + amq_queue_35 + The server SHOULD support a minimum of 256 queues per virtual host + and ideally, impose no limit except as defined by available resources. + + + + + + When a client defines a new queue, this belongs to the access realm + of the ticket used. All further work done with that queue must be + done with an access ticket for the same realm. + + + The client provides a valid access ticket giving "active" access + to the realm in which the queue exists or will be created, or + "passive" access if the if-exists flag is set. + + + + + amq_queue_10 + The queue name MAY be empty, in which case the server MUST create + a new queue with a unique generated name and return this to the + client in the Declare-Ok method. + + + amq_queue_32 + Queue names starting with "amq." are reserved for predeclared and + standardised server queues. If the queue name starts with "amq." + and the passive option is zero, the server MUST raise a connection + exception with reply code 403 (access refused). + + + + + do not create queue + + If set, the server will not create the queue. The client can use + this to check whether a queue exists without modifying the server + state. + + + amq_queue_05 + If set, and the queue does not already exist, the server MUST + respond with a reply code 404 (not found) and raise a channel + exception. + + + + request a durable queue + + 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. + + + amq_queue_03 + The server MUST recreate the durable queue after a restart. + + + amq_queue_36 + The server MUST support both durable and transient queues. + + + amq_queue_37 + The server MUST ignore the durable field if the queue already + exists. + + + + request an exclusive queue + + Exclusive queues may only be consumed from by the current connection. + Setting the 'exclusive' flag always implies 'auto-delete'. + + + amq_queue_38 + The server MUST support both exclusive (private) and non-exclusive + (shared) queues. + + + amq_queue_04 + The server MUST raise a channel exception if 'exclusive' is specified + and the queue already exists and is owned by a different connection. + + + + auto-delete queue when unused + + If set, the queue is deleted when all consumers have finished + using it. Last consumer can be cancelled either explicitly or because + its channel is closed. If there was no consumer ever on the queue, it + won't be deleted. + + + amq_queue_02 + The server SHOULD allow for a reasonable delay between the point + when it determines that a queue is not being used (or no longer + used), and the point when it deletes the queue. At the least it + must allow a client to create a queue and then create a consumer + to read from it, with a small but non-zero delay between these + two actions. The server should equally allow for clients that may + be disconnected prematurely, and wish to re-consume from the same + queue without losing messages. We would recommend a configurable + timeout, with a suitable default value being one minute. + + + amq_queue_31 + The server MUST ignore the auto-delete field if the queue already + exists. + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + arguments for declaration + + 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. + + + + + confirms a queue definition + + This method confirms a Declare method and confirms the name of the + queue, essential for automatically-named queues. + + + + + Reports the name of the queue. If the server generated a queue + name, this field contains that name. + + + + + number of messages in queue + + Reports the number of messages in the queue, which will be zero + for newly-created queues. + + + + number of consumers + + Reports the number of active consumers for the queue. Note that + consumers can suspend activity (Channel.Flow) in which case they + do not appear in this count. + + + + + + bind queue to an exchange + + This method binds a queue to an exchange. Until a queue is + bound it will not receive any messages. In a classic messaging + model, store-and-forward queues are bound to a dest exchange + and subscription queues are bound to a dest_wild exchange. + + + amq_queue_25 + A server MUST allow ignore duplicate bindings - that is, two or + more bind methods for a specific queue, with identical arguments + - without treating these as an error. + + + amq_queue_39 + If a bind fails, the server MUST raise a connection exception. + + + amq_queue_12 + The server MUST NOT allow a durable queue to bind to a transient + exchange. If the client attempts this the server MUST raise a + channel exception. + + + amq_queue_13 + Bindings for durable queues are automatically durable and the + server SHOULD restore such bindings after a server restart. + + + amq_queue_17 + If the client attempts to an exchange that was declared as internal, + the server MUST raise a connection exception with reply code 530 + (not allowed). + + + amq_queue_40 + The server SHOULD support at least 4 bindings per queue, and + ideally, impose no limit except as defined by available resources. + + + + + + The client provides a valid access ticket giving "active" + access rights to the queue's access realm. + + + + + + Specifies the name of the queue to bind. If the queue name is + empty, refers to the current queue for the channel, which is + the last declared queue. + + + If the client did not previously declare a queue, and the queue + name in this method is empty, the server MUST raise a connection + exception with reply code 530 (not allowed). + + + If the queue does not exist the server MUST raise a channel exception + with reply code 404 (not found). + + + + + The name of the exchange to bind to. + + amq_queue_14 + If the exchange does not exist the server MUST raise a channel + exception with reply code 404 (not found). + + + + message routing key + + Specifies the routing key for the binding. The routing key is + used for routing messages depending on the exchange configuration. + Not all exchanges use a routing key - refer to the specific + exchange documentation. If the routing key is empty and the queue + name is empty, the routing key will be the current queue for the + channel, which is the last declared queue. + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + arguments for binding + + A set of arguments for the binding. The syntax and semantics of + these arguments depends on the exchange class. + + + + + confirm bind successful + + This method confirms that the bind was successful. + + + + + + purge a queue + + This method removes all messages from a queue. It does not cancel + consumers. Purged messages are deleted without any formal "undo" + mechanism. + + + amq_queue_15 + A call to purge MUST result in an empty queue. + + + amq_queue_41 + On transacted channels the server MUST not purge messages that have + already been sent to a client but not yet acknowledged. + + + amq_queue_42 + The server MAY implement a purge queue or log that allows system + administrators to recover accidentally-purged messages. The server + SHOULD NOT keep purged messages in the same storage spaces as the + live messages since the volumes of purged messages may get very + large. + + + + + + The access ticket must be for the access realm that holds the + queue. + + + The client MUST provide a valid access ticket giving "read" access + rights to the queue's access realm. Note that purging a queue is + equivalent to reading all messages and discarding them. + + + + + Specifies the name of the queue to purge. If the queue name is + empty, refers to the current queue for the channel, which is + the last declared queue. + + + If the client did not previously declare a queue, and the queue + name in this method is empty, the server MUST raise a connection + exception with reply code 530 (not allowed). + + + The queue must exist. Attempting to purge a non-existing queue + causes a channel exception. + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + confirms a queue purge + + This method confirms the purge of a queue. + + + + number of messages purged + + Reports the number of messages purged. + + + + + + delete a queue + + This method deletes a queue. When a queue is deleted any pending + messages are sent to a dead-letter queue if this is defined in the + server configuration, and all consumers on the queue are cancelled. + + + amq_queue_43 + The server SHOULD use a dead-letter queue to hold messages that + were pending on a deleted queue, and MAY provide facilities for + a system administrator to move these messages back to an active + queue. + + + + + + The client provides a valid access ticket giving "active" + access rights to the queue's access realm. + + + + + + Specifies the name of the queue to delete. If the queue name is + empty, refers to the current queue for the channel, which is the + last declared queue. + + + If the client did not previously declare a queue, and the queue + name in this method is empty, the server MUST raise a connection + exception with reply code 530 (not allowed). + + + The queue must exist. Attempting to delete a non-existing queue + causes a channel exception. + + + + + delete only if unused + + If set, the server will only delete the queue if it has no + consumers. If the queue has consumers the server does does not + delete it but raises a channel exception instead. + + + amq_queue_29 + amq_queue_30 + The server MUST respect the if-unused flag when deleting a queue. + + + + delete only if empty + amq_queue_27 + + If set, the server will only delete the queue if it has no + messages. If the queue is not empty the server raises a channel + exception. + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm deletion of a queue + + This method confirms the deletion of a queue. + + + + number of messages purged + + Reports the number of messages purged. + + + + + + + work with basic content + + The Basic class provides methods that support an industry-standard + messaging model. + + + + basic = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:PUBLISH content + / S:RETURN content + / S:DELIVER content + / C:GET ( S:GET-OK content / S:GET-EMPTY ) + / C:ACK + / C:REJECT + + + + + + + The server SHOULD respect the persistent property of basic messages + and SHOULD make a best-effort to hold persistent basic messages on a + reliable storage mechanism. + + + The server MUST NOT discard a persistent basic message in case of a + queue overflow. The server MAY use the Channel.Flow method to slow + or stop a basic message publisher when necessary. + + + The server MAY overflow non-persistent basic messages to persistent + storage and MAY discard or dead-letter non-persistent basic messages + on a priority basis if the queue size exceeds some configured limit. + + + The server MUST implement at least 2 priority levels for basic + messages, where priorities 0-4 and 5-9 are treated as two distinct + levels. The server MAY implement up to 10 priority levels. + + + The server MUST deliver messages of the same priority in order + irrespective of their individual persistence. + + + The server MUST support both automatic and explicit acknowledgements + on Basic content. + + + + + + MIME content type + + + MIME content encoding + + + Message header field table + + + Non-persistent (1) or persistent (2) + + + The message priority, 0 to 9 + + + The application correlation identifier + + + The destination to reply to + + + Message expiration specification + + + The application message identifier + + + The message timestamp + + + The message type name + + + The creating user id + + + The creating application id + + + Intra-cluster routing identifier + + + + + + + specify quality of service + + This method requests a specific quality of service. The QoS can + be specified for the current channel or for all channels on the + connection. The particular properties and semantics of a qos method + always depend on the content class semantics. Though the qos method + could in principle apply to both peers, it is currently meaningful + only for the server. + + + + + + prefetch window in octets + + 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 + down the channel. Prefetching gives a performance improvement. + This field specifies the prefetch window size in octets. The + server will send a message in advance if it is equal to or + smaller in size than the available prefetch size (and also falls + into other prefetch limits). May be set to zero, meaning "no + specific limit", although other prefetch limits may still apply. + The prefetch-size is ignored if the no-ack option is set. + + + The server MUST ignore this setting when the client is not + processing any messages - i.e. the prefetch size does not limit + the transfer of single messages to a client, only the sending in + advance of more messages while the client still has one or more + unacknowledged messages. + + + + + prefetch window in messages + + Specifies a prefetch window in terms of whole messages. This + field may be used in combination with the prefetch-size field; + a message will only be sent in advance if both prefetch windows + (and those at the channel and connection level) allow it. + The prefetch-count is ignored if the no-ack option is set. + + + The server MAY send less data in advance than allowed by the + client's specified prefetch windows but it MUST NOT send more. + + + + + apply to entire connection + + By default the QoS settings apply to the current channel only. If + this field is set, they are applied to the entire connection. + + + + + + confirm the requested qos + + This method tells the client that the requested QoS levels could + be handled by the server. The requested QoS applies to all active + consumers until a new QoS is defined. + + + + + + + + start a queue consumer + + This method asks the server to start a "consumer", which is a + transient request for messages from a specific queue. Consumers + last as long as the channel they were created on, or until the + client cancels them. + + + The server SHOULD support at least 16 consumers per queue, unless + the queue was declared as private, and ideally, impose no limit + except as defined by available resources. + + + + + + + The client MUST provide a valid access ticket giving "read" access + rights to the realm for the queue. + + + + + + Specifies the name of the queue to consume from. If the queue name + is null, refers to the current queue for the channel, which is the + last declared queue. + + + If the client did not previously declare a queue, and the queue name + in this method is empty, the server MUST raise a connection exception + with reply code 530 (not allowed). + + + + + + Specifies the identifier for the consumer. The consumer tag is + local to a connection, so two clients can use the same consumer + tags. If this field is empty the server will generate a unique + tag. + + + The tag MUST NOT refer to an existing consumer. If the client + attempts to create two consumers with the same non-empty tag + the server MUST raise a connection exception with reply code + 530 (not allowed). + + + + + + + + + request exclusive access + + Request exclusive consumer access, meaning only this consumer can + access the queue. + + + If the server cannot grant exclusive access to the queue when asked, + - because there are other consumers active - it MUST raise a channel + exception with return code 403 (access refused). + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + A set of arguments for the consume. The syntax and semantics + of these arguments depends on the server implementation. This + field is ignored if passive is 1. + + + + + + confirm a new consumer + + The server provides the client with a consumer tag, which is used + by the client for methods called on the consumer at a later stage. + + + + + + Holds the consumer tag specified by the client or provided by + the server. + + + + + + + + + end a queue consumer + + This method cancels a consumer. This does not affect already + delivered messages, but it does mean the server will not send any + more messages for that consumer. The client may receive an + abitrary number of messages in between sending the cancel method + and receiving the cancel-ok reply. + + + If the queue no longer exists when the client sends a cancel command, + or the consumer has been cancelled for other reasons, this command + has no effect. + + + + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm a cancelled consumer + + This method confirms that the cancellation was completed. + + + + + + + + + + + publish a message + + This method publishes a message to a specific exchange. The message + will be routed to queues as defined by the exchange configuration + and distributed to any active consumers when the transaction, if any, + is committed. + + + + + + The client MUST provide a valid access ticket giving "write" + access rights to the access realm for the exchange. + + + + + + Specifies the name of the exchange to publish to. The exchange + name can be empty, meaning the default exchange. If the exchange + name is specified, and that exchange does not exist, the server + will raise a channel exception. + + + The server MUST accept a blank exchange name to mean the default + exchange. + + + If the exchange was declared as an internal exchange, the server + MUST raise a channel exception with a reply code 403 (access + refused). + + + The exchange MAY refuse basic content in which case it MUST raise + a channel exception with reply code 540 (not implemented). + + + + + Message routing key + + Specifies the routing key for the message. The routing key is + used for routing messages depending on the exchange configuration. + + + + + indicate mandatory routing + + This flag tells the server how to react if the message cannot be + routed to a queue. If this flag is set, the server will return an + unroutable message with a Return method. If this flag is zero, the + server silently drops the message. + + + The server SHOULD implement the mandatory flag. + + + + + request immediate delivery + + This flag tells the server how to react if the message cannot be + routed to a queue consumer immediately. If this flag is set, the + server will return an undeliverable message with a Return method. + If this flag is zero, the server will queue the message, but with + no guarantee that it will ever be consumed. + + + The server SHOULD implement the immediate flag. + + + + + + return a failed message + + This method returns an undeliverable message that was published + with the "immediate" flag set, or an unroutable message published + with the "mandatory" flag set. The reply code and text provide + information about the reason that the message was undeliverable. + + + + + + + + + Specifies the name of the exchange that the message was + originally published to. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + + + + + notify the client of a consumer message + + This method delivers a message to the client, via a consumer. In + the asynchronous message delivery model, the client starts a + consumer using the Consume method, then the server responds with + Deliver methods as and when messages arrive for that consumer. + + + The server SHOULD track the number of times a message has been + delivered to clients and when a message is redelivered a certain + number of times - e.g. 5 times - without being acknowledged, the + server SHOULD consider the message to be unprocessable (possibly + causing client applications to abort), and move the message to a + dead letter queue. + + + + + + + + + + + + Specifies the name of the exchange that the message was + originally published to. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + + + + + direct access to a queue + + This method provides a direct access to the messages in a queue + using a synchronous dialogue that is designed for specific types of + application where synchronous functionality is more important than + performance. + + + + + + + + The client MUST provide a valid access ticket giving "read" + access rights to the realm for the queue. + + + + + + Specifies the name of the queue to consume from. If the queue name + is null, refers to the current queue for the channel, which is the + last declared queue. + + + If the client did not previously declare a queue, and the queue name + in this method is empty, the server MUST raise a connection exception + with reply code 530 (not allowed). + + + + + + + + provide client with a message + + This method delivers a message to the client following a get + method. A message delivered by 'get-ok' must be acknowledged + unless the no-ack option was set in the get method. + + + + + + + + + + Specifies the name of the exchange that the message was originally + published to. If empty, the message was published to the default + exchange. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + number of messages pending + + This field reports the number of messages pending on the queue, + excluding the message being delivered. Note that this figure is + indicative, not reliable, and can change arbitrarily as messages + are added to the queue and removed by other clients. + + + + + + + indicate no messages available + + This method tells the client that the queue has no messages + available for the client. + + + + + Cluster id + + For use by cluster applications, should not be used by + client applications. + + + + + + + + acknowledge one or more messages + + This method acknowledges one or more messages delivered via the + Deliver or Get-Ok methods. The client can ask to confirm a + single message or a set of messages up to and including a specific + message. + + + + + + acknowledge multiple messages + + If set to 1, the delivery tag is treated as "up to and including", + so that the client can acknowledge multiple messages with a single + method. If set to zero, the delivery tag refers to a single + message. If the multiple field is 1, and the delivery tag is zero, + tells the server to acknowledge all outstanding mesages. + + + The server MUST validate that a non-zero delivery-tag refers to an + delivered message, and raise a channel exception if this is not the + case. + + + + + + + + reject an incoming message + + This method allows a client to reject a message. It can be used to + interrupt and cancel large incoming messages, or return untreatable + messages to their original queue. + + + The server SHOULD be capable of accepting and process the Reject + method while sending message content with a Deliver or Get-Ok + method. I.e. the server should read and process incoming methods + while sending output frames. To cancel a partially-send content, + the server sends a content body frame of size 1 (i.e. with no data + except the frame-end octet). + + + The server SHOULD interpret this method as meaning that the client + is unable to process the message at this time. + + + A client MUST NOT use this method as a means of selecting messages + to process. A rejected message MAY be discarded or dead-lettered, + not necessarily passed to another client. + + + + + + + requeue the message + + 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 channel. 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. + + + + + + redeliver unacknowledged messages + + This method asks the broker to redeliver all unacknowledged messages on a + specified channel. Zero or more messages may be redelivered. This method + is only allowed on non-transacted channels. + + + + + requeue the message + + If this field is zero, the message will be redelivered to the original + recipient. If this bit is 1, the server will attempt to requeue the + message, potentially then delivering it to an alternative subscriber. + + + + The server MUST set the redelivered flag on all messages that are resent. + + + The server MUST raise a channel exception if this is called on a + transacted channel. + + + + + + + + + work with file content + + The file class provides methods that support reliable file transfer. + File messages have a specific set of properties that are required for + interoperability with file transfer applications. File messages and + acknowledgements are subject to channel transactions. Note that the + file class does not provide message browsing methods; these are not + compatible with the staging model. Applications that need browsable + file transfer should use Basic content and the Basic class. + + + + file = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:OPEN S:OPEN-OK C:STAGE content + / S:OPEN C:OPEN-OK S:STAGE content + / C:PUBLISH + / S:DELIVER + / S:RETURN + / C:ACK + / C:REJECT + + + + + + + The server MUST make a best-effort to hold file messages on a + reliable storage mechanism. + + + The server MUST NOT discard a file message in case of a queue + overflow. The server MUST use the Channel.Flow method to slow or stop + a file message publisher when necessary. + + + The server MUST implement at least 2 priority levels for file + messages, where priorities 0-4 and 5-9 are treated as two distinct + levels. The server MAY implement up to 10 priority levels. + + + The server MUST support both automatic and explicit acknowledgements + on file content. + + + + + + MIME content type + + + MIME content encoding + + + Message header field table + + + The message priority, 0 to 9 + + + The destination to reply to + + + The application message identifier + + + The message filename + + + The message timestamp + + + Intra-cluster routing identifier + + + + + + + specify quality of service + + This method requests a specific quality of service. The QoS can + be specified for the current channel or for all channels on the + connection. The particular properties and semantics of a qos method + always depend on the content class semantics. Though the qos method + could in principle apply to both peers, it is currently meaningful + only for the server. + + + + + + prefetch window in octets + + 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 + down the channel. Prefetching gives a performance improvement. + This field specifies the prefetch window size in octets. May be + set to zero, meaning "no specific limit". Note that other + prefetch limits may still apply. The prefetch-size is ignored + if the no-ack option is set. + + + + + prefetch window in messages + + Specifies a prefetch window in terms of whole messages. This + is compatible with some file API implementations. This field + may be used in combination with the prefetch-size field; a + message will only be sent in advance if both prefetch windows + (and those at the channel and connection level) allow it. + The prefetch-count is ignored if the no-ack option is set. + + + The server MAY send less data in advance than allowed by the + client's specified prefetch windows but it MUST NOT send more. + + + + + apply to entire connection + + By default the QoS settings apply to the current channel only. If + this field is set, they are applied to the entire connection. + + + + + + confirm the requested qos + + This method tells the client that the requested QoS levels could + be handled by the server. The requested QoS applies to all active + consumers until a new QoS is defined. + + + + + + + + start a queue consumer + + This method asks the server to start a "consumer", which is a + transient request for messages from a specific queue. Consumers + last as long as the channel they were created on, or until the + client cancels them. + + + The server SHOULD support at least 16 consumers per queue, unless + the queue was declared as private, and ideally, impose no limit + except as defined by available resources. + + + + + + + The client MUST provide a valid access ticket giving "read" access + rights to the realm for the queue. + + + + + + Specifies the name of the queue to consume from. If the queue name + is null, refers to the current queue for the channel, which is the + last declared queue. + + + If the client did not previously declare a queue, and the queue name + in this method is empty, the server MUST raise a connection exception + with reply code 530 (not allowed). + + + + + + Specifies the identifier for the consumer. The consumer tag is + local to a connection, so two clients can use the same consumer + tags. If this field is empty the server will generate a unique + tag. + + + The tag MUST NOT refer to an existing consumer. If the client + attempts to create two consumers with the same non-empty tag + the server MUST raise a connection exception with reply code + 530 (not allowed). + + + + + + + + + request exclusive access + + Request exclusive consumer access, meaning only this consumer can + access the queue. + + + If the server cannot grant exclusive access to the queue when asked, + - because there are other consumers active - it MUST raise a channel + exception with return code 405 (resource locked). + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm a new consumer + + This method provides the client with a consumer tag which it MUST + use in methods that work with the consumer. + + + + + + Holds the consumer tag specified by the client or provided by + the server. + + + + + + + + + end a queue consumer + + This method cancels a consumer. This does not affect already + delivered messages, but it does mean the server will not send any + more messages for that consumer. + + + + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm a cancelled consumer + + This method confirms that the cancellation was completed. + + + + + + + + + + + request to start staging + + This method requests permission to start staging a message. Staging + means sending the message into a temporary area at the recipient end + and then delivering the message by referring to this temporary area. + Staging is how the protocol handles partial file transfers - if a + message is partially staged and the connection breaks, the next time + the sender starts to stage it, it can restart from where it left off. + + + + + + + staging identifier + + 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.). + + + + + message content size + + 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. + + + + + + confirm staging ready + + This method confirms that the recipient is ready to accept staged + data. If the message was already partially-staged at a previous + time the recipient will report the number of octets already staged. + + + + + + + already staged amount + + The amount of previously-staged content in octets. For a new + message this will be zero. + + + The sender MUST start sending data from this octet offset in the + message, counting from zero. + + + The recipient MAY decide how long to hold partially-staged content + and MAY implement staging by always discarding partially-staged + content. However if it uses the file content type it MUST support + the staging methods. + + + + + + + + stage message content + + This method stages the message, sending the message content to the + recipient from the octet offset specified in the Open-Ok method. + + + + + + + + + + publish a message + + This method publishes a staged file message to a specific exchange. + The file message will be routed to queues as defined by the exchange + configuration and distributed to any active consumers when the + transaction, if any, is committed. + + + + + + The client MUST provide a valid access ticket giving "write" + access rights to the access realm for the exchange. + + + + + + Specifies the name of the exchange to publish to. The exchange + name can be empty, meaning the default exchange. If the exchange + name is specified, and that exchange does not exist, the server + will raise a channel exception. + + + The server MUST accept a blank exchange name to mean the default + exchange. + + + If the exchange was declared as an internal exchange, the server + MUST respond with a reply code 403 (access refused) and raise a + channel exception. + + + The exchange MAY refuse file content in which case it MUST respond + with a reply code 540 (not implemented) and raise a channel + exception. + + + + + Message routing key + + Specifies the routing key for the message. The routing key is + used for routing messages depending on the exchange configuration. + + + + + indicate mandatory routing + + This flag tells the server how to react if the message cannot be + routed to a queue. If this flag is set, the server will return an + unroutable message with a Return method. If this flag is zero, the + server silently drops the message. + + + The server SHOULD implement the mandatory flag. + + + + + request immediate delivery + + This flag tells the server how to react if the message cannot be + routed to a queue consumer immediately. If this flag is set, the + server will return an undeliverable message with a Return method. + If this flag is zero, the server will queue the message, but with + no guarantee that it will ever be consumed. + + + The server SHOULD implement the immediate flag. + + + + + staging identifier + + This is the staging identifier of the message to publish. The + message must have been staged. Note that a client can send the + Publish method asynchronously without waiting for staging to + finish. + + + + + + return a failed message + + This method returns an undeliverable message that was published + with the "immediate" flag set, or an unroutable message published + with the "mandatory" flag set. The reply code and text provide + information about the reason that the message was undeliverable. + + + + + + + + + Specifies the name of the exchange that the message was + originally published to. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + + + + + notify the client of a consumer message + + This method delivers a staged file message to the client, via a + consumer. In the asynchronous message delivery model, the client + starts a consumer using the Consume method, then the server + responds with Deliver methods as and when messages arrive for + that consumer. + + + The server SHOULD track the number of times a message has been + delivered to clients and when a message is redelivered a certain + number of times - e.g. 5 times - without being acknowledged, the + server SHOULD consider the message to be unprocessable (possibly + causing client applications to abort), and move the message to a + dead letter queue. + + + + + + + + + + + + Specifies the name of the exchange that the message was originally + published to. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + staging identifier + + This is the staging identifier of the message to deliver. The + message must have been staged. Note that a server can send the + Deliver method asynchronously without waiting for staging to + finish. + + + + + + + + + acknowledge one or more messages + + This method acknowledges one or more messages delivered via the + Deliver method. The client can ask to confirm a single message or + a set of messages up to and including a specific message. + + + + + + acknowledge multiple messages + + If set to 1, the delivery tag is treated as "up to and including", + so that the client can acknowledge multiple messages with a single + method. If set to zero, the delivery tag refers to a single + message. If the multiple field is 1, and the delivery tag is zero, + tells the server to acknowledge all outstanding mesages. + + + The server MUST validate that a non-zero delivery-tag refers to an + delivered message, and raise a channel exception if this is not the + case. + + + + + + + + + reject an incoming message + + This method allows a client to reject a message. It can be used to + return untreatable messages to their original queue. Note that file + content is staged before delivery, so the client will not use this + method to interrupt delivery of a large message. + + + The server SHOULD interpret this method as meaning that the client + is unable to process the message at this time. + + + A client MUST NOT use this method as a means of selecting messages + to process. A rejected message MAY be discarded or dead-lettered, + not necessarily passed to another client. + + + + + + + requeue the message + + 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 channel. 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. + + + + + + + + + work with streaming content + + + The stream class provides methods that support multimedia streaming. + The stream class uses the following semantics: one message is one + packet of data; delivery is unacknowleged and unreliable; the consumer + can specify quality of service parameters that the server can try to + adhere to; lower-priority messages may be discarded in favour of high + priority messages. + + + + stream = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:PUBLISH content + / S:RETURN + / S:DELIVER content + + + + + + + The server SHOULD discard stream messages on a priority basis if + the queue size exceeds some configured limit. + + + The server MUST implement at least 2 priority levels for stream + messages, where priorities 0-4 and 5-9 are treated as two distinct + levels. The server MAY implement up to 10 priority levels. + + + The server MUST implement automatic acknowledgements on stream + content. That is, as soon as a message is delivered to a client + via a Deliver method, the server must remove it from the queue. + + + + + + + MIME content type + + + MIME content encoding + + + Message header field table + + + The message priority, 0 to 9 + + + The message timestamp + + + + + + + specify quality of service + + This method requests a specific quality of service. The QoS can + be specified for the current channel or for all channels on the + connection. The particular properties and semantics of a qos method + always depend on the content class semantics. Though the qos method + could in principle apply to both peers, it is currently meaningful + only for the server. + + + + + + prefetch window in octets + + 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 + down the channel. Prefetching gives a performance improvement. + This field specifies the prefetch window size in octets. May be + set to zero, meaning "no specific limit". Note that other + prefetch limits may still apply. + + + + + prefetch window in messages + + Specifies a prefetch window in terms of whole messages. This + field may be used in combination with the prefetch-size field; + a message will only be sent in advance if both prefetch windows + (and those at the channel and connection level) allow it. + + + + + transfer rate in octets/second + + Specifies a desired transfer rate in octets per second. This is + usually determined by the application that uses the streaming + data. A value of zero means "no limit", i.e. as rapidly as + possible. + + + The server MAY ignore the prefetch values and consume rates, + depending on the type of stream and the ability of the server + to queue and/or reply it. The server MAY drop low-priority + messages in favour of high-priority messages. + + + + + apply to entire connection + + By default the QoS settings apply to the current channel only. If + this field is set, they are applied to the entire connection. + + + + + + confirm the requested qos + + This method tells the client that the requested QoS levels could + be handled by the server. The requested QoS applies to all active + consumers until a new QoS is defined. + + + + + + + + start a queue consumer + + This method asks the server to start a "consumer", which is a + transient request for messages from a specific queue. Consumers + last as long as the channel 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 channels to select + different streaming resolutions. AMQP makes no provision for + filtering and/or transforming streams except on the basis of + priority-based selective delivery of individual messages. + + + + + + + The client MUST provide a valid access ticket giving "read" access + rights to the realm for the queue. + + + + + + Specifies the name of the queue to consume from. If the queue name + is null, refers to the current queue for the channel, which is the + last declared queue. + + + If the client did not previously declare a queue, and the queue name + in this method is empty, the server MUST raise a connection exception + with reply code 530 (not allowed). + + + + + + Specifies the identifier for the consumer. The consumer tag is + local to a connection, so two clients can use the same consumer + tags. If this field is empty the server will generate a unique + tag. + + + The tag MUST NOT refer to an existing consumer. If the client + attempts to create two consumers with the same non-empty tag + the server MUST raise a connection exception with reply code + 530 (not allowed). + + + + + + + request exclusive access + + Request exclusive consumer access, meaning only this consumer can + access the queue. + + + If the server cannot grant exclusive access to the queue when asked, + - because there are other consumers active - it MUST raise a channel + exception with return code 405 (resource locked). + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + + confirm a new consumer + + This method provides the client with a consumer tag which it may + use in methods that work with the consumer. + + + + + + Holds the consumer tag specified by the client or provided by + the server. + + + + + + + + end a queue consumer + + This method cancels a consumer. Since message delivery is + asynchronous the client may continue to receive messages for + a short while after canceling a consumer. It may process or + discard these as appropriate. + + + + + + + + do not send a reply method + + If set, the server will not respond to the method. The client should + not wait for a reply method. If the server could not complete the + method it will raise a channel or connection exception. + + + + + + confirm a cancelled consumer + + This method confirms that the cancellation was completed. + + + + + + + + + + + publish a message + + This method publishes a message to a specific exchange. The message + will be routed to queues as defined by the exchange configuration + and distributed to any active consumers as appropriate. + + + + + + The client MUST provide a valid access ticket giving "write" + access rights to the access realm for the exchange. + + + + + + Specifies the name of the exchange to publish to. The exchange + name can be empty, meaning the default exchange. If the exchange + name is specified, and that exchange does not exist, the server + will raise a channel exception. + + + The server MUST accept a blank exchange name to mean the default + exchange. + + + If the exchange was declared as an internal exchange, the server + MUST respond with a reply code 403 (access refused) and raise a + channel exception. + + + The exchange MAY refuse stream content in which case it MUST + respond with a reply code 540 (not implemented) and raise a + channel exception. + + + + + Message routing key + + Specifies the routing key for the message. The routing key is + used for routing messages depending on the exchange configuration. + + + + + indicate mandatory routing + + This flag tells the server how to react if the message cannot be + routed to a queue. If this flag is set, the server will return an + unroutable message with a Return method. If this flag is zero, the + server silently drops the message. + + + The server SHOULD implement the mandatory flag. + + + + + request immediate delivery + + This flag tells the server how to react if the message cannot be + routed to a queue consumer immediately. If this flag is set, the + server will return an undeliverable message with a Return method. + If this flag is zero, the server will queue the message, but with + no guarantee that it will ever be consumed. + + + The server SHOULD implement the immediate flag. + + + + + + return a failed message + + This method returns an undeliverable message that was published + with the "immediate" flag set, or an unroutable message published + with the "mandatory" flag set. The reply code and text provide + information about the reason that the message was undeliverable. + + + + + + + + + Specifies the name of the exchange that the message was + originally published to. + + + + + Message routing key + + Specifies the routing key name specified when the message was + published. + + + + + + + + + notify the client of a consumer message + + This method delivers a message to the client, via a consumer. In + the asynchronous message delivery model, the client starts a + consumer using the Consume method, then the server responds with + Deliver methods as and when messages arrive for that consumer. + + + + + + + + + + Specifies the name of the exchange that the message was originally + published to. + + + + + + Specifies the name of the queue that the message came from. Note + that a single channel can start many consumers on different + queues. + + + + + + + + + work with standard transactions + + + 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. + + + 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. + + + tx = C:SELECT S:SELECT-OK + / C:COMMIT S:COMMIT-OK + / C:ROLLBACK S:ROLLBACK-OK + + + + + +select standard transaction mode + + This method sets the channel to use standard transactions. The + client must use this method at least once on a channel before + using the Commit or Rollback methods. + + + + + +confirm transaction mode + + This method confirms to the client that the channel was successfully + set to use standard transactions. + + + + + +commit the current transaction + + This method commits all messages published and acknowledged in + the current transaction. A new transaction starts immediately + after a commit. + + + + + +confirm a successful commit + + This method confirms to the client that the commit succeeded. + Note that if a commit fails, the server raises a channel exception. + + + + + +abandon the current transaction + + This method abandons all messages published and acknowledged in + the current transaction. A new transaction starts immediately + after a rollback. + + + + + +confirm a successful rollback + + This method confirms to the client that the rollback succeeded. + Note that if an rollback fails, the server raises a channel exception. + + + + + + + work with distributed transactions + + + Distributed transactions provide so-called "2-phase commit". The + AMQP distributed transaction model supports the X-Open XA + architecture and other distributed transaction implementations. + The Dtx class assumes that the server has a private communications + channel (not AMQP) to a distributed transaction coordinator. + + + dtx = C:SELECT S:SELECT-OK + C:START S:START-OK + + + + + +select standard transaction mode + + This method sets the channel to use distributed transactions. The + client must use this method at least once on a channel before + using the Start method. + + + + + +confirm transaction mode + + This method confirms to the client that the channel was successfully + set to use distributed transactions. + + + + + + start a new distributed transaction + + This method starts a new distributed transaction. This must be + the first method on a new channel that uses the distributed + transaction mode, before any methods that publish or consume + messages. + + + + + transaction identifier + + The distributed transaction key. This identifies the transaction + so that the AMQP server can coordinate with the distributed + transaction coordinator. + + + + + + confirm the start of a new distributed transaction + + This method confirms to the client that the transaction started. + Note that if a start fails, the server raises a channel exception. + + + + + + + methods for protocol tunneling. + + + The tunnel methods are used to send blocks of binary data - which + can be serialised AMQP methods or other protocol frames - between + AMQP peers. + + + tunnel = C:REQUEST + / S:REQUEST + + + + + Message header field table + + + The identity of the tunnelling proxy + + + The name or type of the message being tunnelled + + + The message durability indicator + + + The message broadcast mode + + + + sends a tunnelled method + + This method tunnels a block of binary data, which can be an + encoded AMQP method or other data. The binary data is sent + as the content for the Tunnel.Request method. + + + + meta data for the tunnelled block + + This field table holds arbitrary meta-data that the sender needs + to pass to the recipient. + + + + + + + test functional primitives of the implementation + + + The test class provides methods for a peer to test the basic + operational correctness of another peer. The test methods are + intended to ensure that all peers respect at least the basic + elements of the protocol, such as frame and content organisation + and field types. We assume that a specially-designed peer, a + "monitor client" would perform such tests. + + + test = C:INTEGER S:INTEGER-OK + / S:INTEGER C:INTEGER-OK + / C:STRING S:STRING-OK + / S:STRING C:STRING-OK + / C:TABLE S:TABLE-OK + / S:TABLE C:TABLE-OK + / C:CONTENT S:CONTENT-OK + / S:CONTENT C:CONTENT-OK + + + + + + test integer handling + + This method tests the peer's capability to correctly marshal integer + data. + + + + + + octet test value + + An octet integer test value. + + + + short test value + + A short integer test value. + + + + long test value + + A long integer test value. + + + + long-long test value + + A long long integer test value. + + + + operation to test + + The client must execute this operation on the provided integer + test fields and return the result. + + + return sum of test values + return lowest of test values + return highest of test values + + + + + report integer test result + + This method reports the result of an Integer method. + + + + + result value + + The result of the tested operation. + + + + + + test string handling + + This method tests the peer's capability to correctly marshal string + data. + + + + + + short string test value + + An short string test value. + + + + long string test value + + A long string test value. + + + + operation to test + + The client must execute this operation on the provided string + test fields and return the result. + + + return concatentation of test strings + return shortest of test strings + return longest of test strings + + + + + report string test result + + This method reports the result of a String method. + + + + + result value + + The result of the tested operation. + + + + + + test field table handling + + This method tests the peer's capability to correctly marshal field + table data. + + + + + + field table of test values + + A field table of test values. + + + + operation to test on integers + + The client must execute this operation on the provided field + table integer values and return the result. + + + return sum of numeric field values + return min of numeric field values + return max of numeric field values + + + + operation to test on strings + + The client must execute this operation on the provided field + table string values and return the result. + + + return concatenation of string field values + return shortest of string field values + return longest of string field values + + + + + report table test result + + This method reports the result of a Table method. + + + + + integer result value + + The result of the tested integer operation. + + + + string result value + + The result of the tested string operation. + + + + + + test content handling + + This method tests the peer's capability to correctly marshal content. + + + + + + + report content test result + + This method reports the result of a Content method. It contains the + content checksum and echoes the original content as provided. + + + + + content hash + + The 32-bit checksum of the content, calculated by adding the + content into a 32-bit accumulator. + + + + + diff --git a/specs/amqp.0-9.xml b/specs/amqp.0-9.xml new file mode 100644 index 0000000000..9d1b488c03 --- /dev/null +++ b/specs/amqp.0-9.xml @@ -0,0 +1,5185 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Indicates that the method completed successfully. This reply code is + reserved for future use - the current protocol design does not use positive + confirmation and reply codes are sent only in case of an error. + + + + + + The client asked for a specific message that is no longer available. + The message was delivered to another client, or was purged from the queue + for some other reason. + + + + + + The client attempted to transfer content larger than the server could accept + at the present time. The client may retry at a later time. + + + + + + When the exchange cannot route the result of a .Publish, most likely due + to an invalid routing key. Only when the mandatory flag is set. + + + + + + When the exchange cannot deliver to a consumer when the immediate flag is + set. As a result of pending data on the queue or the absence of any + consumers of the queue. + + + + + + An operator intervened to close the connection for some reason. The client + may retry at some later date. + + + + + + The client tried to work with an unknown virtual host. + + + + + + The client attempted to work with a server entity to which it has no + access due to security settings. + + + + + The client attempted to work with a server entity that does not exist. + + + + + The client attempted to work with a server entity to which it has no + access because another client is working with it. + + + + + + The client requested a method that was not allowed because some precondition + failed. + + + + + + The client sent a malformed frame that the server could not decode. This + strongly implies a programming error in the client. + + + + + + The client sent a frame that contained illegal values for one or more + fields. This strongly implies a programming error in the client. + + + + + + The client sent an invalid sequence of frames, attempting to perform an + operation that was considered invalid by the server. This usually implies + a programming error in the client. + + + + + + The client attempted to work with a channel that had not been correctly + opened. This most likely indicates a fault in the client layer. + + + + + + The server could not complete the method because it lacked sufficient + resources. This may be due to the client creating too many of some type + of entity. + + + + + + The client tried to work with some entity in a manner that is prohibited + by the server, due to security settings or by some other criteria. + + + + + + The client tried to use functionality that is not implemented in the + server. + + + + + + The server could not complete the method because of an internal error. + The server may require intervention by an operator in order to resume + normal operations. + + + + + + + + An access ticket granted by the server for a certain set of access rights + within a specific realm. Access tickets are valid within the channel where + they were created, and expire when the channel closes. + + + + + + + + + Identifier for the consumer, valid within the current connection. + + + + + + The server-assigned and channel-specific delivery tag + + + + The delivery tag is valid only within the channel from which the message was + received. I.e. a client MUST NOT receive a message on one channel and then + acknowledge it on another. + + + + + The server MUST NOT use a zero value for delivery tags. Zero is reserved + for client use, meaning "all messages so far received". + + + + + + + The exchange name is a client-selected string that identifies the exchange for publish + methods. Exchange names may consist of any mixture of digits, letters, and underscores. + Exchange names are scoped by the virtual host. + + + + + + + Specifies the list of equivalent or alternative hosts that the server knows about, + which will normally include the current server itself. Clients can cache this + information and use it when reconnecting to a server after a failure. This field + may be empty. + + + + + + + + If this field is set the server does not expect acknowledgements for + messages. That is, when a message is delivered to the client the server + automatically and silently acknowledges it on behalf of the client. This + functionality increases performance but at the cost of reliability. + Messages can get lost if a client dies before it can deliver them to the + application. + + + + + + If the no-local field is set the server will not send messages to the connection that + published them. + + + + + + Must start with a slash "/" and continue with path names separated by slashes. A path + name consists of any combination of at least one of [A-Za-z0-9] plus zero or more of + [.-_+!=:]. + + + + + + + + + + This string provides a set of peer properties, used for identification, debugging, and + general information. + + + + + + The queue name identifies the queue within the vhost. Queue names may consist of any + mixture of digits, letters, and underscores. + + + + + + + This indicates that the message has been previously delivered to this or + another client. + + + + The server SHOULD try to signal redelivered messages when it can. When + redelivering a message that was not successfully acknowledged, the server + SHOULD deliver it to the original client if possible. + + + Create a shared queue and publish a message to the queue. Consume the + message using explicit acknowledgements, but do not acknowledge the + message. Close the connection, reconnect, and consume from the queue + again. The message should arrive with the redelivered flag set. + + + + + The client MUST NOT rely on the redelivered field but should take it as a + hint that the message may already have been processed. A fully robust + client must be able to track duplicate received messages on non-transacted, + and locally-transacted channels. + + + + + + + The reply code. The AMQ reply codes are defined as constants at the start + of this formal specification. + + + + + + + The localised reply text. This text can be logged as an aid to resolving + issues. + + + + + + + + + + + + + Specifies the destination to which the message is to be + transferred. The destination can be empty, meaning the + default exchange or consumer. + + + + + + The reject code must be one of 0 (generic) or 1 (immediate + delivery was attempted but failed). + + + + + + + Used for authentication, replay prevention, and encrypted bodies. + + + + + + + + + + + + + + + + + + + + + The connection class provides methods for a client to establish a network connection to + a server, and for both peers to operate the connection thereafter. + + + + connection = open-connection *use-connection close-connection + open-connection = C:protocol-header + S:START C:START-OK + *challenge + S:TUNE C:TUNE-OK + C:OPEN S:OPEN-OK | S:REDIRECT + challenge = S:SECURE C:SECURE-OK + use-connection = *channel + close-connection = C:CLOSE S:CLOSE-OK + / S:CLOSE C:CLOSE-OK + + + + + + + + + + This method starts the connection negotiation process by telling the client the + protocol version that the server proposes, along with a list of security mechanisms + which the client can use for authentication. + + + + + If the server cannot support the protocol specified in the protocol header, + it MUST close the socket connection without sending any response method. + + + The client sends a protocol header containing an invalid protocol name. + The server must respond by closing the connection. + + + + + The server MUST provide a protocol version that is lower than or equal to + that requested by the client in the protocol header. + + + The client requests a protocol version that is higher than any valid + implementation, e.g. 9.0. The server must respond with a current + protocol version, e.g. 1.0. + + + + + If the client cannot handle the protocol version suggested by the server + it MUST close the socket connection. + + + The server sends a protocol version that is lower than any valid + implementation, e.g. 0.1. The client must respond by closing the + connection. + + + + + + + + + The protocol version, major component, as transmitted in the AMQP protocol + header. This, combined with the protocol minor component fully describe the + protocol version, which is written in the format major-minor. Hence, with + major=1, minor=3, the protocol version would be "1-3". + + + + + + The protocol version, minor component, as transmitted in the AMQP protocol + header. This, combined with the protocol major component fully describe the + protocol version, which is written in the format major-minor. Hence, with + major=1, minor=3, the protocol version would be "1-3". + + + + + + + The properties SHOULD contain at least these fields: "host", specifying the + server host name or address, "product", giving the name of the server product, + "version", giving the name of the server version, "platform", giving the name + of the operating system, "copyright", if appropriate, and "information", giving + other general information. + + + Client connects to server and inspects the server properties. It checks for + the presence of the required fields. + + + + + + + A list of the security mechanisms that the server supports, delimited by spaces. + + + + + + + A list of the message locales that the server supports, delimited by spaces. The + locale defines the language in which the server will send reply texts. + + + + The server MUST support at least the en_US locale. + + + Client connects to server and inspects the locales field. It checks for + the presence of the required locale(s). + + + + + + + + + This method selects a SASL security mechanism. + + + + + + + + + The properties SHOULD contain at least these fields: "product", giving the name + of the client product, "version", giving the name of the client version, "platform", + giving the name of the operating system, "copyright", if appropriate, and + "information", giving other general information. + + + + + + + A single security mechanisms selected by the client, which must be one of those + specified by the server. + + + + The client SHOULD authenticate using the highest-level security profile it + can handle from the list provided by the server. + + + + + If the mechanism field does not contain one of the security mechanisms + proposed by the server in the Start method, the server MUST close the + connection without sending any further data. + + + Client connects to server and sends an invalid security mechanism. The + server must respond by closing the connection (a socket close, with no + connection close negotiation). + + + + + + + + A block of opaque data passed to the security mechanism. The contents of this + data are defined by the SASL security mechanism. + + + + + + + A single message locale selected by the client, which must be one of those + specified by the server. + + + + + + + + + + The SASL protocol works by exchanging challenges and responses until both peers have + received sufficient information to authenticate each other. This method challenges + the client to provide more information. + + + + + + + + Challenge information, a block of opaque binary data passed to the security + mechanism. + + + + + + + This method attempts to authenticate, passing a block of SASL data for the security + mechanism at the server side. + + + + + + + A block of opaque data passed to the security mechanism. The contents of this + data are defined by the SASL security mechanism. + + + + + + + + + + This method proposes a set of connection configuration values to the client. The + client can accept and/or adjust these. + + + + + + + + + The maximum total number of channels that the server allows per connection. Zero + means that the server does not impose a fixed limit, but the number of allowed + channels may be limited by available server resources. + + + + + + The largest frame size that the server proposes for the connection. The client + can negotiate a lower value. Zero means that the server does not impose any + specific limit but may reject very large frames if it cannot allocate resources + for them. + + + + Until the frame-max has been negotiated, both peers MUST accept frames of up + to frame-min-size octets large, and the minimum negotiated value for frame-max + is also frame-min-size. + + + Client connects to server and sends a large properties field, creating a frame + of frame-min-size octets. The server must accept this frame. + + + + + + + + The delay, in seconds, of the connection heartbeat that the server wants. + Zero means the server does not want a heartbeat. + + + + + + + This method sends the client's connection tuning parameters to the server. + Certain fields are negotiated, others provide capability information. + + + + + + + The maximum total number of channels that the client will use per connection. + + + + If the client specifies a channel max that is higher than the value provided + by the server, the server MUST close the connection without attempting a + negotiated close. The server may report the error in some fashion to assist + implementors. + + + + + + + + + The largest frame size that the client and server will use for the connection. + Zero means that the client does not impose any specific limit but may reject + very large frames if it cannot allocate resources for them. Note that the + frame-max limit applies principally to content frames, where large contents can + be broken into frames of arbitrary size. + + + + Until the frame-max has been negotiated, both peers MUST accept frames of up + to frame-min-size octets large, and the minimum negotiated value for frame-max + is also frame-min-size. + + + + + If the client specifies a frame max that is higher than the value provided + by the server, the server MUST close the connection without attempting a + negotiated close. The server may report the error in some fashion to assist + implementors. + + + + + + + The delay, in seconds, of the connection heartbeat that the client wants. Zero + means the client does not want a heartbeat. + + + + + + + + + This method opens a connection to a virtual host, which is a collection of + resources, and acts to separate multiple application domains within a server. + The server may apply arbitrary limits per virtual host, such as the number + of each type of entity that may be used, per connection and/or in total. + + + + + + + + + + + The name of the virtual host to work with. + + + + If the server supports multiple virtual hosts, it MUST enforce a full + separation of exchanges, queues, and all associated entities per virtual + host. An application, connected to a specific virtual host, MUST NOT be able + to access resources of another virtual host. + + + + + The server SHOULD verify that the client has permission to access the + specified virtual host. + + + + + + + The client can specify zero or more capability names, delimited by spaces. + The server can use this string to how to process the client's connection + request. + + + + + + In a configuration with multiple collaborating servers, the server may respond + to a Connection.Open method with a Connection.Redirect. The insist option tells + the server that the client is insisting on a connection to the specified server. + + + + When the client uses the insist option, the server MUST NOT respond with a + Connection.Redirect method. If it cannot accept the client's connection + request it should respond by closing the connection with a suitable reply + code. + + + + + + + + This method signals to the client that the connection is ready for use. + + + + + + + + This method redirects the client to another server, based on the requested virtual + host and/or capabilities. + + + + When getting the Connection.Redirect method, the client SHOULD reconnect to + the host specified, and if that host is not present, to any of the hosts + specified in the known-hosts list. + + + + + + Specifies the server to connect to. This is an IP address or a DNS name, + optionally followed by a colon and a port number. If no port number is + specified, the client should use the default port number for the protocol. + + + + + + + + + + + This method indicates that the sender wants to close the connection. This may be + due to internal conditions (e.g. a forced shut-down) or due to an error handling + a specific method, i.e. an exception. When a close is due to an exception, the + sender provides the class and method id of the method which caused the exception. + + + + + After sending this method any received method except the Close-OK method MUST + be discarded. + + + + + + + + + + + + + When the close is provoked by a method exception, this is the class of the + method. + + + + + + When the close is provoked by a method exception, this is the ID of the method. + + + + + + + This method confirms a Connection.Close method and tells the recipient that it is + safe to release resources for the connection and close the socket. + + + + A peer that detects a socket closure without having received a Close-Ok + handshake method SHOULD log the error. + + + + + + + + + + + + The channel class provides methods for a client to establish a channel to a + server and for both peers to operate the channel thereafter. + + + + channel = open-channel *use-channel close-channel + open-channel = C:OPEN S:OPEN-OK + / C:RESUME S:OK + use-channel = C:FLOW S:FLOW-OK + / S:FLOW C:FLOW-OK + / S:PING C:OK + / C:PONG S:OK + / C:PING S:OK + / S:PONG C:OK + / functional-class + close-channel = C:CLOSE S:CLOSE-OK + / S:CLOSE C:CLOSE-OK + + + + + + + + + + This method opens a channel to the server. + + + + The client MUST NOT use this method on an already-opened channel. + + + Client opens a channel and then reopens the same channel. + + + + + + + Configures out-of-band transfers on this channel. The syntax and meaning of this + field will be formally defined at a later date. + + + + + + + + This method signals to the client that the channel is ready for use. + + + + + + + + + + This method asks the peer to pause or restart the flow of content data. This is a + simple flow-control mechanism that a peer can use to avoid overflowing its queues or + otherwise finding itself receiving more messages than it can process. Note that this + method is not intended for window control. The peer that receives a disable flow + method should finish sending the current content frame, if any, then pause. + + + + + When a new channel is opened, it is active (flow is active). Some applications + assume that channels are inactive until started. To emulate this behaviour a + client MAY open the channel, then pause it. + + + + + + When sending content frames, a peer SHOULD monitor the channel for incoming + methods and respond to a Channel.Flow as rapidly as possible. + + + + + + A peer MAY use the Channel.Flow method to throttle incoming content data for + internal reasons, for example, when exchanging data over a slower connection. + + + + + + The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer + that does not respect the request. This is to prevent badly-behaved clients + from overwhelming a broker. + + + + + + + + + + + If 1, the peer starts sending content frames. If 0, the peer stops sending + content frames. + + + + + + + Confirms to the peer that a flow command was received and processed. + + + + + + Confirms the setting of the processed flow method: 1 means the peer will start + sending or continue to send content frames; 0 means it will not. + + + + + + + + + This method indicates that the sender wants to close the channel. This may be due to + internal conditions (e.g. a forced shut-down) or due to an error handling a specific + method, i.e. an exception. When a close is due to an exception, the sender provides + the class and method id of the method which caused the exception. + + + + + + After sending this method any received method except the Close-OK method MUST + be discarded. + + + + + + + + + + + + + When the close is provoked by a method exception, this is the class of the + method. + + + + + + When the close is provoked by a method exception, this is the ID of the method. + + + + + + + This method confirms a Channel.Close method and tells the recipient that it is safe + to release resources for the channel. + + + + A peer that detects a socket closure without having received a Channel.Close-Ok + handshake method SHOULD log the error. + + + + + + + + + + + This method resume a previously interrupted channel. + + + + + + + + + + + [WORK IN PROGRESS] Request that the recipient issue a pong request. + + + + + + + + + [WORK IN PROGRESS] Issued after a ping request is received. Note that this is a + request issued after receiving a ping, not a response to + receiving a ping. + + + + + + + + + [WORK IN PROGRESS] Signals normal completion of a method. + + + + + + + + + + + + + The protocol control access to server resources using access tickets. A + client must explicitly request access tickets before doing work. An access + ticket grants a client the right to use a specific set of resources - + called a "realm" - in specific ways. + + + + access = C:REQUEST S:REQUEST-OK + + + + + + + + + + This method requests an access ticket for an access realm. The server + responds by granting the access ticket. If the client does not have + access rights to the requested realm this causes a connection exception. + Access tickets are a per-channel resource. + + + + + + + + Specifies the name of the realm to which the client is requesting access. + The realm is a configured server-side object that collects a set of + resources (exchanges, queues, etc.). If the channel has already requested + an access ticket onto this realm, the previous ticket is destroyed and a + new ticket is created with the requested access rights, if allowed. + + + + The client MUST specify a realm that is known to the server. The server + makes an identical response for undefined realms as it does for realms + that are defined but inaccessible to this client. + + + Client specifies an undefined realm. + + + + + + + Request exclusive access to the realm, meaning that this will be the only + channel that uses the realm's resources. + + + + The client MAY NOT request exclusive access to a realm that has active + access tickets, unless the same channel already had the only access + ticket onto that realm. + + + Client opens two channels and requests exclusive access to the same realm. + + + + + + Request message passive access to the specified access realm. Passive + access lets a client get information about resources in the realm but + not to make any changes to them. + + + + + Request message active access to the specified access realm. Active access lets + a client get create and delete resources in the realm. + + + + + Request write access to the specified access realm. Write access lets a client + publish messages to all exchanges in the realm. + + + + + Request read access to the specified access realm. Read access lets a client + consume messages from queues in the realm. + + + + + + + This method provides the client with an access ticket. The access ticket is valid + within the current channel and for the lifespan of the channel. + + + + The client MUST NOT use access tickets except within the same channel as + originally granted. + + + Client opens two channels, requests a ticket on one channel, and then + tries to use that ticket in a second channel. + + + + + + + + + + + + Exchanges match and distribute messages across queues. Exchanges can be configured in + the server or created at runtime. + + + + exchange = C:DECLARE S:DECLARE-OK + / C:DELETE S:DELETE-OK + + + + + + + + The server MUST implement these standard exchange types: fanout, direct. + + + Client attempts to declare an exchange with each of these standard types. + + + + + The server SHOULD implement these standard exchange types: topic, headers. + + + Client attempts to declare an exchange with each of these standard types. + + + + + The server MUST, in each virtual host, pre-declare an exchange instance + for each standard exchange type that it implements, where the name of the + exchange instance, if defined, is "amq." followed by the exchange type name. + + + The server MUST, in each virtual host, pre-declare at least two direct + exchange instances: one named "amq.direct", the other with no public name + that serves as a default exchange for Publish methods. + + + Client creates a temporary queue and attempts to bind to each required + exchange instance ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" + if those types are defined). + + + + + The server MUST pre-declare a direct exchange with no public name to act as + the default exchange for content Publish methods and for default queue bindings. + + + Client checks that the default exchange is active by specifying a queue + binding with no exchange name, and 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 server MUST NOT allow clients to access the default exchange except + by specifying an empty exchange name in the Queue.Bind and content Publish + methods. + + + + + The server MAY implement other exchange types as wanted. + + + + + + + + This method creates an exchange if it does not already exist, and if the exchange + exists, verifies that it is of the correct and expected class. + + + + The server SHOULD support a minimum of 16 exchanges per virtual host and + ideally, impose no limit except as defined by available resources. + + + The client creates as many exchanges as it can until the server reports + an error; the number of exchanges successfully created must be at least + sixteen. + + + + + + + + + When a client defines a new exchange, this belongs to the access realm of the + ticket used. All further work done with that exchange must be done with an + access ticket for the same realm. + + + + The client MUST provide a valid access ticket giving "active" access to + the realm in which the exchange exists or will be created, or "passive" + access if the if-exists flag is set. + + + Client creates access ticket with wrong access rights and attempts to use + in this method. + + + + + + + + Exchange names starting with "amq." are reserved for pre-declared and + standardised exchanges. The client MUST NOT attempt to create an exchange + starting with "amq.". + + + TODO. + + + + + + + + Each exchange belongs to one of a set of exchange types implemented by the + server. The exchange types define the functionality of the exchange - i.e. how + messages are routed through it. It is not valid or meaningful to attempt to + change the type of an existing exchange. + + + + Exchanges cannot be redeclared with different types. The client MUST not + attempt to redeclare an existing exchange with a different type than used + in the original Exchange.Declare method. + + + TODO. + + + + + The client MUST NOT attempt to create an exchange with a type that the + server does not support. + + + TODO. + + + + + + + + If set, the server will not create the exchange. The client can use this to + check whether an exchange exists without modifying the server state. + + + + If set, and the exchange does not already exist, the server MUST raise a + channel exception with reply code 404 (not found). + + + TODO. + + + + + + + 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. + + + TODO. + + + + + The server MUST ignore the durable field if the exchange already exists. + + + TODO. + + + + + + + + If set, the exchange is deleted when all queues have finished using it. + + + + The server MUST ignore the auto-delete field if the exchange already + exists. + + + TODO. + + + + + + + If set, the exchange may not be used directly by publishers, but only when bound + to other exchanges. Internal exchanges are used to construct wiring that is not + visible to applications. + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + A set of arguments for the declaration. The syntax and semantics of these + arguments depends on the server implementation. This field is ignored if passive + is 1. + + + + + + + This method confirms a Declare method and confirms the name of the exchange, + essential for automatically-named exchanges. + + + + + + + + + This method deletes an exchange. When an exchange is deleted all queue bindings on + the exchange are cancelled. + + + + + + + + + The client MUST provide a valid access ticket giving "active" access + rights to the exchange's access realm. + + + Client creates access ticket with wrong access rights and attempts to use + in this method. + + + + + + + + The client MUST NOT attempt to delete an exchange that does not exist. + + + + + + + + + If set, the server will only delete the exchange if it has no queue bindings. If + the exchange has queue bindings the server does not delete it but raises a + channel exception instead. + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + This method confirms the deletion of an exchange. + + + + + + + + + Queues store and forward messages. Queues can be configured in the server or created at + runtime. Queues must be attached to at least one exchange in order to receive messages + from publishers. + + + + queue = C:DECLARE S:DECLARE-OK + / C:BIND S:BIND-OK + / C:PURGE S:PURGE-OK + / C:DELETE S:DELETE-OK + + + + + + + + A server MUST allow any content class to be sent to any queue, in any mix, and + queue and deliver these content classes independently. Note that all methods + that fetch content off queues are specific to a given content class. + + + Client creates an exchange of each standard type and several queues that + it binds to each exchange. It must then successfully send each of the standard + content types to each of the available queues. + + + + + + + + This method creates or checks a queue. When creating a new queue the client can + specify various properties that control the durability of the queue and its + contents, and the level of sharing for the queue. + + + + + The server MUST create a default binding for a newly-created queue to the + default exchange, which is an exchange of type 'direct' and use the queue + name as the routing key. + + + Client creates a new queue, and then without explicitly binding it to an + exchange, attempts to send a message through the default exchange binding, + i.e. publish a message to the empty exchange, with the queue name as routing + key. + + + + + + + The server SHOULD support a minimum of 256 queues per virtual host and ideally, + impose no limit except as defined by available resources. + + + Client attempts to create as many queues as it can until the server reports + an error. The resulting count must at least be 256. + + + + + + + + + When a client defines a new queue, this belongs to the access realm of the + ticket used. All further work done with that queue must be done with an access + ticket for the same realm. + + + + The client MUST provide a valid access ticket giving "active" access to + the realm in which the queue exists or will be created. + + + Client creates access ticket with wrong access rights and attempts to use + in this method. + + + + + + + + The queue name MAY be empty, in which case the server MUST create a new + queue with a unique generated name and return this to the client in the + Declare-Ok method. + + + Client attempts to create several queues with an empty name. The client then + verifies that the server-assigned names are unique and different. + + + + + Queue names starting with "amq." are reserved for pre-declared and + standardised server queues. A client MAY NOT attempt to declare a queue with a + name that starts with "amq." and the passive option set to zero. + + + A client attempts to create a queue with a name starting with "amq." and with + the passive option set to zero. + + + + + + + + If set, the server will not create the queue. This field allows the client + to assert the presence of a queue without modifying the server state. + + + + The client MAY ask the server to assert that a queue exists without + creating the queue if not. If the queue does not exist, the server + treats this as a failure. + + + Client declares an existing queue with the passive option and expects + the server to respond with a declare-ok. Client then attempts to declare + a non-existent queue with the passive option, and the server must close + the channel with the correct reply-code. + + + + + + + If set when creating a new queue, the queue will be marked as durable. Durable + queues remain active when a server restarts. Non-durable queues (transient + queues) are purged if/when a server restarts. Note that durable queues do not + necessarily hold persistent messages, although it does not make sense to send + persistent messages to a transient queue. + + + + The server MUST recreate the durable queue after a restart. + + + + A client creates a durable queue. The server is then restarted. The client + then attempts to send a 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 may only be consumed from by the current connection. Setting + the 'exclusive' flag always implies 'auto-delete'. + + + + + + The server MUST support both exclusive (private) and non-exclusive (shared) + queues. + + + A client creates two named queues, one exclusive and one non-exclusive. + + + + + + + The client MAY NOT attempt to declare any existing and exclusive queue + on multiple connections. + + + A client declares an exclusive named queue. A second client on a different + connection attempts to declare a queue of the same name. + + + + + + + If set, the queue is deleted when all consumers have finished using it. Last + consumer can be cancelled either explicitly or because its channel is closed. If + there was no consumer ever on the queue, it won't be deleted. + + + + + + The server MUST ignore the auto-delete field if the queue already exists. + + + A client creates two named queues, one as auto-delete and one explicit-delete. + The client then attempts to declare the two queues using the same names again, + but reversing the value of the auto-delete field in each case. Verify that the + queues still exist with the original auto-delete flag values. + + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + A set of arguments for the declaration. The syntax and semantics of these + arguments depends on the server implementation. This field is ignored if passive + is 1. + + + + + + + This method confirms a Declare method and confirms the name of the queue, essential + for automatically-named queues. + + + + + + + Reports the name of the queue. If the server generated a queue name, this field + contains that name. + + + + + + + Reports the number of messages in the queue, which will be zero for + newly-created queues. + + + + + + Reports the number of active consumers for the queue. Note that consumers can + suspend activity (Channel.Flow) in which case they do not appear in this count. + + + + + + + + + This method binds a queue to an exchange. Until a queue is bound it will not receive + any messages. In a classic messaging model, store-and-forward queues are bound to a + direct exchange and subscription queues are bound to a topic exchange. + + + + + + A server MUST allow ignore duplicate bindings - that is, two or more bind + methods for a specific queue, with identical arguments - without treating these + as an error. + + + A client binds a named queue to an exchange. The client then repeats the bind + (with identical arguments). + + + + + + + If a bind fails, the server MUST raise a connection exception. + + TODO + + + + + + + The server MUST NOT allow a durable queue to bind to a transient exchange. + + + A client creates a transient exchange. The client then declares a named durable + queue and then attempts to bind the transient exchange to the durable queue. + + + + + + + Bindings for durable queues are automatically durable and the server SHOULD + restore such bindings after a server restart. + + + A server creates a named durable queue and binds it to a durable exchange. The + server is restarted. The client then attempts to use the queue/exchange combination. + + + + + + + If the client attempts to bind to an exchange that was declared as internal, the server + MUST raise a connection exception with reply code 530 (not allowed). + + + A client attempts to bind a named queue to an internal exchange. + + + + + + + The server SHOULD support at least 4 bindings per queue, and ideally, impose no + limit except as defined by available resources. + + + A client creates a named queue and attempts to bind it to 4 different non-internal + exchanges. + + + + + + + + + + The client provides a valid access ticket giving "active" access rights to the + queue's access realm. + + + + + + Specifies the name of the queue to bind. If the queue name is empty, refers to + the current queue for the channel, which is the last declared queue. + + + + + A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. + empty queue name) to an exchange. + + + A client attempts to bind with an unnamed (empty) queue name to an exchange. + + + + + + + A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously + declared) to an exchange. + + + A client attempts to bind an undeclared queue name to an exchange. + + + + + + + + + A client MUST NOT be allowed to bind a queue to a non-existent exchange. + + + A client attempts to bind an named queue to a undeclared exchange. + + + + + + + Specifies the routing key for the binding. The routing key is used for routing + messages depending on the exchange configuration. Not all exchanges use a + routing key - refer to the specific exchange documentation. If the queue name + is empty, the server uses the last queue declared on the channel. If the + routing key is also empty, the server uses this queue name for the routing + key as well. If the queue name is provided but the routing key is empty, the + server does the binding with that empty routing key. The meaning of empty + routing keys depends on the exchange implementation. + + + + If a message queue binds to a direct exchange using routing key K and a + publisher sends the exchange a message with routing key R, then the message + MUST be passed to the message queue if K = R. + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + A set of arguments for the binding. The syntax and semantics of these arguments + depends on the exchange class. + + + + + + This method confirms that the bind was successful. + + + + + + + + This method unbinds a queue from an exchange. + + If a unbind fails, the server MUST raise a connection exception. + + + + + + + The client provides a valid access ticket giving "active" + access rights to the queue's access realm. + + + + + Specifies the name of the queue to unbind. + + + If the queue does not exist the server MUST raise a channel exception + with reply code 404 (not found). + + + + + + The name of the exchange to unbind from. + + + If the exchange does not exist the server MUST raise a channel + exception with reply code 404 (not found). + + + + + + Specifies the routing key of the binding to unbind. + + + + Specifies the arguments of the binding to unbind. + + + + + This method confirms that the unbind was successful. + + + + + + + + This method removes all messages from a queue. It does not cancel consumers. Purged + messages are deleted without any formal "undo" mechanism. + + + + + A call to purge MUST result in an empty queue. + + + + + + On transacted channels the server MUST not purge messages that have already been + sent to a client but not yet acknowledged. + + + + + + + + + The server MAY implement a purge queue or log that allows system administrators + to recover accidentally-purged messages. The server SHOULD NOT keep purged + messages in the same storage spaces as the live messages since the volumes of + purged messages may get very large. + + + + + + + + + The access ticket must be for the access realm that holds the queue. + + + + The client MUST provide a valid access ticket giving "read" access rights to + the queue's access realm. Note that purging a queue is equivalent to reading + all messages and discarding them. + + + + + + + Specifies the name of the queue to purge. If the queue name is empty, refers to + the current queue for the channel, which is the last declared queue. + + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + + + + + + + The queue MUST exist. Attempting to purge a non-existing queue MUST cause a + channel exception. + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + This method confirms the purge of a queue. + + + + + Reports the number of messages purged. + + + + + + + + This method deletes a queue. When a queue is deleted any pending messages are sent + to a dead-letter queue if this is defined in the server configuration, and all + consumers on the queue are cancelled. + + + + + + + + The server SHOULD use a dead-letter queue to hold messages that were pending on + a deleted queue, and MAY provide facilities for a system administrator to move + these messages back to an active queue. + + + + + + + + + + The client provides a valid access ticket giving "active" access rights to the + queue's access realm. + + + + + + Specifies the name of the queue to delete. If the queue name is empty, refers to + the current queue for the channel, which is the last declared queue. + + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + + + + + The queue must exist. If the client attempts to delete a non-existing queue + the server MUST raise a channel exception with reply code 404 (not found). + + + + + + + If set, the server will only delete the queue if it has no consumers. If the + queue has consumers the server does does not delete it but raises a channel + exception instead. + + + + + The server MUST respect the if-unused flag when deleting a queue. + + + + + + If set, the server will only delete the queue if it has no messages. + + + + If the queue is not empty the server MUST raise a channel exception with + reply code 406 (precondition failed). + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + This method confirms the deletion of a queue. + + + + + Reports the number of messages purged. + + + + + + + + + The Basic class provides methods that support an industry-standard messaging model. + + + + basic = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:PUBLISH content + / S:RETURN content + / S:DELIVER content + / C:GET ( S:GET-OK content / S:GET-EMPTY ) + / C:ACK + / C:REJECT + + + + + + + + + The server SHOULD respect the persistent property of basic messages and + SHOULD make a best-effort to hold persistent basic messages on a reliable + storage mechanism. + + + Send a persistent message to queue, stop server, restart server and then + verify whether message is still present. Assumes that queues are durable. + Persistence without durable queues makes no sense. + + + + + + + The server MUST NOT discard a persistent basic message in case of a queue + overflow. + + + Create a queue overflow situation with persistent messages and verify that + messages do not get lost (presumably the server will write them to disk). + + + + + + The server MAY use the Channel.Flow method to slow or stop a basic message + publisher when necessary. + + + Create a queue overflow situation with non-persistent messages and verify + whether the server responds with Channel.Flow or not. Repeat with persistent + messages. + + + + + + + The server MAY overflow non-persistent basic messages to persistent + storage. + + + + + + + The server MAY discard or dead-letter non-persistent basic messages on a + priority basis if the queue size exceeds some configured limit. + + + + + + + + The server MUST implement at least 2 priority levels for basic messages, + where priorities 0-4 and 5-9 are treated as two distinct levels. + + + Send a number of priority 0 messages to a queue. Send one priority 9 + message. Consume messages from the queue and verify that the first message + received was priority 9. + + + + + + The server MAY implement up to 10 priority levels. + + + Send a number of messages with mixed priorities to a queue, so that all + priority values from 0 to 9 are exercised. A good scenario would be ten + messages in low-to-high priority. Consume from queue and verify how many + priority levels emerge. + + + + + + + The server MUST deliver messages of the same priority in order irrespective of + their individual persistence. + + + Send a set of messages with the same priority but different persistence + settings to a queue. Consume and verify that messages arrive in same order + as originally published. + + + + + + + The server MUST support automatic acknowledgements on Basic content, i.e. + consumers with the no-ack field set to FALSE. + + + Create a queue and a consumer using automatic acknowledgements. Publish + a set of messages to the queue. Consume the messages and verify that all + messages are received. + + + + + + The server MUST support explicit acknowledgements on Basic content, i.e. + consumers with the no-ack field set to TRUE. + + + Create a queue and a consumer using explicit acknowledgements. Publish a + set of messages to the queue. Consume the messages but acknowledge only + half of them. Disconnect and reconnect, and consume from the queue. + Verify that the remaining messages are received. + + + + + + + + + + + + + + + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the + current channel or for all channels on the connection. The particular properties and + semantics of a qos method always depend on the content class semantics. Though the + qos method could in principle apply to both peers, it is currently meaningful only + for the server. + + + + + + + + The client can request that messages be sent in advance so that when the client + finishes processing a message, the following message is already held locally, + rather than needing to be sent down the channel. Prefetching gives a performance + improvement. This field specifies the prefetch window size in octets. The server + will send a message in advance if it is equal to or smaller in size than the + available prefetch size (and also falls into other prefetch limits). May be set + to zero, meaning "no specific limit", although other prefetch limits may still + apply. The prefetch-size is ignored if the no-ack option is set. + + + + + The server MUST ignore this setting when the client is not processing any + messages - i.e. the prefetch size does not limit the transfer of single + messages to a client, only the sending in advance of more messages while + the client still has one or more unacknowledged messages. + + + Define a QoS prefetch-size limit and send a single message that exceeds + that limit. Verify that the message arrives correctly. + + + + + + + Specifies a prefetch window in terms of whole messages. This field may be used + in combination with the prefetch-size field; a message will only be sent in + advance if both prefetch windows (and those at the channel and connection level) + allow it. The prefetch-count is ignored if the no-ack option is set. + + + + + The server may send less data in advance than allowed by the client's + specified prefetch windows but it MUST NOT send more. + + + Define a QoS prefetch-size limit and a prefetch-count limit greater than + one. Send multiple messages that exceed the prefetch size. Verify that + no more than one message arrives at once. + + + + + + + By default the QoS settings apply to the current channel only. If this field is + set, they are applied to the entire connection. + + + + + + + This method tells the client that the requested QoS levels could be handled by the + server. The requested QoS applies to all active consumers until a new QoS is + defined. + + + + + + + + + This method asks the server to start a "consumer", which is a transient request for + messages from a specific queue. Consumers last as long as the channel they were + created on, or until the client cancels them. + + + + + + The server SHOULD support at least 16 consumers per queue, and ideally, impose + no limit except as defined by available resources. + + + Create a queue and create consumers on that queue until the server closes the + connection. Verify that the number of consumers created was at least sixteen + and report the total number. + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + Attempt to create a consumer with an invalid (non-zero) access ticket. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + If the queue name is empty the client MUST have previously declared a + queue using this channel. + + + Attempt to create a consumer with an empty queue name and no previously + declared queue on the channel. + + + + + + + Specifies the identifier for the consumer. The consumer tag is local to a + connection, so two clients can use the same consumer tags. If this field is + empty the server will generate a unique tag. + + + + The client MUST NOT specify a tag that refers to an existing consumer. + + + Attempt to create two consumers with the same non-empty tag. + + + + + The consumer tag is valid only within the channel from which the + consumer was created. I.e. a client MUST NOT create a consumer in one + channel and then use it in another. + + + Attempt to create a consumer in one channel, then use in another channel, + in which consumers have also been created (to test that the server uses + unique consumer tags). + + + + + + + + + + + Request exclusive consumer access, meaning only this consumer can access the + queue. + + + + + The client MAY NOT gain exclusive access to a queue that already has + active consumers. + + + Open two connections to a server, and in one connection create a shared + (non-exclusive) queue and then consume from the queue. In the second + connection attempt to consume from the same queue using the exclusive + option. + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise + a channel or connection exception. + + + + + + A set of filters for the consume. The syntax and semantics + of these filters depends on the providers implementation. + + + + + + + The server provides the client with a consumer tag, which is used by the client + for methods called on the consumer at a later stage. + + + + + Holds the consumer tag specified by the client or provided by the server. + + + + + + + + + This method cancels a consumer. This does not affect already delivered + messages, but it does mean the server will not send any more messages for + that consumer. The client may receive an arbitrary number of messages in + between sending the cancel method and receiving the cancel-ok reply. + + + + + If the queue does not exist the server MUST ignore the cancel method, so + long as the consumer tag is valid for that channel. + + + TODO. + + + + + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + + This method confirms that the cancellation was completed. + + + + + + + + + + This method publishes a message to a specific exchange. The message will be routed + to queues as defined by the exchange configuration and distributed to any active + consumers when the transaction, if any, is committed. + + + + + + + + The client MUST provide a valid access ticket giving "write" access rights + to the access realm for the exchange. + + + TODO. + + + + + + + Specifies the name of the exchange to publish to. The exchange name can be + empty, meaning the default exchange. If the exchange name is specified, and that + exchange does not exist, the server will raise a channel exception. + + + + + + The server MUST accept a blank exchange name to mean the default exchange. + + + TODO. + + + + + + + If the exchange was declared as an internal exchange, the server MUST raise + a channel exception with a reply code 403 (access refused). + + + TODO. + + + + + + + The exchange MAY refuse basic content in which case it MUST raise a channel + exception with reply code 540 (not implemented). + + + TODO. + + + + + + + Specifies the routing key for the message. The routing key is used for routing + messages depending on the exchange configuration. + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue. If this flag is set, the server will return an unroutable message with a + Return method. If this flag is zero, the server silently drops the message. + + + + + The server SHOULD implement the mandatory flag. + + + TODO. + + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue consumer immediately. If this flag is set, the server will return an + undeliverable message with a Return method. If this flag is zero, the server + will queue the message, but with no guarantee that it will ever be consumed. + + + + + The server SHOULD implement the immediate flag. + + + TODO. + + + + + + + + This method returns an undeliverable message that was published with the "immediate" + flag set, or an unroutable message published with the "mandatory" flag set. The + reply code and text provide information about the reason that the message was + undeliverable. + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + + This method delivers a message to the client, via a consumer. In the asynchronous + message delivery model, the client starts a consumer using the Consume method, then + the server responds with Deliver methods as and when messages arrive for that + consumer. + + + + + + + The server SHOULD track the number of times a message has been delivered to + clients and when a message is redelivered a certain number of times - e.g. 5 + times - without being acknowledged, the server SHOULD consider the message to be + unprocessable (possibly causing client applications to abort), and move the + message to a dead letter queue. + + + TODO. + + + + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + This method provides a direct access to the messages in a queue using a synchronous + dialogue that is designed for specific types of application where synchronous + functionality is more important than performance. + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + TODO. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + TODO. + + + + + + + + + + This method delivers a message to the client following a get method. A message + delivered by 'get-ok' must be acknowledged unless the no-ack option was set in the + get method. + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + If empty, the message was published to the default exchange. + + + + + Specifies the routing key name specified when the message was published. + + + + + This field reports the number of messages pending on the queue, excluding the + message being delivered. Note that this figure is indicative, not reliable, and + can change arbitrarily as messages are added to the queue and removed by other + clients. + + + + + + + This method tells the client that the queue has no messages available for the + client. + + + + + + + + For use by cluster applications, should not be used by client applications. + + + + + + + + + This method acknowledges one or more messages delivered via the Deliver or Get-Ok + methods. The client can ask to confirm a single message or a set of messages up to + and including a specific message. + + + + + + + + + If set to 1, the delivery tag is treated as "up to and including", so that the + client can acknowledge multiple messages with a single method. If set to zero, + the delivery tag refers to a single message. If the multiple field is 1, and the + delivery tag is zero, tells the server to acknowledge all outstanding messages. + + + + + + The server MUST validate that a non-zero delivery-tag refers to an delivered + message, and raise a channel exception if this is not the case. + + + TODO. + + + + + + + + + + This method allows a client to reject a message. It can be used to interrupt and + cancel large incoming messages, or return untreatable messages to their original + queue. + + + + + + The server SHOULD be capable of accepting and process the Reject method while + sending message content with a Deliver or Get-Ok method. I.e. the server should + read and process incoming methods while sending output frames. To cancel a + partially-send content, the server sends a content body frame of size 1 (i.e. + with no data except the frame-end octet). + + + + + + + The server SHOULD interpret this method as meaning that the client is unable to + process the message at this time. + + + TODO. + + + + + + + A client MUST NOT use this method as a means of selecting messages to process. A + rejected message MAY be discarded or dead-lettered, not necessarily passed to + another client. + + + TODO. + + + + + + + + + + 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 channel. 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. + + + TODO. + + + + + + + + This method asks the broker to redeliver all unacknowledged messages on a specified + channel. Zero or more messages may be redelivered. This method is only allowed on + non-transacted channels. + + + + + The server MUST set the redelivered flag on all messages that are resent. + + + TODO. + + + + + + The server MUST raise a channel exception if this is called on a transacted + channel. + + + TODO. + + + + + + + + If this field is zero, the message will be redelivered to the original + recipient. If this bit is 1, the server will attempt to requeue the message, + potentially then delivering it to an alternative subscriber. + + + + + + + + + + The file class provides methods that support reliable file transfer. File + messages have a specific set of properties that are required for interoperability + with file transfer applications. File messages and acknowledgements are subject to + channel transactions. Note that the file class does not provide message browsing + methods; these are not compatible with the staging model. Applications that need + browsable file transfer should use Basic content and the Basic class. + + + + file = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:OPEN S:OPEN-OK C:STAGE content + / S:OPEN C:OPEN-OK S:STAGE content + / C:PUBLISH + / S:DELIVER + / S:RETURN + / C:ACK + / C:REJECT + + + + + + + + The server MUST make a best-effort to hold file messages on a reliable storage + mechanism. + + + + + + + + + + The server MUST NOT discard a file message in case of a queue overflow. The server + MUST use the Channel.Flow method to slow or stop a file message publisher when + necessary. + + + + + + + + The server MUST implement at least 2 priority levels for file messages, where + priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement + up to 10 priority levels. + + + + + + The server MUST support both automatic and explicit acknowledgements on file + content. + + + + + + + + + + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the + current channel or for all channels on the connection. The particular properties and + semantics of a qos method always depend on the content class semantics. Though the + qos method could in principle apply to both peers, it is currently meaningful only + for the server. + + + + + + + + + The client can request that messages be sent in advance so that when the client + finishes processing a message, the following message is already held locally, + rather than needing to be sent down the channel. Prefetching gives a performance + improvement. This field specifies the prefetch window size in octets. May be set + to zero, meaning "no specific limit". Note that other prefetch limits may still + apply. The prefetch-size is ignored if the no-ack option is set. + + + + + + Specifies a prefetch window in terms of whole messages. This is compatible with + some file API implementations. This field may be used in combination with the + prefetch-size field; a message will only be sent in advance if both prefetch + windows (and those at the channel and connection level) allow it. The + prefetch-count is ignored if the no-ack option is set. + + + + + + The server MAY send less data in advance than allowed by the client's + specified prefetch windows but it MUST NOT send more. + + + + + + + By default the QoS settings apply to the current channel only. If this field is + set, they are applied to the entire connection. + + + + + + + This method tells the client that the requested QoS levels could be handled by the + server. The requested QoS applies to all active consumers until a new QoS is + defined. + + + + + + + + + + This method asks the server to start a "consumer", which is a transient request for + messages from a specific queue. Consumers last as long as the channel they were + created on, or until the client cancels them. + + + + + The server SHOULD support at least 16 consumers per queue, unless the queue was + declared as private, and ideally, impose no limit except as defined by available + resources. + + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + + + + + Specifies the identifier for the consumer. The consumer tag is local to a + connection, so two clients can use the same consumer tags. If this field is + empty the server will generate a unique tag. + + + + + + The tag MUST NOT refer to an existing consumer. If the client attempts to + create two consumers with the same non-empty tag the server MUST raise a + connection exception with reply code 530 (not allowed). + + + + + + + + + + + Request exclusive consumer access, meaning only this consumer can access the + queue. + + + + + + If the server cannot grant exclusive access to the queue when asked, - + because there are other consumers active - it MUST raise a channel exception + with return code 405 (resource locked). + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + A set of filters for the consume. The syntax and semantics + of these filters depends on the providers implementation. + + + + + + + This method provides the client with a consumer tag which it MUST use in methods + that work with the consumer. + + + + + + Holds the consumer tag specified by the client or provided by the server. + + + + + + + + This method cancels a consumer. This does not affect already delivered messages, but + it does mean the server will not send any more messages for that consumer. + + + + + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + This method confirms that the cancellation was completed. + + + + + + + + + + + This method requests permission to start staging a message. Staging means sending + the message into a temporary area at the recipient end and then delivering the + message by referring to this temporary area. Staging is how the protocol handles + partial file transfers - if a message is partially staged and the connection breaks, + the next time the sender starts to stage it, it can restart from where it left off. + + + + + + + + + + This is the staging identifier. This is an arbitrary string chosen by the + sender. For staging to work correctly the sender must use the same staging + identifier when staging the same message a second time after recovery from a + failure. A good choice for the staging identifier would be the SHA1 hash of the + message properties data (including the original filename, revised time, etc.). + + + + + + The size of the content in octets. The recipient may use this information to + allocate or check available space in advance, to avoid "disk full" errors during + staging of very large messages. + + + + + The sender MUST accurately fill the content-size field. Zero-length content + is permitted. + + + + + + + + This method confirms that the recipient is ready to accept staged data. If the + message was already partially-staged at a previous time the recipient will report + the number of octets already staged. + + + + + + + + + + The amount of previously-staged content in octets. For a new message this will + be zero. + + + + + The sender MUST start sending data from this octet offset in the message, + counting from zero. + + + + + + + The recipient MAY decide how long to hold partially-staged content and MAY + implement staging by always discarding partially-staged content. However if + it uses the file content type it MUST support the staging methods. + + + + + + + + + + This method stages the message, sending the message content to the recipient from + the octet offset specified in the Open-Ok method. + + + + + + + + + + + This method publishes a staged file message to a specific exchange. The file message + will be routed to queues as defined by the exchange configuration and distributed to + any active consumers when the transaction, if any, is committed. + + + + + + + + The client MUST provide a valid access ticket giving "write" access rights + to the access realm for the exchange. + + + + + + + Specifies the name of the exchange to publish to. The exchange name can be + empty, meaning the default exchange. If the exchange name is specified, and that + exchange does not exist, the server will raise a channel exception. + + + + + The server MUST accept a blank exchange name to mean the default exchange. + + + + + + If the exchange was declared as an internal exchange, the server MUST + respond with a reply code 403 (access refused) and raise a channel + exception. + + + + + + + + The exchange MAY refuse file content in which case it MUST respond with a + reply code 540 (not implemented) and raise a channel exception. + + + + + + + Specifies the routing key for the message. The routing key is used for routing + messages depending on the exchange configuration. + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue. If this flag is set, the server will return an unroutable message with a + Return method. If this flag is zero, the server silently drops the message. + + + + + The server SHOULD implement the mandatory flag. + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue consumer immediately. If this flag is set, the server will return an + undeliverable message with a Return method. If this flag is zero, the server + will queue the message, but with no guarantee that it will ever be consumed. + + + + + The server SHOULD implement the immediate flag. + + + + + + This is the staging identifier of the message to publish. The message must have + been staged. Note that a client can send the Publish method asynchronously + without waiting for staging to finish. + + + + + + + This method returns an undeliverable message that was published with the "immediate" + flag set, or an unroutable message published with the "mandatory" flag set. The + reply code and text provide information about the reason that the message was + undeliverable. + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + This method delivers a staged file message to the client, via a consumer. In the + asynchronous message delivery model, the client starts a consumer using the Consume + method, then the server responds with Deliver methods as and when messages arrive + for that consumer. + + + + + + The server SHOULD track the number of times a message has been delivered to + clients and when a message is redelivered a certain number of times - e.g. 5 + times - without being acknowledged, the server SHOULD consider the message to be + unprocessable (possibly causing client applications to abort), and move the + message to a dead letter queue. + + + + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + Specifies the routing key name specified when the message was published. + + + + + This is the staging identifier of the message to deliver. The message must have + been staged. Note that a server can send the Deliver method asynchronously + without waiting for staging to finish. + + + + + + + + + This method acknowledges one or more messages delivered via the Deliver method. The + client can ask to confirm a single message or a set of messages up to and including + a specific message. + + + + + + + + + If set to 1, the delivery tag is treated as "up to and including", so that the + client can acknowledge multiple messages with a single method. If set to zero, + the delivery tag refers to a single message. If the multiple field is 1, and the + delivery tag is zero, tells the server to acknowledge all outstanding messages. + + + + + The server MUST validate that a non-zero delivery-tag refers to an delivered + message, and raise a channel exception if this is not the case. + + + + + + + + + + This method allows a client to reject a message. It can be used to return + untreatable messages to their original queue. Note that file content is staged + before delivery, so the client will not use this method to interrupt delivery of a + large message. + + + + + The server SHOULD interpret this method as meaning that the client is unable to + process the message at this time. + + + + + + + + A client MUST NOT use this method as a means of selecting messages to process. A + rejected message MAY be discarded or dead-lettered, not necessarily passed to + another client. + + + + + + + + + + If this field is zero, the message will be discarded. If this bit is 1, the + server will attempt to requeue the message. + + + + + + The server MUST NOT deliver the message to the same client within the + context of the current channel. The recommended strategy is to attempt to + deliver the message to an alternative consumer, and if that is not possible, + to move the message to a dead-letter queue. The server MAY use more + sophisticated tracking to hold the message on the queue and redeliver it to + the same client at a later stage. + + + + + + + + + + + The stream class provides methods that support multimedia streaming. The stream class + uses the following semantics: one message is one packet of data; delivery is + unacknowledged and unreliable; the consumer can specify quality of service parameters + that the server can try to adhere to; lower-priority messages may be discarded in favour + of high priority messages. + + + + stream = C:QOS S:QOS-OK + / C:CONSUME S:CONSUME-OK + / C:CANCEL S:CANCEL-OK + / C:PUBLISH content + / S:RETURN + / S:DELIVER content + + + + + + + + The server SHOULD discard stream messages on a priority basis if the queue size + exceeds some configured limit. + + + + + + + The server MUST implement at least 2 priority levels for stream messages, where + priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement + up to 10 priority levels. + + + + + + The server MUST implement automatic acknowledgements on stream content. That is, as + soon as a message is delivered to a client via a Deliver method, the server must + remove it from the queue. + + + + + + + + + + + + + + + + This method requests a specific quality of service. The QoS can be specified for the + current channel or for all channels on the connection. The particular properties and + semantics of a qos method always depend on the content class semantics. Though the + qos method could in principle apply to both peers, it is currently meaningful only + for the server. + + + + + + + + + The client can request that messages be sent in advance so that when the client + finishes processing a message, the following message is already held locally, + rather than needing to be sent down the channel. Prefetching gives a performance + improvement. This field specifies the prefetch window size in octets. May be set + to zero, meaning "no specific limit". Note that other prefetch limits may still + apply. + + + + + + Specifies a prefetch window in terms of whole messages. This field may be used + in combination with the prefetch-size field; a message will only be sent in + advance if both prefetch windows (and those at the channel and connection level) + allow it. + + + + + + Specifies a desired transfer rate in octets per second. This is usually + determined by the application that uses the streaming data. A value of zero + means "no limit", i.e. as rapidly as possible. + + + + + + The server MAY ignore the prefetch values and consume rates, depending on + the type of stream and the ability of the server to queue and/or reply it. + The server MAY drop low-priority messages in favour of high-priority + messages. + + + + + + + By default the QoS settings apply to the current channel only. If this field is + set, they are applied to the entire connection. + + + + + + + This method tells the client that the requested QoS levels could be handled by the + server. The requested QoS applies to all active consumers until a new QoS is + defined. + + + + + + + + + + This method asks the server to start a "consumer", which is a transient request for + messages from a specific queue. Consumers last as long as the channel 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 channels to select different + streaming resolutions. AMQP makes no provision for filtering and/or transforming + streams except on the basis of priority-based selective delivery of individual + messages. + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + + + + + Specifies the identifier for the consumer. The consumer tag is local to a + connection, so two clients can use the same consumer tags. If this field is + empty the server will generate a unique tag. + + + + + + The tag MUST NOT refer to an existing consumer. If the client attempts to + create two consumers with the same non-empty tag the server MUST raise a + connection exception with reply code 530 (not allowed). + + + + + + + + + Request exclusive consumer access, meaning only this consumer can access the + queue. + + + + + + + If the server cannot grant exclusive access to the queue when asked, - + because there are other consumers active - it MUST raise a channel exception + with return code 405 (resource locked). + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + A set of filters for the consume. The syntax and semantics + of these filters depends on the providers implementation. + + + + + + + This method provides the client with a consumer tag which it may use in methods that + work with the consumer. + + + + + + Holds the consumer tag specified by the client or provided by the server. + + + + + + + + This method cancels a consumer. Since message delivery is asynchronous the client + may continue to receive messages for a short while after cancelling a consumer. It + may process or discard these as appropriate. + + + + + + + + + + + If set, the server will not respond to the method. The client should not wait + for a reply method. If the server could not complete the method it will raise a + channel or connection exception. + + + + + + This method confirms that the cancellation was completed. + + + + + + + + + + + This method publishes a message to a specific exchange. The message will be routed + to queues as defined by the exchange configuration and distributed to any active + consumers as appropriate. + + + + + + + + The client MUST provide a valid access ticket giving "write" access rights + to the access realm for the exchange. + + + + + + + Specifies the name of the exchange to publish to. The exchange name can be + empty, meaning the default exchange. If the exchange name is specified, and that + exchange does not exist, the server will raise a channel exception. + + + + + The server MUST accept a blank exchange name to mean the default exchange. + + + + + + If the exchange was declared as an internal exchange, the server MUST + respond with a reply code 403 (access refused) and raise a channel + exception. + + + + + + The exchange MAY refuse stream content in which case it MUST respond with a + reply code 540 (not implemented) and raise a channel exception. + + + + + + + Specifies the routing key for the message. The routing key is used for routing + messages depending on the exchange configuration. + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue. If this flag is set, the server will return an unroutable message with a + Return method. If this flag is zero, the server silently drops the message. + + + + + The server SHOULD implement the mandatory flag. + + + + + + This flag tells the server how to react if the message cannot be routed to a + queue consumer immediately. If this flag is set, the server will return an + undeliverable message with a Return method. If this flag is zero, the server + will queue the message, but with no guarantee that it will ever be consumed. + + + + + The server SHOULD implement the immediate flag. + + + + + + + This method returns an undeliverable message that was published with the "immediate" + flag set, or an unroutable message published with the "mandatory" flag set. The + reply code and text provide information about the reason that the message was + undeliverable. + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + Specifies the routing key name specified when the message was published. + + + + + + + + This method delivers a message to the client, via a consumer. In the asynchronous + message delivery model, the client starts a consumer using the Consume method, then + the server responds with Deliver methods as and when messages arrive for that + consumer. + + + + + + + + + + + Specifies the name of the exchange that the message was originally published to. + + + + + + Specifies the name of the queue that the message came from. Note that a single + channel can start many consumers on different queues. + + + + + + + + + + + Standard transactions provide so-called "1.5 phase commit". We can ensure that work is + never lost, but there is a chance of confirmations being lost, so that messages may be + resent. Applications that use standard transactions must be able to detect and ignore + duplicate messages. + + + + + + + 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. + + + + + tx = C:SELECT S:SELECT-OK + / C:COMMIT S:COMMIT-OK + / C:ROLLBACK S:ROLLBACK-OK + + + + + + + + + + This method sets the channel to use standard transactions. The client must use this + method at least once on a channel before using the Commit or Rollback methods. + + + + + + + + This method confirms to the client that the channel was successfully set to use + standard transactions. + + + + + + + + + This method commits all messages published and acknowledged in the current + transaction. A new transaction starts immediately after a commit. + + + + + + + + This method confirms to the client that the commit succeeded. Note that if a commit + fails, the server raises a channel exception. + + + + + + + + + This method abandons all messages published and acknowledged in the current + transaction. A new transaction starts immediately after a rollback. + + + + + + + + This method confirms to the client that the rollback succeeded. Note that if an + rollback fails, the server raises a channel exception. + + + + + + + + + + Distributed transactions provide so-called "2-phase commit". The AMQP distributed + transaction model supports the X-Open XA architecture and other distributed transaction + implementations. The Dtx class assumes that the server has a private communications + channel (not AMQP) to a distributed transaction coordinator. + + + + dtx = C:SELECT S:SELECT-OK + C:START S:START-OK + + + + + + + + + + This method sets the channel to use distributed transactions. The client must use + this method at least once on a channel before using the Start method. + + + + + + + + This method confirms to the client that the channel was successfully set to use + distributed transactions. + + + + + + + + + This method starts a new distributed transaction. This must be the first method on a + new channel that uses the distributed transaction mode, before any methods that + publish or consume messages. + + + + + + The distributed transaction key. This identifies the transaction so that the + AMQP server can coordinate with the distributed transaction coordinator. + + + + + + + + This method confirms to the client that the transaction started. Note that if a + start fails, the server raises a channel exception. + + + + + + + + + + The tunnel methods are used to send blocks of binary data - which can be serialised AMQP + methods or other protocol frames - between AMQP peers. + + + + tunnel = C:REQUEST + / S:REQUEST + + + + + + + + + + + + + + + + This method tunnels a block of binary data, which can be an encoded + AMQP method or other data. The binary data is sent as the content for + the Tunnel.Request method. + + + + + This field table holds arbitrary meta-data that the sender needs to + pass to the recipient. + + + + + + + + + + [WORK IN PROGRESS] The message class provides methods that support an industry-standard messaging model. + + + + message = C:QOS S:OK + / C:CONSUME S:OK + / C:CANCEL S:OK + / C:TRANSFER ( S:OK / S:REJECT ) + / S:TRANSFER ( C:OK / C:REJECT ) + / C:GET ( S:OK / S:EMPTY ) + / C:RECOVER S:OK + / C:OPEN S:OK + / S:OPEN C:OK + / C:APPEND S:OK + / S:APPEND C:OK + / C:CLOSE S:OK + / S:CLOSE C:OK + / C:CHECKPOINT S:OK + / S:CHECKPOINT C:OK + / C:RESUME S:OFFSET + / S:RESUME C:OFFSET + + + + + + + + The server SHOULD respect the persistent property of messages + and SHOULD make a best-effort to hold persistent mess ages on + a reliable storage mechanism. + + + Send a persistent message to queue, stop server, restart + server and then verify whether message is still present. + Assumes that queues are durable. Persistence without durable + queues makes no sense. + + + + + + The server MUST NOT discard a persistent message in case of a + queue overflow. + + + Create a queue overflow situation with persistent messages and + verify that messages do not get lost (presumably the server + will write them to disk). + + + + + + The server MAY use the Channel.Flow method to slow or stop a + message publisher when necessary. + + + Create a queue overflow situation with non-persistent messages + and verify whether the server responds with Channel.Flow or + not. Repeat with persistent messages. + + + + + + The server MAY overflow non-persistent messages to persistent + storage. + + + + + + The server MAY discard or dead-letter non-persistent messages + on a priority basis if the queue size exceeds some configured + limit. + + + + + + The server MUST implement at least 2 priority levels for + messages, where priorities 0-4 and 5-9 are treated as two + distinct levels. + + + Send a number of priority 0 messages to a queue. Send one + priority 9 message. Consume messages from the queue and verify + that the first message received was priority 9. + + + + + + The server MAY implement up to 10 priority levels. + + + Send a number of messages with mixed priorities to a queue, so + that all priority values from 0 to 9 are exercised. A good + scenario would be ten messages in low-to-high priority. + Consume from queue and verify how many priority levels emerge. + + + + + + The server MUST deliver messages of the same priority in order + irrespective of their individual persistence. + + + Send a set of messages with the same priority but different + persistence settings to a queue. Consume and verify that + messages arrive in same order as originally published. + + + + + + The server MUST support automatic acknowledgements on + messages, i.e. consumers with the no-ack field set to FALSE. + + + Create a queue and a consumer using automatic + acknowledgements. Publish a set of messages to the queue. + Consume the messages and verify that all messages are + received. + + + + + + The server MUST support explicit acknowledgements on messages, + i.e. consumers with the no-ack field set to TRUE. + + + Create a queue and a consumer using explicit acknowledgements. + Publish a set of messages to the queue. Consume the messages + but acknowledge only half of them. Disconnect and reconnect, + and consume from the queue. Verify that the remaining messages + are received. + + + + + + + + [WORK IN PROGRESS] This method transfers a message between two peers. When a + client uses this method to publish a message to a broker, the + destination identifies a specific exchange. The message will + then be routed to queues as defined by the exchange + configuration and distributed to any active consumers when the + transaction, if any, is committed. + + In the asynchronous message delivery model, the client starts + a consumer using the Consume method and passing in a + destination, then the broker responds with transfer methods to + the specified destination as and when messages arrive for that + consumer. + + If synchronous message delivery is required, the client may + issue a get request which on success causes a single message + to be transferred to the specified destination. + + Message acknowledgement is signalled by the return result of + this method. + + + + + The recipient MUST NOT return ok before the message has been + processed as defined by the QoS settings. + + + + + + + + + + + + The client MUST provide a valid access ticket giving "write" access rights + to the access realm for the exchange. + + + + + + + Specifies the destination to which the message is to be + transferred. The destination can be empty, meaning the + default exchange or consumer. If the destination is + specified, and that exchange or consumer does not exist, the + peer must raise a channel exception. + + + + + The server MUST accept a blank destination to mean the + default exchange. + + + + + + If the destination refers to an internal exchange, the + server MUST raise a channel exception with a reply code + 403 (access refused). + + + + + + A destination MAY refuse message content in which case it + MUST raise a channel exception with reply code 540 (not + implemented). + + + + + + + + + This 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 reject the message. 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. + + + + + + + If this is set to a non zero value then a message expiration + time will be computed based on the current time plus this + value. Messages that live longer than their expiration time + will be discarded (or dead lettered). + + + + If a message is transfered between brokers before delivery + to a final consumer the ttl should be decremented before + peer to peer transfer and both timestamp and expiration + should be cleared. + + + + + + + + + Set on arrival by the broker. + + + + + + The expiration header assigned by the broker. After + receiving the message the broker sets expiration to the sum + of the ttl specified in the publish method and the current + time. (ttl = expiration - timestamp) + + + + + + + + + + + + + + + + + + + + + + + + [WORK IN PROGRESS] This method asks the server to start a "consumer", which is a transient request for + messages from a specific queue. Consumers last as long as the channel they were + created on, or until the client cancels them. + + + + + The server SHOULD support at least 16 consumers per queue, and ideally, impose + no limit except as defined by available resources. + + + Create a queue and create consumers on that queue until the server closes the + connection. Verify that the number of consumers created was at least sixteen + and report the total number. + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + Attempt to create a consumer with an invalid (non-zero) access ticket. + + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + If the queue name is empty the client MUST have previously declared a + queue using this channel. + + + Attempt to create a consumer with an empty queue name and no previously + declared queue on the channel. + + + + + + + Specifies the destination for the consumer. The destination is local to a + connection, so two clients can use the same destination. + + + + The client MUST NOT specify a destination that refers to an existing consumer. + + + Attempt to create two consumers with the same non-empty destination. + + + + + The destination is valid only within the channel from which the + consumer was created. I.e. a client MUST NOT create a consumer in one + channel and then use it in another. + + + Attempt to create a consumer in one channel, then use in another channel, + in which consumers have also been created (to test that the server uses + unique destinations). + + + + + + + + + + + Request exclusive consumer access, meaning only this consumer can access the + queue. + + + + + The client MAY NOT gain exclusive access to a queue that already has + active consumers. + + + Open two connections to a server, and in one connection create a shared + (non-exclusive) queue and then consume from the queue. In the second + connection attempt to consume from the same queue using the exclusive + option. + + + + + + + A set of filters for the consume. The syntax and semantics + of these filters depends on the providers implementation. + + + + + + + + + [WORK IN PROGRESS] This method cancels a consumer. This does not affect already delivered + messages, but it does mean the server will not send any more messages for + that consumer. The client may receive an arbitrary number of messages in + between sending the cancel method and receiving the cancel-ok reply. + + + + + If the queue does not exist the server MUST ignore the cancel method, so + long as the consumer tag is valid for that channel. + + + + + + + + + + + + + + [WORK IN PROGRESS] This method provides a direct access to the messages in a queue using a synchronous + dialogue that is designed for specific types of application where synchronous + functionality is more important than performance. + + + + + + + + + + The client MUST provide a valid access ticket giving "read" access rights to + the realm for the queue. + + + + + + Specifies the name of the queue to consume from. If the queue name is null, + refers to the current queue for the channel, which is the last declared queue. + + + + If the client did not previously declare a queue, and the queue name in this + method is empty, the server MUST raise a connection exception with reply + code 530 (not allowed). + + + + + + + On normal completion of the get request (i.e. a response of + ok). A message will be transferred to the supplied destination. + + + + + + + + + + + [WORK IN PROGRESS] This method asks the broker to redeliver all unacknowledged + messages on a specified channel. Zero or more messages may be + redelivered. This method is only allowed on non-transacted + channels. + + + + + The server MUST set the redelivered flag on all messages + that are resent. + + + + + + The server MUST raise a channel exception if this is called + on a transacted channel. + + + + + + + + + If this field is zero, the message will be redelivered to + the original recipient. If this bit is 1, the server will + attempt to requeue the message, potentially then delivering + it to an alternative subscriber. + + + + + + + + + [WORK IN PROGRESS] This method creates a reference. A references provides a means + to send a message body into a temporary area at the recipient + end and then deliver the message by referring to this + temporary area. This is how the protocol handles large message + transfers. + + The scope of a ref is defined to be between calls to + open (or resume) and close. Between these points it is valid + for a ref to be used from any content data type, and so the + receiver must hold onto its contents. Should the channel be + closed when a ref is still in scope, the receiver may discard + its contents (unless it is checkpointed). A ref that is in + scope is considered open. + + + + + + + + + + The recipient MUST generate an error if the reference is + currently open (in scope). + + + + + + + + + + [WORK IN PROGRESS] This method signals the recipient that no more data will be + appended to the reference. + + + + + A recipient CANNOT acknowledge a message until its reference + is closed (not in scope). + + + + + + + + + + + The recipient MUST generate an error if the reference was + not previously open (in scope). + + + + + + + + + + [WORK IN PROGRESS] This method appends data to a reference. + + + + + + + + + + The recipient MUST generate an error if the reference is + not open (not in scope). + + + + + + + + + + + [WORK IN PROGRESS] This method provides a means to checkpoint large message + transfer. The sender may ask the recipient to checkpoint the + contents of a reference using the supplied identifier. The + sender may then resume the transfer at a later point. It is at + the discretion of the recipient how much data to save with the + checkpoint, and the sender MUST honour the offset returned by + the resume method. + + + + + + + + + + The recipient MUST generate an error if the reference is + not open (not in scope). + + + + + + This is the checkpoint identifier. This is an arbitrary + string chosen by the sender. For checkpointing to work + correctly the sender must use the same checkpoint identifier + when resuming the message. A good choice for the checkpoint + identifier would be the SHA1 hash of the message properties + data (including the original filename, revised time, etc.). + + + + + + + + + [WORK IN PROGRESS] This method resumes a reference from the last checkpoint. A + reference is considered to be open (in scope) after a resume + even though it will not have been opened via the open method + during this session. + + + + + + + + + + The recipient MUST generate an error if the reference is + currently open (in scope). + + + + + + + + + + + [WORK IN PROGRESS] This method requests a specific quality of service. The QoS can be specified for the + current channel or for all channels on the connection. The particular properties and + semantics of a qos method always depend on the content class semantics. Though the + qos method could in principle apply to both peers, it is currently meaningful only + for the server. + + + + + + + + The client can request that messages be sent in advance so that when the client + finishes processing a message, the following message is already held locally, + rather than needing to be sent down the channel. Prefetching gives a performance + improvement. This field specifies the prefetch window size in octets. The server + will send a message in advance if it is equal to or smaller in size than the + available prefetch size (and also falls into other prefetch limits). May be set + to zero, meaning "no specific limit", although other prefetch limits may still + apply. The prefetch-size is ignored if the no-ack option is set. + + + + The server MUST ignore this setting when the client is not processing any + messages - i.e. the prefetch size does not limit the transfer of single + messages to a client, only the sending in advance of more messages while + the client still has one or more unacknowledged messages. + + + Define a QoS prefetch-size limit and send a single message that exceeds + that limit. Verify that the message arrives correctly. + + + + + + + Specifies a prefetch window in terms of whole messages. This field may be used + in combination with the prefetch-size field; a message will only be sent in + advance if both prefetch windows (and those at the channel and connection level) + allow it. The prefetch-count is ignored if the no-ack option is set. + + + + The server may send less data in advance than allowed by the client's + specified prefetch windows but it MUST NOT send more. + + + Define a QoS prefetch-size limit and a prefetch-count limit greater than + one. Send multiple messages that exceed the prefetch size. Verify that + no more than one message arrives at once. + + + + + + + By default the QoS settings apply to the current channel only. If this field is + set, they are applied to the entire connection. + + + + + + + + + + [WORK IN PROGRESS] Signals the normal completion of a method. + + + + + + + + [WORK IN PROGRESS] Signals that a queue does not contain any messages. + + + + + + + + [WORK IN PROGRESS] This response rejects a message. A message may be rejected for + a number of reasons. + + + + + + + + + + [WORK IN PROGRESS] Returns the data offset into a reference body. + + + + + + + + + diff --git a/specs/cluster.0-8.xml b/specs/cluster.0-8.xml new file mode 100644 index 0000000000..09e8ca0787 --- /dev/null +++ b/specs/cluster.0-8.xml @@ -0,0 +1,59 @@ + + + + + + + + + An extension that allows brokers to communicate in order to + provide a clustered service to clients. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/specs/cluster.0-9.xml b/specs/cluster.0-9.xml new file mode 100644 index 0000000000..142e6c9380 --- /dev/null +++ b/specs/cluster.0-9.xml @@ -0,0 +1,59 @@ + + + + + + + + + An extension that allows brokers to communicate in order to + provide a clustered service to clients. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.1