From 5a99ae4cd298d69372c4f162b88ff1be3012c422 Mon Sep 17 00:00:00 2001
From: Nilstrieb <48135649+Nilstrieb@users.noreply.github.com>
Date: Mon, 14 Feb 2022 21:38:15 +0100
Subject: [PATCH] used full spec
---
.gitignore | 1 -
amqp_codegen/amqp-0-9-1-bsd.xml | 468 ----
amqp_codegen/amqp0-9-1.xml | 2845 +++++++++++++++++++++++
amqp_codegen/src/main.rs | 77 +-
amqp_transport/src/classes/generated.rs | 512 +++-
5 files changed, 3329 insertions(+), 574 deletions(-)
delete mode 100644 amqp_codegen/amqp-0-9-1-bsd.xml
create mode 100644 amqp_codegen/amqp0-9-1.xml
diff --git a/.gitignore b/.gitignore
index a609fc2..3a8cabc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,2 @@
/target
.idea
-amqp0-9-1.xml
\ No newline at end of file
diff --git a/amqp_codegen/amqp-0-9-1-bsd.xml b/amqp_codegen/amqp-0-9-1-bsd.xml
deleted file mode 100644
index f70584f..0000000
--- a/amqp_codegen/amqp-0-9-1-bsd.xml
+++ /dev/null
@@ -1,468 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/amqp_codegen/amqp0-9-1.xml b/amqp_codegen/amqp0-9-1.xml
new file mode 100644
index 0000000..42fe855
--- /dev/null
+++ b/amqp_codegen/amqp0-9-1.xml
@@ -0,0 +1,2845 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 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 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 sender sent a malformed frame that the recipient could not decode.
+ This strongly implies a programming error in the sending peer.
+
+
+
+
+
+ The sender sent a frame that contained illegal values for one or more
+ fields. This strongly implies a programming error in the sending peer.
+
+
+
+
+
+ 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 peer sent a frame that was not expected, usually in the context of
+ a content header and body. This strongly indicates a fault in the peer's
+ content processing.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ Identifier for the consumer, valid within the current channel.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ 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
+ assumes the delivery will succeed and immediately dequeues it. This
+ functionality may increase performance but at the cost of reliability.
+ Messages can get lost if a client dies before they are delivered to the
+ application.
+
+
+
+
+
+ If the no-local field is set the server will not send messages to the connection that
+ published them.
+
+
+
+
+
+ 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.
+
+
+
+
+
+ Unconstrained.
+
+
+
+
+
+
+
+ This table provides a set of peer properties, used for identification, debugging,
+ and general information.
+
+
+
+
+
+ The queue name identifies the queue within the vhost. In methods where the queue
+ name may be blank, and that has no specific significance, this refers to the
+ 'current' queue for the channel, meaning the last queue that the client declared
+ on the channel. If the client did not declare a queue, and the method needs a
+ queue name, this will result in a 502 (syntax error) channel exception.
+
+
+
+
+
+
+
+ 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.
+
+
+ Declare 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 number of messages in the queue, which will be zero for newly-declared
+ queues. This is the number of messages present in the queue, and committed
+ if the channel on which they were published is transacted, that are not
+ waiting acknowledgement.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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
+ 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 respond with a valid protocol header and then close the socket
+ connection.
+
+
+ The client sends a protocol header containing an invalid protocol name.
+ The server MUST respond by sending a valid protocol header and then 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. 2.0. The server must respond with a protocol header
+ indicating its supported protocol version, e.g. 1.0.
+
+
+
+
+ If the client cannot handle the protocol version suggested by the server
+ it MUST close the socket connection without sending any further data.
+
+
+ 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 without sending any further data.
+
+
+
+
+
+
+
+
+ The major version number can take any value from 0 to 99 as defined in the
+ AMQP specification.
+
+
+
+
+
+ The minor version number can take any value from 0 to 99 as defined in the
+ AMQP specification.
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ Specifies highest channel number that the server permits. Usable channel numbers
+ are in the range 1..channel-max. Zero indicates no specified limit.
+
+
+
+
+
+ The largest frame size that the server proposes for the connection, including
+ frame header and end-byte. 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.
+
+
+
+
+
+
+
+
+
+
+
+ This method signals to the client that the connection is ready for use.
+
+
+
+
+
+
+
+
+
+
+ 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 methods except Close and Close-OK MUST
+ be discarded. The response to receiving a Close after sending Close must be to
+ send Close-Ok.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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
+ use-channel =C:FLOW S:FLOW-OK
+ / S:FLOW C:FLOW-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.
+
+
+
+
+
+
+
+
+
+
+ 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 sent by
+ a consumer. 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. It does
+ not affect contents returned by Basic.Get-Ok methods.
+
+
+
+
+ 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 server.
+
+
+
+
+
+
+
+
+
+
+ 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 methods except Close and Close-OK MUST
+ be discarded. The response to receiving a Close after sending Close must be to
+ send Close-Ok.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+ Exchanges match and distribute messages across queues. Exchanges can be configured in
+ the server or declared 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 declares 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 declares as many exchanges as it can until the server reports
+ an error; the number of exchanges successfully declared must be at least
+ sixteen.
+
+
+
+
+
+
+
+
+
+
+
+
+ Exchange names starting with "amq." are reserved for pre-declared and
+ standardised exchanges. The client MAY declare an exchange starting with
+ "amq." if the passive option is set, or the exchange already exists.
+
+
+ The client attempts to declare a non-existing exchange starting with
+ "amq." and with the passive option set to zero.
+
+
+
+
+ The exchange name consists of a non-empty sequence of these characters:
+ letters, digits, hyphen, underscore, period, or colon.
+
+
+ The client attempts to declare an exchange with an illegal name.
+
+
+
+
+
+
+
+ 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 declare an exchange with a type that the
+ server does not support.
+
+
+ TODO.
+
+
+
+
+
+
+ If set, the server will reply with Declare-Ok if the exchange already
+ exists with the same name, and raise an error if not. The client can
+ use this to check whether an exchange exists without modifying the
+ server state. When set, all other method fields except name and no-wait
+ are ignored. A declare with both passive and no-wait has no effect.
+ Arguments are compared for semantic equivalence.
+
+
+
+ If set, and the exchange does not already exist, the server MUST
+ raise a channel exception with reply code 404 (not found).
+
+
+ TODO.
+
+
+
+
+ If not set and the exchange exists, the server MUST check that the
+ existing exchange has the same values for type, durable, and arguments
+ fields. The server MUST respond with Declare-Ok if the requested
+ exchange matches these fields, and MUST raise a channel exception if
+ not.
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+ A set of arguments for the declaration. The syntax and semantics of these
+ arguments depends on the server implementation.
+
+
+
+
+
+
+ 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 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.
+
+
+
+ The server MUST NOT delete an exchange that has bindings on it, if the if-unused
+ field is true.
+
+
+ The client declares an exchange, binds a queue to it, then tries to delete it
+ setting if-unused to true.
+
+
+
+
+
+
+
+
+ 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:UNBIND S:UNBIND-OK
+ / C:PURGE S:PURGE-OK
+ / C:DELETE S:DELETE-OK
+
+
+
+
+
+
+
+
+
+ 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-declared queue to the
+ default exchange, which is an exchange of type 'direct' and use the queue
+ name as the routing key.
+
+
+ Client declares 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 declare as many queues as it can until the server reports
+ an error. The resulting count must at least be 256.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 declare 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 queues. The client MAY declare a queue starting with
+ "amq." if the passive option is set, or the queue already exists.
+
+
+ The client attempts to declare a non-existing queue starting with
+ "amq." and with the passive option set to zero.
+
+
+
+
+ The queue name can be empty, or a sequence of these characters:
+ letters, digits, hyphen, underscore, period, or colon.
+
+
+ The client attempts to declare a queue with an illegal name.
+
+
+
+
+
+
+ If set, the server will reply with Declare-Ok if the queue already
+ exists with the same name, and raise an error if not. The client can
+ use this to check whether a queue exists without modifying the
+ server state. When set, all other method fields except name and no-wait
+ are ignored. A declare with both passive and no-wait has no effect.
+ Arguments are compared for semantic equivalence.
+
+
+
+ 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 not set and the queue exists, the server MUST check that the
+ existing queue has the same values for durable, exclusive, auto-delete,
+ and arguments fields. The server MUST respond with Declare-Ok if the
+ requested queue matches these fields, and MUST raise a channel exception
+ if not.
+
+
+ TODO.
+
+
+
+
+
+
+ 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.
+
+
+ Client declares 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 declares two named queues, one durable and one transient.
+
+
+
+
+
+
+ Exclusive queues may only be accessed by the current connection, and are
+ deleted when that connection closes. Passive declaration of an exclusive
+ queue by other connections are not allowed.
+
+
+
+
+ The server MUST support both exclusive (private) and non-exclusive (shared)
+ queues.
+
+
+ A client declares two named queues, one exclusive and one non-exclusive.
+
+
+
+
+
+ The client MAY NOT attempt to use a queue that was declared as exclusive
+ by another still-open connection.
+
+
+ One client declares an exclusive queue. A second client on a different
+ connection attempts to declare, bind, consume, purge, delete, or declare
+ a queue of the same name.
+
+
+
+
+
+
+ If set, the queue is deleted when all consumers have finished using it. The 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. Applications can
+ explicitly delete auto-delete queues using the Delete method as normal.
+
+
+
+
+ The server MUST ignore the auto-delete field if the queue already exists.
+
+
+ Client declares two named queues, one as auto-delete and one explicit-delete.
+ Client then attempts to declare the two queues using the same names again,
+ but reversing the value of the auto-delete field in each case. Verify that the
+ queues still exist with the original auto-delete flag values.
+
+
+
+
+
+
+
+
+ A set of arguments for the declaration. The syntax and semantics of these
+ arguments depends on the server implementation.
+
+
+
+
+
+
+ This 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 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).
+
+
+
+
+
+ A server MUST not deliver the same message more than once to a queue, even if
+ the queue has multiple bindings that match the message.
+
+
+ A client declares a named queue and binds it using multiple bindings to the
+ amq.topic exchange. The client then publishes a message that matches all its
+ bindings.
+
+
+
+
+
+ The server MUST allow a durable queue to bind to a transient exchange.
+
+
+ A client declares a transient exchange. The client then declares a named durable
+ queue and then attempts to bind the transient exchange to the durable queue.
+
+
+
+
+
+ Bindings of durable queues to durable exchanges are automatically durable
+ and the server MUST restore such bindings after a server restart.
+
+
+ A server declares a named durable queue and binds it to a durable exchange. The
+ server is restarted. The client then attempts to use the queue/exchange combination.
+
+
+
+
+
+ The server SHOULD support at least 4 bindings per queue, and ideally, impose no
+ limit except as defined by available resources.
+
+
+ A client declares a named queue and attempts to bind it to 4 different
+ exchanges.
+
+
+
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to bind.
+
+
+ The client MUST either specify a queue name or have previously declared a
+ queue on the same channel
+
+
+ The client opens a channel and attempts to bind an unnamed queue.
+
+
+
+
+ The client MUST NOT attempt to bind a queue that does not exist.
+
+
+ The client attempts to bind a non-existent queue.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+ The server MUST accept a blank exchange name to mean the default exchange.
+
+
+ The client declares a queue and binds it to a blank exchange name.
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to unbind.
+
+
+ The client MUST either specify a queue name or have previously declared a
+ queue on the same channel
+
+
+ The client opens a channel and attempts to unbind an unnamed queue.
+
+
+
+
+ The client MUST NOT attempt to unbind a queue that does not exist.
+
+
+ The client attempts to unbind a non-existent queue.
+
+
+
+
+
+ The name of the exchange to unbind from.
+
+
+ The client MUST NOT attempt to unbind a queue from an exchange that
+ does not exist.
+
+
+ The client attempts to unbind a queue from a non-existent exchange.
+
+
+
+
+ The server MUST accept a blank exchange name to mean the default exchange.
+
+
+ The client declares a queue and binds it to a blank exchange name.
+
+
+
+
+
+ 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 which are not awaiting
+ acknowledgment.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to purge.
+
+
+ The client MUST either specify a queue name or have previously declared a
+ queue on the same channel
+
+
+ The client opens a channel and attempts to purge an unnamed queue.
+
+
+
+
+ The client MUST NOT attempt to purge a queue that does not exist.
+
+
+ The client attempts to purge a non-existent queue.
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to delete.
+
+
+ The client MUST either specify a queue name or have previously declared a
+ queue on the same channel
+
+
+ The client opens a channel and attempts to delete an unnamed queue.
+
+
+
+
+ The client MUST NOT attempt to delete a queue that does not exist.
+
+
+ The client attempts to delete a non-existent queue.
+
+
+
+
+
+
+ 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 NOT delete a queue that has consumers on it, if the if-unused
+ field is true.
+
+
+ The client declares a queue, and consumes from it, then tries to delete it
+ setting if-unused to true.
+
+
+
+
+
+
+ If set, the server will only delete the queue if it has no messages.
+
+
+
+ The server MUST NOT delete a queue that has messages on it, if the
+ if-empty field is true.
+
+
+ The client declares a queue, binds it and publishes some messages into it,
+ then tries to delete it setting if-empty to true.
+
+
+
+
+
+
+
+
+ This method confirms the deletion of a queue.
+
+
+
+
+ Reports the number of messages deleted.
+
+
+
+
+
+
+
+
+ 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
+ / C:RECOVER-ASYNC
+ / C:RECOVER S:RECOVER-OK
+
+
+
+
+
+
+
+ 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.
+
+
+ Declare 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.
+
+
+ Declare 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 un-acknowledged delivery of Basic content, i.e.
+ consumers with the no-ack field set to TRUE.
+
+
+
+
+
+ The server MUST support explicitly acknowledged delivery of Basic content,
+ i.e. consumers with the no-ack field set to FALSE.
+
+
+ Declare 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
+ declared 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.
+
+
+ Declare 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.
+
+
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to consume from.
+
+
+
+
+ Specifies the identifier for the consumer. The consumer tag is local to a
+ channel, 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, on the
+ same channel.
+
+
+
+
+ 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 declare 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 arguments for the consume. The syntax and semantics of these
+ arguments depends on the server 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.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ 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 client MUST NOT attempt to publish a content to an exchange that
+ does not exist.
+
+
+ The client attempts to publish a content to a non-existent exchange.
+
+
+
+
+ The server MUST accept a blank exchange name to mean the default exchange.
+
+
+ The client declares a queue and binds it to a blank exchange name.
+
+
+
+
+ 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. May be empty, meaning the default exchange.
+
+
+
+
+
+ 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.
+ May be empty, indicating the default exchange.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+ Specifies the name of the queue to get a message from.
+
+
+
+
+
+
+ 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 method tells the client that the queue has no messages available for the
+ client.
+
+
+
+
+
+
+
+
+
+
+ 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 a delivered
+ message, and raise a channel exception if this is not the case. On a transacted
+ channel, this check MUST be done immediately and not delayed until a Tx.Commit.
+ Specifically, a client MUST not acknowledge the same message more than once.
+
+
+ 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.
+
+
+
+
+
+ The client MUST NOT use this method as a means of selecting messages to process.
+
+
+ TODO.
+
+
+
+
+
+
+
+
+
+ If requeue is true, the server will attempt to requeue the message. If requeue
+ is false or the requeue attempt fails the messages are discarded or dead-lettered.
+
+
+
+
+ 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 server to redeliver all unacknowledged messages on a
+ specified channel. Zero or more messages may be redelivered. This method
+ is deprecated in favour of the synchronous Recover/Recover-Ok.
+
+
+
+ The server MUST set the redelivered flag on all messages that are resent.
+
+
+ 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.
+
+
+
+
+
+
+
+
+ This method asks the server to redeliver all unacknowledged messages on a
+ specified channel. Zero or more messages may be redelivered. This method
+ replaces the asynchronous Recover.
+
+
+
+ The server MUST set the redelivered flag on all messages that are resent.
+
+
+ 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.
+
+
+
+
+
+
+ This method acknowledges a Basic.Recover method.
+
+
+
+
+
+
+
+
+
+ The Tx class allows publish and ack operations to be batched into atomic
+ units of work. The intention is that all publish and ack requests issued
+ within a transaction will complete successfully or none of them will.
+ Servers SHOULD implement atomic transactions at least where all publish
+ or ack requests affect a single queue. Transactions that cover multiple
+ queues may be non-atomic, given that queues can be created and destroyed
+ asynchronously, and such events do not form part of any transaction.
+ Further, the behaviour of transactions with respect to the immediate and
+ mandatory flags on Basic.Publish methods is not defined.
+
+
+
+
+ Applications MUST NOT rely on the atomicity of transactions that
+ affect more than one queue.
+
+
+
+
+ Applications MUST NOT rely on the behaviour of transactions that
+ include messages published with the immediate option.
+
+
+
+
+ Applications MUST NOT rely on the behaviour of transactions that
+ include messages published with the mandatory option.
+
+
+
+
+ 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 message publications and acknowledgments performed in
+ the current transaction. A new transaction starts immediately after a commit.
+
+
+
+
+
+
+ The client MUST NOT use the Commit method on non-transacted channels.
+
+
+ The client opens a channel and then uses Tx.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 message publications and acknowledgments performed in
+ the current transaction. A new transaction starts immediately after a rollback.
+ Note that unacked messages will not be automatically redelivered by rollback;
+ if that is required an explicit recover call should be issued.
+
+
+
+
+
+
+ The client MUST NOT use the Rollback method on non-transacted channels.
+
+
+ The client opens a channel and then uses Tx.Rollback.
+
+
+
+
+
+
+ This method confirms to the client that the rollback succeeded. Note that if an
+ rollback fails, the server raises a channel exception.
+
+
+
+
+
+
diff --git a/amqp_codegen/src/main.rs b/amqp_codegen/src/main.rs
index 2e1cf04..5a8f103 100644
--- a/amqp_codegen/src/main.rs
+++ b/amqp_codegen/src/main.rs
@@ -1,14 +1,14 @@
mod parser;
-mod write;
mod random;
+mod write;
use crate::parser::codegen_parser;
+use crate::random::codegen_random;
use crate::write::codegen_write;
use heck::ToUpperCamelCase;
use std::fs;
use std::iter::Peekable;
use strong_xml::XmlRead;
-use crate::random::codegen_random;
#[derive(Debug, XmlRead)]
#[xml(tag = "amqp")]
@@ -26,8 +26,13 @@ struct Domain {
name: String,
#[xml(attr = "type")]
kind: String,
+ #[xml(attr = "label")]
+ label: Option,
#[xml(child = "assert")]
asserts: Vec,
+ #[xml(child = "doc")]
+ doc: Vec,
+
}
#[derive(Debug, XmlRead)]
@@ -48,12 +53,12 @@ struct Assert {
struct Class {
#[xml(attr = "name")]
name: String,
- #[xml(attr = "handler")]
- handler: String,
#[xml(attr = "index")]
index: u16,
#[xml(child = "method")]
methods: Vec,
+ #[xml(child = "doc")]
+ doc: Vec,
}
#[derive(Debug, XmlRead)]
@@ -65,6 +70,9 @@ struct Method {
fields: Vec,
#[xml(attr = "index")]
index: u16,
+ #[xml(child = "doc")]
+ doc: Vec,
+
}
#[derive(Debug, XmlRead)]
@@ -78,12 +86,31 @@ struct Field {
kind: Option,
#[xml(child = "assert")]
asserts: Vec,
+ #[xml(child = "doc")]
+ doc: Vec,
+
}
-fn main() {
- let content = fs::read_to_string("./amqp-0-9-1-bsd.xml").unwrap();
+#[derive(Debug, XmlRead)]
+#[xml(tag = "doc")]
+struct Doc {
+ #[xml(text)]
+ text: String,
+ #[xml(attr = "type")]
+ kind: Option,
+}
- let amqp = Amqp::from_str(&content).unwrap();
+
+fn main() {
+ let content = fs::read_to_string("./amqp0-9-1.xml").unwrap();
+
+ let amqp = match Amqp::from_str(&content) {
+ Ok(amqp) => amqp,
+ Err(err) => {
+ eprintln!("{err}");
+ std::process::exit(1);
+ }
+ };
codegen(&amqp);
}
@@ -100,9 +127,20 @@ fn codegen_domain_defs(amqp: &Amqp) {
for domain in &amqp.domains {
let invariants = invariants(domain.asserts.iter());
+ if let Some(label) = &domain.label {
+ println!("/// {label}");
+ }
+
if !invariants.is_empty() {
+ if domain.label.is_some() {
+ println!("///");
+ }
println!("/// {invariants}");
}
+ if !domain.doc.is_empty() {
+ println!("///");
+ doc_comment(&domain.doc, 0);
+ }
println!(
"pub type {} = {};\n",
domain.name.to_upper_camel_case(),
@@ -122,12 +160,12 @@ fn codegen_class_defs(amqp: &Amqp) {
for class in &amqp.classes {
let enum_name = class.name.to_upper_camel_case();
- println!("/// Index {}, handler = {}", class.index, class.handler);
+ doc_comment(&class.doc, 0);
println!("#[derive(Debug, Clone, PartialEq)]");
println!("pub enum {enum_name} {{");
for method in &class.methods {
let method_name = method.name.to_upper_camel_case();
- println!(" /// Index {}", method.index);
+ doc_comment(&method.doc, 4);
print!(" {method_name}");
if !method.fields.is_empty() {
println!(" {{");
@@ -137,6 +175,12 @@ fn codegen_class_defs(amqp: &Amqp) {
get_invariants_with_type(field_type(field), field.asserts.as_ref());
if !field_docs.is_empty() {
println!(" /// {field_docs}");
+ if !field.doc.is_empty() {
+ println!(" ///");
+ doc_comment(&field.doc, 8);
+ }
+ } else {
+ doc_comment(&field.doc, 8);
}
println!(" {field_name}: {field_type},");
}
@@ -234,3 +278,18 @@ fn invariants<'a>(asserts: impl Iterator- ) -> String {
.collect::>()
.join(", ")
}
+
+fn doc_comment(docs: &[Doc], indent: usize) {
+ for doc in docs {
+ if doc.kind == Some("grammar".to_string()) {
+ continue;
+ }
+ for line in doc.text.lines() {
+ let line = line.trim();
+ if !line.is_empty() {
+ let indent = " ".repeat(indent);
+ println!("{indent}/// {line}");
+ }
+ }
+ }
+}
diff --git a/amqp_transport/src/classes/generated.rs b/amqp_transport/src/classes/generated.rs
index f7d0713..8246c00 100644
--- a/amqp_transport/src/classes/generated.rs
+++ b/amqp_transport/src/classes/generated.rs
@@ -2,55 +2,125 @@
pub type ClassId = u16;
+/// consumer tag
+///
+/// Identifier for the consumer, valid within the current channel.
pub type ConsumerTag = String;
+/// server-assigned delivery tag
+///
+/// The server-assigned and channel-specific delivery tag
pub type DeliveryTag = u64;
+/// exchange name
+///
/// must be shorter than 127, must match `^[a-zA-Z0-9-_.:]*$`
+///
+/// The exchange name is a client-selected string that identifies the exchange for
+/// publish methods.
pub type ExchangeName = String;
pub type MethodId = u16;
+/// no acknowledgement needed
+///
+/// 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
+/// assumes the delivery will succeed and immediately dequeues it. This
+/// functionality may increase performance but at the cost of reliability.
+/// Messages can get lost if a client dies before they are delivered to the
+/// application.
pub type NoAck = bool;
+/// do not deliver own messages
+///
+/// If the no-local field is set the server will not send messages to the connection that
+/// published them.
pub type NoLocal = bool;
+/// do not send 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.
pub type NoWait = bool;
/// must not be null, must be shorter than 127
+///
+/// Unconstrained.
pub type Path = String;
+///
+/// This table provides a set of peer properties, used for identification, debugging,
+/// and general information.
pub type PeerProperties = super::Table;
+/// queue name
+///
/// must be shorter than 127, must match `^[a-zA-Z0-9-_.:]*$`
+///
+/// The queue name identifies the queue within the vhost. In methods where the queue
+/// name may be blank, and that has no specific significance, this refers to the
+/// 'current' queue for the channel, meaning the last queue that the client declared
+/// on the channel. If the client did not declare a queue, and the method needs a
+/// queue name, this will result in a 502 (syntax error) channel exception.
pub type QueueName = String;
+/// message is being redelivered
+///
+/// This indicates that the message has been previously delivered to this or
+/// another client.
pub type Redelivered = bool;
+/// number of messages in queue
+///
+/// The number of messages in the queue, which will be zero for newly-declared
+/// queues. This is the number of messages present in the queue, and committed
+/// if the channel on which they were published is transacted, that are not
+/// waiting acknowledgement.
pub type MessageCount = u32;
+/// reply code from server
+///
/// must not be null
+///
+/// The reply code. The AMQ reply codes are defined as constants at the start
+/// of this formal specification.
pub type ReplyCode = u16;
+/// localised reply text
+///
/// must not be null
+///
+/// The localised reply text. This text can be logged as an aid to resolving
+/// issues.
pub type ReplyText = String;
+/// single bit
pub type Bit = bool;
+/// single octet
pub type Octet = u8;
+/// 16-bit integer
pub type Short = u16;
+/// 32-bit integer
pub type Long = u32;
+/// 64-bit integer
pub type Longlong = u64;
+/// short string (max. 256 characters)
pub type Shortstr = String;
+/// long string
pub type Longstr = Vec;
+/// 64-bit timestamp
pub type Timestamp = u64;
+/// field table
pub type Table = super::Table;
#[derive(Debug, Clone, PartialEq)]
@@ -63,283 +133,557 @@ pub enum Class {
Tx(Tx),
}
-/// Index 10, handler = connection
+/// 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.
#[derive(Debug, Clone, PartialEq)]
pub enum Connection {
- /// Index 10
+ /// 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.
Start {
+ /// The major version number can take any value from 0 to 99 as defined in the
+ /// AMQP specification.
version_major: Octet,
+ /// The minor version number can take any value from 0 to 99 as defined in the
+ /// AMQP specification.
version_minor: Octet,
server_properties: PeerProperties,
/// must not be null
+ ///
+ /// A list of the security mechanisms that the server supports, delimited by spaces.
mechanisms: Longstr,
/// must not be null
+ ///
+ /// 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.
locales: Longstr,
},
- /// Index 11
+ /// This method selects a SASL security mechanism.
StartOk {
client_properties: PeerProperties,
/// must not be null
+ ///
+ /// A single security mechanisms selected by the client, which must be one of those
+ /// specified by the server.
mechanism: Shortstr,
/// must not be null
+ ///
+ /// A block of opaque data passed to the security mechanism. The contents of this
+ /// data are defined by the SASL security mechanism.
response: Longstr,
/// must not be null
+ ///
+ /// A single message locale selected by the client, which must be one of those
+ /// specified by the server.
locale: Shortstr,
},
- /// Index 20
- Secure { challenge: Longstr },
- /// Index 21
+ /// 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.
+ Secure {
+ /// Challenge information, a block of opaque binary data passed to the security
+ /// mechanism.
+ challenge: Longstr,
+ },
+ /// This method attempts to authenticate, passing a block of SASL data for the security
+ /// mechanism at the server side.
SecureOk {
/// must not be null
+ ///
+ /// A block of opaque data passed to the security mechanism. The contents of this
+ /// data are defined by the SASL security mechanism.
response: Longstr,
},
- /// Index 30
+ /// This method proposes a set of connection configuration values to the client. The
+ /// client can accept and/or adjust these.
Tune {
+ /// Specifies highest channel number that the server permits. Usable channel numbers
+ /// are in the range 1..channel-max. Zero indicates no specified limit.
channel_max: Short,
+ /// The largest frame size that the server proposes for the connection, including
+ /// frame header and end-byte. 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.
frame_max: Long,
+ /// The delay, in seconds, of the connection heartbeat that the server wants.
+ /// Zero means the server does not want a heartbeat.
heartbeat: Short,
},
- /// Index 31
+ /// This method sends the client's connection tuning parameters to the server.
+ /// Certain fields are negotiated, others provide capability information.
TuneOk {
/// must not be null, must be less than the tune field of the method channel-max
+ ///
+ /// The maximum total number of channels that the client will use per connection.
channel_max: Short,
+ /// 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.
frame_max: Long,
+ /// The delay, in seconds, of the connection heartbeat that the client wants. Zero
+ /// means the client does not want a heartbeat.
heartbeat: Short,
},
- /// Index 40
+ /// 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.
Open {
+ /// The name of the virtual host to work with.
virtual_host: Path,
reserved_1: Shortstr,
reserved_2: Bit,
},
- /// Index 41
+ /// This method signals to the client that the connection is ready for use.
OpenOk { reserved_1: Shortstr },
- /// Index 50
+ /// 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.
Close {
reply_code: ReplyCode,
reply_text: ReplyText,
+ /// When the close is provoked by a method exception, this is the class of the
+ /// method.
class_id: ClassId,
+ /// When the close is provoked by a method exception, this is the ID of the method.
method_id: MethodId,
},
- /// Index 51
+ /// 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.
CloseOk,
- /// Index 60
- Blocked { reason: Shortstr },
- /// Index 61
- Unblocked,
}
-/// Index 20, handler = channel
+/// The channel class provides methods for a client to establish a channel to a
+/// server and for both peers to operate the channel thereafter.
#[derive(Debug, Clone, PartialEq)]
pub enum Channel {
- /// Index 10
+ /// This method opens a channel to the server.
Open { reserved_1: Shortstr },
- /// Index 11
+ /// This method signals to the client that the channel is ready for use.
OpenOk { reserved_1: Longstr },
- /// Index 20
- Flow { active: Bit },
- /// Index 21
- FlowOk { active: Bit },
- /// Index 40
+ /// This method asks the peer to pause or restart the flow of content data sent by
+ /// a consumer. 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. It does
+ /// not affect contents returned by Basic.Get-Ok methods.
+ Flow {
+ /// If 1, the peer starts sending content frames. If 0, the peer stops sending
+ /// content frames.
+ active: Bit,
+ },
+ /// Confirms to the peer that a flow command was received and processed.
+ FlowOk {
+ /// 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.
+ active: Bit,
+ },
+ /// 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.
Close {
reply_code: ReplyCode,
reply_text: ReplyText,
+ /// When the close is provoked by a method exception, this is the class of the
+ /// method.
class_id: ClassId,
+ /// When the close is provoked by a method exception, this is the ID of the method.
method_id: MethodId,
},
- /// Index 41
+ /// This method confirms a Channel.Close method and tells the recipient that it is safe
+ /// to release resources for the channel.
CloseOk,
}
-/// Index 40, handler = channel
+/// Exchanges match and distribute messages across queues. Exchanges can be configured in
+/// the server or declared at runtime.
#[derive(Debug, Clone, PartialEq)]
pub enum Exchange {
- /// Index 10
+ /// 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.
Declare {
reserved_1: Short,
/// must not be null
exchange: ExchangeName,
+ /// 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.
r#type: Shortstr,
+ /// If set, the server will reply with Declare-Ok if the exchange already
+ /// exists with the same name, and raise an error if not. The client can
+ /// use this to check whether an exchange exists without modifying the
+ /// server state. When set, all other method fields except name and no-wait
+ /// are ignored. A declare with both passive and no-wait has no effect.
+ /// Arguments are compared for semantic equivalence.
passive: Bit,
+ /// 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.
durable: Bit,
reserved_2: Bit,
reserved_3: Bit,
no_wait: NoWait,
+ /// A set of arguments for the declaration. The syntax and semantics of these
+ /// arguments depends on the server implementation.
arguments: Table,
},
- /// Index 11
+ /// This method confirms a Declare method and confirms the name of the exchange,
+ /// essential for automatically-named exchanges.
DeclareOk,
- /// Index 20
+ /// This method deletes an exchange. When an exchange is deleted all queue bindings on
+ /// the exchange are cancelled.
Delete {
reserved_1: Short,
/// must not be null
exchange: ExchangeName,
+ /// 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_unused: Bit,
no_wait: NoWait,
},
- /// Index 21
+ /// This method confirms the deletion of an exchange.
DeleteOk,
}
-/// Index 50, handler = channel
+/// 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.
#[derive(Debug, Clone, PartialEq)]
pub enum Queue {
- /// Index 10
+ /// 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.
Declare {
reserved_1: Short,
queue: QueueName,
+ /// If set, the server will reply with Declare-Ok if the queue already
+ /// exists with the same name, and raise an error if not. The client can
+ /// use this to check whether a queue exists without modifying the
+ /// server state. When set, all other method fields except name and no-wait
+ /// are ignored. A declare with both passive and no-wait has no effect.
+ /// Arguments are compared for semantic equivalence.
passive: Bit,
+ /// 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.
durable: Bit,
+ /// Exclusive queues may only be accessed by the current connection, and are
+ /// deleted when that connection closes. Passive declaration of an exclusive
+ /// queue by other connections are not allowed.
exclusive: Bit,
+ /// If set, the queue is deleted when all consumers have finished using it. The 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. Applications can
+ /// explicitly delete auto-delete queues using the Delete method as normal.
auto_delete: Bit,
no_wait: NoWait,
+ /// A set of arguments for the declaration. The syntax and semantics of these
+ /// arguments depends on the server implementation.
arguments: Table,
},
- /// Index 11
+ /// This method confirms a Declare method and confirms the name of the queue, essential
+ /// for automatically-named queues.
DeclareOk {
/// must not be null
+ ///
+ /// Reports the name of the queue. If the server generated a queue name, this field
+ /// contains that name.
queue: QueueName,
message_count: MessageCount,
+ /// 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.
consumer_count: Long,
},
- /// Index 20
+ /// 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.
Bind {
reserved_1: Short,
+ /// Specifies the name of the queue to bind.
queue: QueueName,
exchange: ExchangeName,
+ /// 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.
routing_key: Shortstr,
no_wait: NoWait,
+ /// A set of arguments for the binding. The syntax and semantics of these arguments
+ /// depends on the exchange class.
arguments: Table,
},
- /// Index 21
+ /// This method confirms that the bind was successful.
BindOk,
- /// Index 50
+ /// This method unbinds a queue from an exchange.
Unbind {
reserved_1: Short,
+ /// Specifies the name of the queue to unbind.
queue: QueueName,
+ /// The name of the exchange to unbind from.
exchange: ExchangeName,
+ /// Specifies the routing key of the binding to unbind.
routing_key: Shortstr,
+ /// Specifies the arguments of the binding to unbind.
arguments: Table,
},
- /// Index 51
+ /// This method confirms that the unbind was successful.
UnbindOk,
- /// Index 30
+ /// This method removes all messages from a queue which are not awaiting
+ /// acknowledgment.
Purge {
reserved_1: Short,
+ /// Specifies the name of the queue to purge.
queue: QueueName,
no_wait: NoWait,
},
- /// Index 31
- PurgeOk { message_count: MessageCount },
- /// Index 40
+ /// This method confirms the purge of a queue.
+ PurgeOk {
+ /// Reports the number of messages purged.
+ message_count: MessageCount,
+ },
+ /// 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.
Delete {
reserved_1: Short,
+ /// Specifies the name of the queue to delete.
queue: QueueName,
+ /// 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.
if_unused: Bit,
+ /// If set, the server will only delete the queue if it has no messages.
if_empty: Bit,
no_wait: NoWait,
},
- /// Index 41
- DeleteOk { message_count: MessageCount },
+ /// This method confirms the deletion of a queue.
+ DeleteOk {
+ /// Reports the number of messages deleted.
+ message_count: MessageCount,
+ },
}
-/// Index 60, handler = channel
+/// The Basic class provides methods that support an industry-standard messaging model.
#[derive(Debug, Clone, PartialEq)]
pub enum Basic {
- /// Index 10
+ /// 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.
Qos {
+ /// 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.
prefetch_size: Long,
+ /// 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.
prefetch_count: Short,
+ /// By default the QoS settings apply to the current channel only. If this field is
+ /// set, they are applied to the entire connection.
global: Bit,
},
- /// Index 11
+ /// 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.
QosOk,
- /// Index 20
+ /// 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
+ /// declared on, or until the client cancels them.
Consume {
reserved_1: Short,
+ /// Specifies the name of the queue to consume from.
queue: QueueName,
+ /// Specifies the identifier for the consumer. The consumer tag is local to a
+ /// channel, so two clients can use the same consumer tags. If this field is
+ /// empty the server will generate a unique tag.
consumer_tag: ConsumerTag,
no_local: NoLocal,
no_ack: NoAck,
+ /// Request exclusive consumer access, meaning only this consumer can access the
+ /// queue.
exclusive: Bit,
no_wait: NoWait,
+ /// A set of arguments for the consume. The syntax and semantics of these
+ /// arguments depends on the server implementation.
arguments: Table,
},
- /// Index 21
- ConsumeOk { consumer_tag: ConsumerTag },
- /// Index 30
+ /// 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.
+ ConsumeOk {
+ /// Holds the consumer tag specified by the client or provided by the server.
+ consumer_tag: ConsumerTag,
+ },
+ /// 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.
Cancel {
consumer_tag: ConsumerTag,
no_wait: NoWait,
},
- /// Index 31
+ /// This method confirms that the cancellation was completed.
CancelOk { consumer_tag: ConsumerTag },
- /// Index 40
+ /// 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.
Publish {
reserved_1: Short,
+ /// 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.
exchange: ExchangeName,
+ /// Specifies the routing key for the message. The routing key is used for routing
+ /// messages depending on the exchange configuration.
routing_key: Shortstr,
+ /// 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.
mandatory: Bit,
+ /// 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.
immediate: Bit,
},
- /// Index 50
+ /// 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.
Return {
reply_code: ReplyCode,
reply_text: ReplyText,
+ /// Specifies the name of the exchange that the message was originally published
+ /// to. May be empty, meaning the default exchange.
exchange: ExchangeName,
+ /// Specifies the routing key name specified when the message was published.
routing_key: Shortstr,
},
- /// Index 60
+ /// 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.
Deliver {
consumer_tag: ConsumerTag,
delivery_tag: DeliveryTag,
redelivered: Redelivered,
+ /// Specifies the name of the exchange that the message was originally published to.
+ /// May be empty, indicating the default exchange.
exchange: ExchangeName,
+ /// Specifies the routing key name specified when the message was published.
routing_key: Shortstr,
},
- /// Index 70
+ /// 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.
Get {
reserved_1: Short,
+ /// Specifies the name of the queue to get a message from.
queue: QueueName,
no_ack: NoAck,
},
- /// Index 71
+ /// 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.
GetOk {
delivery_tag: DeliveryTag,
redelivered: Redelivered,
+ /// Specifies the name of the exchange that the message was originally published to.
+ /// If empty, the message was published to the default exchange.
exchange: ExchangeName,
+ /// Specifies the routing key name specified when the message was published.
routing_key: Shortstr,
message_count: MessageCount,
},
- /// Index 72
+ /// This method tells the client that the queue has no messages available for the
+ /// client.
GetEmpty { reserved_1: Shortstr },
- /// Index 80
+ /// 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.
Ack {
delivery_tag: DeliveryTag,
+ /// 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.
multiple: Bit,
},
- /// Index 90
+ /// 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.
Reject {
delivery_tag: DeliveryTag,
+ /// If requeue is true, the server will attempt to requeue the message. If requeue
+ /// is false or the requeue attempt fails the messages are discarded or dead-lettered.
requeue: Bit,
},
- /// Index 100
- RecoverAsync { requeue: Bit },
- /// Index 110
- Recover { requeue: Bit },
- /// Index 111
+ /// This method asks the server to redeliver all unacknowledged messages on a
+ /// specified channel. Zero or more messages may be redelivered. This method
+ /// is deprecated in favour of the synchronous Recover/Recover-Ok.
+ RecoverAsync {
+ /// 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.
+ requeue: Bit,
+ },
+ /// This method asks the server to redeliver all unacknowledged messages on a
+ /// specified channel. Zero or more messages may be redelivered. This method
+ /// replaces the asynchronous Recover.
+ Recover {
+ /// 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.
+ requeue: Bit,
+ },
+ /// This method acknowledges a Basic.Recover method.
RecoverOk,
}
-/// Index 90, handler = channel
+/// The Tx class allows publish and ack operations to be batched into atomic
+/// units of work. The intention is that all publish and ack requests issued
+/// within a transaction will complete successfully or none of them will.
+/// Servers SHOULD implement atomic transactions at least where all publish
+/// or ack requests affect a single queue. Transactions that cover multiple
+/// queues may be non-atomic, given that queues can be created and destroyed
+/// asynchronously, and such events do not form part of any transaction.
+/// Further, the behaviour of transactions with respect to the immediate and
+/// mandatory flags on Basic.Publish methods is not defined.
#[derive(Debug, Clone, PartialEq)]
pub enum Tx {
- /// Index 10
+ /// 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.
Select,
- /// Index 11
+ /// This method confirms to the client that the channel was successfully set to use
+ /// standard transactions.
SelectOk,
- /// Index 20
+ /// This method commits all message publications and acknowledgments performed in
+ /// the current transaction. A new transaction starts immediately after a commit.
Commit,
- /// Index 21
+ /// This method confirms to the client that the commit succeeded. Note that if a commit
+ /// fails, the server raises a channel exception.
CommitOk,
- /// Index 30
+ /// This method abandons all message publications and acknowledgments performed in
+ /// the current transaction. A new transaction starts immediately after a rollback.
+ /// Note that unacked messages will not be automatically redelivered by rollback;
+ /// if that is required an explicit recover call should be issued.
Rollback,
- /// Index 31
+ /// This method confirms to the client that the rollback succeeded. Note that if an
+ /// rollback fails, the server raises a channel exception.
RollbackOk,
}
pub mod parse {
@@ -457,8 +801,6 @@ pub mod parse {
connection_open_ok,
connection_close,
connection_close_ok,
- connection_blocked,
- connection_unblocked,
))(input)
.map_err(err("class connection"))
.map_err(failure)
@@ -646,17 +988,6 @@ pub mod parse {
let (input, _) = tag(51_u16.to_be_bytes())(input).map_err(err("parsing method index"))?;
Ok((input, Class::Connection(Connection::CloseOk {})))
}
- fn connection_blocked(input: &[u8]) -> IResult {
- let (input, _) = tag(60_u16.to_be_bytes())(input).map_err(err("parsing method index"))?;
- let (input, reason) = domain_shortstr(input)
- .map_err(err("field reason in method blocked"))
- .map_err(failure)?;
- Ok((input, Class::Connection(Connection::Blocked { reason })))
- }
- fn connection_unblocked(input: &[u8]) -> IResult {
- let (input, _) = tag(61_u16.to_be_bytes())(input).map_err(err("parsing method index"))?;
- Ok((input, Class::Connection(Connection::Unblocked {})))
- }
fn channel(input: &[u8]) -> IResult {
let (input, _) =
tag(20_u16.to_be_bytes())(input).map_err(err("invalid tag for class channel"))?;
@@ -1455,13 +1786,6 @@ pub mod write {
Class::Connection(Connection::CloseOk {}) => {
writer.write_all(&[0, 10, 0, 51])?;
}
- Class::Connection(Connection::Blocked { reason }) => {
- writer.write_all(&[0, 10, 0, 60])?;
- shortstr(reason, &mut writer)?;
- }
- Class::Connection(Connection::Unblocked {}) => {
- writer.write_all(&[0, 10, 0, 61])?;
- }
Class::Channel(Channel::Open { reserved_1 }) => {
writer.write_all(&[0, 20, 0, 10])?;
shortstr(reserved_1, &mut writer)?;
@@ -1811,7 +2135,7 @@ mod random {
impl RandomMethod for Connection {
#[allow(unused_variables)]
fn random(rng: &mut R) -> Self {
- match rng.gen_range(0u32..12) {
+ match rng.gen_range(0u32..10) {
0 => Connection::Start {
version_major: RandomMethod::random(rng),
version_minor: RandomMethod::random(rng),
@@ -1856,10 +2180,6 @@ mod random {
method_id: RandomMethod::random(rng),
},
9 => Connection::CloseOk {},
- 10 => Connection::Blocked {
- reason: RandomMethod::random(rng),
- },
- 11 => Connection::Unblocked {},
_ => unreachable!(),
}
}