AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
share/fixed_amqp0-9-1.xml view on Meta::CPAN
No other rights are granted by implication, estoppel or otherwise.
Upon termination of your license or rights under this Agreement, you
shall destroy all copies of the Advanced Messaging Queue Protocol
Specification in your possession or control.
Trademarks
==========
JPMorgan, JPMorgan Chase, Chase, the JPMorgan Chase logo and the
Octagon Symbol are trademarks of JPMorgan Chase & Co.
IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
IONA, IONA Technologies, and the IONA logos are trademarks of IONA
Technologies PLC and/or its subsidiaries.
LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered
trademarks of Red Hat, Inc. in the US and other countries.
Java, all Java-based trademarks and OpenOffice.org are trademarks of
Sun Microsystems, Inc. in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service
marks of others.
Links to full AMQP specification:
=================================
http://www.amqp.org
-->
<!--
<!DOCTYPE amqp SYSTEM "amqp.dtd">
-->
<!-- XML Notes
We use entities to indicate repetition; attributes to indicate properties.
We use the 'name' attribute as an identifier, usually within the context
of the surrounding entities.
We use spaces to seperate words in names, so that we can print names in
their natural form depending on the context - underlines for source code,
hyphens for written text, etc.
We do not enforce any particular validation mechanism but we support all
mechanisms. The protocol definition conforms to a formal grammar that is
published seperately in several technologies.
-->
<amqp major = "0" minor = "9" revision = "1"
port = "5672" comment = "AMQ Protocol version 0-9-1">
<!--
======================================================
== CONSTANTS
======================================================
-->
<!-- Frame types -->
<constant name = "frame-method" value = "1" />
<constant name = "frame-header" value = "2" />
<constant name = "frame-body" value = "3" />
<constant name = "frame-heartbeat" value = "8" />
<!-- Protocol constants -->
<constant name = "frame-min-size" value = "4096" />
<constant name = "frame-end" value = "206" />
<!-- Reply codes -->
<constant name = "reply-success" value = "200">
<doc>
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.
</doc>
</constant>
<constant name = "content-too-large" value = "311" class = "soft-error">
<doc>
The client attempted to transfer content larger than the server could accept
at the present time. The client may retry at a later time.
</doc>
</constant>
<constant name = "no-consumers" value = "313" class = "soft-error">
<doc>
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.
</doc>
</constant>
<constant name = "connection-forced" value = "320" class = "hard-error">
<doc>
An operator intervened to close the connection for some reason. The client
may retry at some later date.
</doc>
</constant>
<constant name = "invalid-path" value = "402" class = "hard-error">
<doc>
The client tried to work with an unknown virtual host.
</doc>
</constant>
<constant name = "access-refused" value = "403" class = "soft-error">
<doc>
The client attempted to work with a server entity to which it has no
access due to security settings.
</doc>
</constant>
<constant name = "not-found" value = "404" class = "soft-error">
<doc>
The client attempted to work with a server entity that does not exist.
</doc>
</constant>
<constant name = "resource-locked" value = "405" class = "soft-error">
<doc>
The client attempted to work with a server entity to which it has no
access because another client is working with it.
</doc>
</constant>
<constant name = "precondition-failed" value = "406" class = "soft-error">
<doc>
The client requested a method that was not allowed because some precondition
failed.
</doc>
</constant>
<constant name = "frame-error" value = "501" class = "hard-error">
<doc>
The sender sent a malformed frame that the recipient could not decode.
This strongly implies a programming error in the sending peer.
</doc>
</constant>
<constant name = "syntax-error" value = "502" class = "hard-error">
<doc>
The sender sent a frame that contained illegal values for one or more
fields. This strongly implies a programming error in the sending peer.
</doc>
</constant>
<constant name = "command-invalid" value = "503" class = "hard-error">
<doc>
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.
</doc>
</constant>
<constant name = "channel-error" value = "504" class = "hard-error">
<doc>
The client attempted to work with a channel that had not been correctly
opened. This most likely indicates a fault in the client layer.
</doc>
</constant>
<constant name = "unexpected-frame" value = "505" class = "hard-error">
<doc>
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.
</doc>
</constant>
<constant name = "resource-error" value = "506" class = "hard-error">
<doc>
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.
</doc>
</constant>
<constant name = "not-allowed" value = "530" class = "hard-error">
<doc>
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.
</doc>
</constant>
<constant name = "not-implemented" value = "540" class = "hard-error">
<doc>
The client tried to use functionality that is not implemented in the
server.
</doc>
</constant>
<constant name = "internal-error" value = "541" class = "hard-error">
<doc>
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.
</doc>
</constant>
<!--
======================================================
== DOMAIN TYPES
======================================================
-->
<domain name = "class-id" type = "short" />
<domain name = "consumer-tag" type = "shortstr" label = "consumer tag">
<doc>
Identifier for the consumer, valid within the current channel.
</doc>
</domain>
<domain name = "delivery-tag" type = "longlong" label = "server-assigned delivery tag">
<doc>
The server-assigned and channel-specific delivery tag
</doc>
<rule name = "channel-local">
<doc>
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.
</doc>
</rule>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "secure" synchronous = "1" index = "20" label = "security mechanism challenge">
<doc>
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.
</doc>
<chassis name = "client" implement = "MUST" />
<response name = "secure-ok" />
<field name = "challenge" domain = "longstr" label = "security challenge data">
<doc>
Challenge information, a block of opaque binary data passed to the security
mechanism.
</doc>
</field>
</method>
<method name = "secure-ok" synchronous = "1" index = "21" label = "security mechanism response">
<doc>
This method attempts to authenticate, passing a block of SASL data for the security
mechanism at the server side.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "response" domain = "longstr" label = "security response data">
<doc>
A block of opaque data passed to the security mechanism. The contents of this
data are defined by the SASL security mechanism.
</doc>
<assert check = "notnull" />
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "tune" synchronous = "1" index = "30"
label = "propose connection tuning parameters">
<doc>
This method proposes a set of connection configuration values to the client. The
client can accept and/or adjust these.
</doc>
<chassis name = "client" implement = "MUST" />
<response name = "tune-ok" />
<field name = "channel-max" domain = "short" label = "proposed maximum channels">
<doc>
Specifies highest channel number that the server permits. Usable channel numbers
are in the range 1..channel-max. Zero indicates no specified limit.
</doc>
</field>
<field name = "frame-max" domain = "long" label = "proposed maximum frame size">
<doc>
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.
</doc>
<rule name = "minimum">
<doc>
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.
</doc>
<doc type = "scenario">
Client connects to server and sends a large properties field, creating a frame
of frame-min-size octets. The server must accept this frame.
</doc>
</rule>
</field>
<field name = "heartbeat" domain = "short" label = "desired heartbeat delay">
<doc>
The delay, in seconds, of the connection heartbeat that the server wants.
Zero means the server does not want a heartbeat.
</doc>
</field>
</method>
<method name = "tune-ok" synchronous = "1" index = "31"
label = "negotiate connection tuning parameters">
<doc>
This method sends the client's connection tuning parameters to the server.
Certain fields are negotiated, others provide capability information.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "channel-max" domain = "short" label = "negotiated maximum channels">
<doc>
The maximum total number of channels that the client will use per connection.
</doc>
<rule name = "upper-limit">
<doc>
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.
</doc>
</rule>
<assert check = "notnull" />
<assert check = "le" method = "tune" field = "channel-max" />
</field>
<field name = "frame-max" domain = "long" label = "negotiated maximum frame size">
<doc>
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.
</doc>
<rule name = "minimum">
<doc>
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.
</doc>
</rule>
<rule name = "upper-limit">
<doc>
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.
</doc>
</rule>
</field>
<field name = "heartbeat" domain = "short" label = "desired heartbeat delay">
<doc>
The delay, in seconds, of the connection heartbeat that the client wants. Zero
means the client does not want a heartbeat.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "open" synchronous = "1" index = "40" label = "open connection to virtual host">
<doc>
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.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "open-ok" />
<field name = "virtual-host" domain = "path" label = "virtual host name">
<doc>
The name of the virtual host to work with.
</doc>
<rule name = "separation">
<doc>
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.
</doc>
</rule>
<rule name = "security">
<doc>
The server SHOULD verify that the client has permission to access the
specified virtual host.
</doc>
</rule>
</field>
<!-- Deprecated: "capabilities", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
<!-- Deprecated: "insist", must be zero -->
<field name = "reserved-2" type = "bit" reserved = "1" />
</method>
<method name = "open-ok" synchronous = "1" index = "41" label = "signal that connection is ready">
<doc>
This method signals to the client that the connection is ready for use.
</doc>
<chassis name = "client" implement = "MUST" />
<!-- Deprecated: "known-hosts", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
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
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "open" synchronous = "1" index = "10" label = "open a channel for use">
<doc>
This method opens a channel to the server.
</doc>
<rule name = "state" on-failure = "channel-error">
<doc>
The client MUST NOT use this method on an already-opened channel.
</doc>
<doc type = "scenario">
Client opens a channel and then reopens the same channel.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "open-ok" />
<!-- Deprecated: "out-of-band", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
</method>
<method name = "open-ok" synchronous = "1" index = "11" label = "signal that the channel is ready">
<doc>
This method signals to the client that the channel is ready for use.
</doc>
<chassis name = "client" implement = "MUST" />
<!-- Deprecated: "channel-id", must be zero -->
<field name = "reserved-1" type = "longstr" reserved = "1" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "flow" synchronous = "1" index = "20" label = "enable/disable flow from peer">
<doc>
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.
</doc>
<rule name = "initial-state">
<doc>
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.
</doc>
</rule>
<rule name = "bidirectional">
<doc>
When sending content frames, a peer SHOULD monitor the channel for incoming
methods and respond to a Channel.Flow as rapidly as possible.
</doc>
</rule>
<rule name = "throttling">
<doc>
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.
</doc>
</rule>
<rule name = "expected-behaviour">
<doc>
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.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<response name = "flow-ok" />
<field name = "active" domain = "bit" label = "start/stop content frames">
<doc>
If 1, the peer starts sending content frames. If 0, the peer stops sending
content frames.
</doc>
</field>
</method>
<method name = "flow-ok" index = "21" label = "confirm a flow method">
<doc>
Confirms to the peer that a flow command was received and processed.
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<field name = "active" domain = "bit" label = "current flow setting">
<doc>
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.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "close" synchronous = "1" index = "40" label = "request a channel close">
<doc>
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.
</doc>
<rule name = "stability">
<doc>
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.
</doc>
</rule>
<chassis name = "client" implement = "MUST" />
<chassis name = "server" implement = "MUST" />
<response name = "close-ok" />
<field name = "reply-code" domain = "reply-code" />
<field name = "reply-text" domain = "reply-text" />
<field name = "class-id" domain = "class-id" label = "failing method class">
<doc>
When the close is provoked by a method exception, this is the class of the
method.
</doc>
</field>
<field name = "method-id" domain = "method-id" label = "failing method ID">
<doc>
When the close is provoked by a method exception, this is the ID of the method.
</doc>
</field>
</method>
<method name = "close-ok" synchronous = "1" index = "41" label = "confirm a channel close">
<doc>
This method confirms a Channel.Close method and tells the recipient that it is safe
to release resources for the channel.
</doc>
<rule name = "reporting">
<doc>
A peer that detects a socket closure without having received a Channel.Close-Ok
handshake method SHOULD log the error.
</doc>
</rule>
<chassis name = "client" implement = "MUST" />
<chassis name = "server" implement = "MUST" />
</method>
</class>
<!-- == EXCHANGE ========================================================= -->
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<field name = "reserved-1" type = "shortstr" reserved = "1" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "ack" index = "80" label = "acknowledge one or more messages">
<doc>
When sent by the client, this method acknowledges one or more
messages delivered via the Deliver or Get-Ok methods.
When sent by server, this method acknowledges one or more
messages published with the Publish method on a channel in
confirm mode.
The acknowledgement can be for a single message or a set of
messages up to and including a specific message.
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name ="client" implement = "MUST"/>
<field name = "delivery-tag" domain = "delivery-tag" />
<field name = "multiple" domain = "bit" label = "acknowledge multiple messages">
<doc>
If set to 1, the delivery tag is treated as "up to and
including", so that multiple messages can be acknowledged
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, this indicates acknowledgement of
all outstanding messages.
</doc>
<rule name = "exists" on-failure = "precondition-failed">
<doc>
A message MUST not be acknowledged more than once. The
receiving peer 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.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "reject" index = "90" label = "reject an incoming message">
<doc>
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.
</doc>
<rule name = "01">
<doc>
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).
</doc>
</rule>
<rule name = "02">
<doc>
The server SHOULD interpret this method as meaning that the client is unable to
process the message at this time.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<rule name = "03">
<doc>
The client MUST NOT use this method as a means of selecting messages to process.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<field name = "delivery-tag" domain = "delivery-tag" />
<field name = "requeue" domain = "bit" label = "requeue the message">
<doc>
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.
</doc>
<rule name = "01">
<doc>
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.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "recover-async" index = "100" label = "redeliver unacknowledged messages"
deprecated = "1">
<doc>
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.
</doc>
<rule name = "01">
<doc>
The server MUST set the redelivered flag on all messages that are resent.
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</doc>
</rule>
<chassis name = "server" implement = "MAY" />
<field name = "requeue" domain = "bit" label = "requeue the message">
<doc>
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.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "recover" index = "110" label = "redeliver unacknowledged messages">
<doc>
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.
</doc>
<rule name = "01">
<doc>
The server MUST set the redelivered flag on all messages that are resent.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<field name = "requeue" domain = "bit" label = "requeue the message">
<doc>
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.
</doc>
</field>
</method>
<method name = "recover-ok" synchronous = "1" index = "111" label = "confirm recovery">
<doc>
This method acknowledges a Basic.Recover method.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<method name = "nack" index = "120" label = "reject one or more incoming messages">
<doc>
This method allows a client to reject one or more incoming messages. It can be
used to interrupt and cancel large incoming messages, or return untreatable
messages to their original queue.
This method is also used by the server to inform publishers on channels in
confirm mode of unhandled messages. If a publisher receives this method, it
probably needs to republish the offending messages.
</doc>
<rule name = "01">
<doc>
The server SHOULD be capable of accepting and processing the Nack 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).
</doc>
</rule>
<rule name = "02">
<doc>
The server SHOULD interpret this method as meaning that the client is unable to
process the message at this time.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<rule name = "03">
<doc>
The client MUST NOT use this method as a means of selecting messages to process.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<rule name = "04">
<doc>
A client publishing messages to a channel in confirm mode SHOULD be capable of accepting
and somehow handling the Nack method.
</doc>
<doc type = "scenario">
TODO
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<field name = "delivery-tag" domain = "delivery-tag" />
<field name = "multiple" domain = "bit" label = "reject multiple messages">
<doc>
If set to 1, the delivery tag is treated as "up to and
including", so that multiple messages can be rejected
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, this indicates rejection of
all outstanding messages.
</doc>
<rule name = "exists" on-failure = "precondition-failed">
<doc>
A message MUST not be rejected more than once. The
receiving peer MUST validate that a non-zero delivery-tag
refers to an unacknowledged, delivered message, and
raise a channel exception if this is not the case.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "requeue" domain = "bit" label = "requeue the message">
( run in 1.641 second using v1.01-cache-2.11-cpan-df04353d9ac )