AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
share/fixed_amqp0-8.xml view on Meta::CPAN
IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE
CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE
SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED
MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY
PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY
USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE
PROTOCOL SPECIFICATION.
The name and trademarks of the Authors may NOT be used in any manner,
including advertising or publicity pertaining to the Advanced Messaging
Queue Protocol Specification or its contents without specific, written
prior permission. Title to copyright in the Advanced Messaging Queue
Protocol Specification will at all times remain with the Authors.
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.envoytech.org/spec/amq/
http://www.iona.com/opensource/amqp/
http://www.redhat.com/solutions/specifications/amqp/
http://www.twiststandards.org/tiki-index.php?page=AMQ
http://www.imatix.com/amqp
-->
<amqp major="8" minor="0" port="5672" comment="AMQ protocol 0.80">
AMQ Protocol 0.80
<!--
======================================================
== CONSTANTS
======================================================
-->
<constant name="frame method" value="1"/>
<constant name="frame header" value="2"/>
<constant name="frame body" value="3"/>
<constant name="frame oob method" value="4"/>
<constant name="frame oob header" value="5"/>
<constant name="frame oob body" value="6"/>
<constant name="frame trace" value="7"/>
<constant name="frame heartbeat" value="8"/>
<constant name="frame min size" value="4096"/>
<constant name="frame end" value="206"/>
<constant name="reply success" value="200">
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.
</constant>
<constant name="not delivered" value="310" class="soft error">
The client asked for a specific message that is no longer available.
The message was delivered to another client, or was purged from the
queue for some other reason.
</constant>
<constant name="content too large" value="311" class="soft 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.
</constant>
<constant name="connection forced" value="320" class="hard error">
An operator intervened to close the connection for some reason.
The client may retry at some later date.
</constant>
<constant name="invalid path" value="402" class="hard error">
The client tried to work with an unknown virtual host or cluster.
</constant>
<constant name="access refused" value="403" class="soft error">
The client attempted to work with a server entity to which it has
no due to security settings.
</constant>
<constant name="not found" value="404" class="soft error">
The client attempted to work with a server entity that does not exist.
</constant>
<constant name="resource locked" value="405" class="soft error">
The client attempted to work with a server entity to which it has
no access because another client is working with it.
</constant>
<constant name="frame error" value="501" class="hard error">
The client sent a malformed frame that the server could not decode.
This strongly implies a programming error in the client.
</constant>
<constant name="syntax error" value="502" class="hard error">
The client sent a frame that contained illegal values for one or more
fields. This strongly implies a programming error in the client.
</constant>
<constant name="command invalid" value="503" class="hard error">
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.
</constant>
<constant name="channel error" value="504" class="hard error">
The client attempted to work with a channel that had not been
correctly opened. This most likely indicates a fault in the client
layer.
</constant>
<constant name="resource error" value="506" class="hard error">
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.
</constant>
<constant name="not allowed" value="530" class="hard error">
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.
</constant>
<constant name="not implemented" value="540" class="hard error">
The client tried to use functionality that is not implemented in the
server.
</constant>
<constant name="internal error" value="541" class="hard error">
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.
</constant>
<!--
======================================================
== DOMAIN TYPES
======================================================
-->
<domain name="access ticket" type="short">
access ticket granted by server
<doc>
An access ticket granted by the server for a certain set of access
rights within a specific realm. Access tickets are valid within the
channel where they were created, and expire when the channel closes.
</doc>
<assert check="ne" value="0"/>
</domain>
<domain name="class id" type="short"/>
<domain name="consumer tag" type="shortstr">
consumer tag
<doc>
Identifier for the consumer, valid within the current connection.
</doc>
<rule implement="MUST">
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.
</rule>
</domain>
<domain name="delivery tag" type="longlong">
server-assigned delivery tag
<doc>
The server-assigned and channel-specific delivery tag
</doc>
<rule implement="MUST">
The delivery tag is valid only within the channel from which the
share/fixed_amqp0-8.xml view on Meta::CPAN
<doc>
A single message local selected by the client, which must be one
of those specified by the server.
</doc>
<assert check="notnull"/>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="secure" synchronous="1" index="20">
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" type="longstr">
security challenge data
<doc>
Challenge information, a block of opaque binary data passed to
the security mechanism.
</doc>
<see name="security mechanisms"/>
</field>
</method>
<method name="secure-ok" synchronous="1" index="21">
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" type="longstr">
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">
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" type="short">
proposed maximum channels
<doc>
The maximum total number of channels that the server allows
per connection. Zero means that the server does not impose a
fixed limit, but the number of allowed channels may be limited
by available server resources.
</doc>
</field>
<field name="frame max" type="long">
proposed maximum frame size
<doc>
The largest frame size that the server proposes for the
connection. The client can negotiate a lower value. Zero means
that the server does not impose any specific limit but may reject
very large frames if it cannot allocate resources for them.
</doc>
<rule implement="MUST">
Until the frame-max has been negotiated, both peers MUST accept
frames of up to 4096 octets large. The minimum non-zero value for
the frame-max field is 4096.
</rule>
</field>
<field name="heartbeat" type="short">
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">
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" type="short">
negotiated maximum channels
<doc>
The maximum total number of channels that the client will use
per connection. May not be higher than the value specified by
the server.
</doc>
<rule implement="MAY">
The server MAY ignore the channel-max value or MAY use it for
tuning its resource allocation.
</rule>
<assert check="notnull"/>
<assert check="le" method="tune" field="channel max"/>
</field>
<field name="frame max" type="long">
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 implement="MUST">
Until the frame-max has been negotiated, both peers must accept
frames of up to 4096 octets large. The minimum non-zero value for
the frame-max field is 4096.
</rule>
</field>
<field name="heartbeat" type="short">
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">
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.
</doc>
<rule implement="MUST">
The client MUST open the context before doing any work on the
connection.
</rule>
<chassis name="server" implement="MUST"/>
<response name="open-ok"/>
<response name="redirect"/>
<field name="virtual host" domain="path">
virtual host name
<assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/>
<doc>
The name of the virtual host to work with.
</doc>
<rule implement="MUST">
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.
</rule>
<rule implement="SHOULD">
The server SHOULD verify that the client has permission to access
the specified virtual host.
</rule>
<rule implement="MAY">
The server MAY configure arbitrary limits per virtual host, such
as the number of each type of entity that may be used, per
connection and/or in total.
</rule>
</field>
<field name="capabilities" type="shortstr">
required capabilities
<doc>
The client may specify a number of capability names, delimited by
spaces. The server can use this string to how to process the
client's connection request.
</doc>
</field>
<field name="insist" type="bit">
insist on connecting to server
<doc>
In a configuration with multiple load-sharing servers, the server
may respond to a Connection.Open method with a Connection.Redirect.
share/fixed_amqp0-8.xml view on Meta::CPAN
connection - a channel - to a server and for both peers to operate the
virtual connection thereafter.
</doc>
<doc name="grammar">
channel = open-channel *use-channel close-channel
open-channel = C:OPEN S:OPEN-OK
use-channel = C:FLOW S:FLOW-OK
/ S:FLOW C:FLOW-OK
/ S:ALERT
/ functional-class
close-channel = C:CLOSE S:CLOSE-OK
/ S:CLOSE C:CLOSE-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="open" synchronous="1" index="10">
open a channel for use
<doc>
This method opens a virtual connection (a channel).
</doc>
<rule implement="MUST">
This method MUST NOT be called when the channel is already open.
</rule>
<chassis name="server" implement="MUST"/>
<response name="open-ok"/>
<field name="out of band" type="shortstr">
out-of-band settings
<doc>
Configures out-of-band transfers on this channel. The syntax and
meaning of this field will be formally defined at a later date.
</doc>
<assert check="null"/>
</field>
</method>
<method name="open-ok" synchronous="1" index="11">
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"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="flow" synchronous="1" index="20">
enable/disable flow from peer
<doc>
This method asks the peer to pause or restart the flow of content
data. This is a simple flow-control mechanism that a peer can use
to avoid oveflowing its queues or otherwise finding itself receiving
more messages than it can process. Note that this method is not
intended for window control. The peer that receives a request to
stop sending content should finish sending the current content, if
any, and then wait until it receives a Flow restart method.
</doc>
<rule implement="MAY">
When a new channel is opened, it is active. Some applications
assume that channels are inactive until started. To emulate this
behaviour a client MAY open the channel, then pause it.
</rule>
<rule implement="SHOULD">
When sending content data in multiple frames, a peer SHOULD monitor
the channel for incoming methods and respond to a Channel.Flow as
rapidly as possible.
</rule>
<rule implement="MAY">
A peer MAY use the Channel.Flow method to throttle incoming content
data for internal reasons, for example, when exchangeing data over a
slower connection.
</rule>
<rule implement="MAY">
The peer that requests a Channel.Flow method MAY disconnect and/or
ban a peer that does not respect the request.
</rule>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<response name="flow-ok"/>
<field name="active" type="bit">
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">
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" type="bit">
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="alert" index="30">
send a non-fatal warning message
<doc>
This method allows the server to send a non-fatal warning to the
client. This is used for methods that are normally asynchronous
and thus do not have confirmations, and for which the server may
detect errors that need to be reported. Fatal errors are handled
as channel or connection exceptions; non-fatal errors are sent
through this method.
</doc>
<chassis name="client" implement="MUST"/>
<field name="reply code" domain="reply code"/>
<field name="reply text" domain="reply text"/>
<field name="details" type="table">
detailed information for warning
<doc>
A set of fields that provide more information about the
problem. The meaning of these fields are defined on a
per-reply-code basis (TO BE DEFINED).
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="close" synchronous="1" index="40">
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 implement="MUST">
After sending this method any received method except
Channel.Close-OK MUST be discarded.
</rule>
<rule implement="MAY">
The peer sending this method MAY use a counter or timeout to detect
failure of the other peer to respond correctly with Channel.Close-OK..
</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">
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">
failing method ID
<doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
<method name = "get-empty" synchronous = "1" index = "72">
indicate no messages available
<doc>
This method tells the client that the queue has no messages
available for the client.
</doc>
<chassis name = "client" implement = "MAY" />
<field name = "cluster id" type = "shortstr">
Cluster id
<doc>
For use by cluster applications, should not be used by
client applications.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "ack" index = "80">
acknowledge one or more messages
<doc>
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.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "delivery tag" domain = "delivery tag" />
<field name = "multiple" type = "bit">
acknowledge multiple messages
<doc>
If set to 1, the delivery tag is treated as "up to and including",
so that the client can acknowledge multiple messages with a single
method. If set to zero, the delivery tag refers to a single
message. If the multiple field is 1, and the delivery tag is zero,
tells the server to acknowledge all outstanding mesages.
</doc>
<doc name = "rule" test = "amq_basic_20">
The server MUST validate that a non-zero delivery-tag refers to an
delivered message, and raise a channel exception if this is not the
case.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "reject" index = "90">
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>
<doc name = "rule" test = "amq_basic_21">
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>
<doc name = "rule" test = "amq_basic_22">
The server SHOULD interpret this method as meaning that the client
is unable to process the message at this time.
</doc>
<doc name = "rule">
A client MUST NOT use this method as a means of selecting messages
to process. A rejected message MAY be discarded or dead-lettered,
not necessarily passed to another client.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "delivery tag" domain = "delivery tag" />
<field name = "requeue" type = "bit">
requeue the message
<doc>
If this field is zero, the message will be discarded. If this bit
is 1, the server will attempt to requeue the message.
</doc>
<doc name = "rule" test = "amq_basic_23">
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>
</field>
</method>
<method name = "recover" index = "100">
redeliver unacknowledged messages. This method is only allowed on non-transacted channels.
<doc>
This method asks the broker to redeliver all unacknowledged messages on a
specifieid channel. Zero or more messages may be redelivered.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "requeue" type = "bit">
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>
<doc name="rule">
The server MUST set the redelivered flag on all messages that are resent.
</doc>
<doc name="rule">
The server MUST raise a channel exception if this is called on a transacted channel.
</doc>
</method>
</class>
share/fixed_amqp0-8.xml view on Meta::CPAN
<chassis name="client" implement="MAY"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="select" synchronous="1" index="10">
select standard transaction mode
<doc>
This method sets the channel to use distributed transactions. The
client must use this method at least once on a channel before
using the Start method.
</doc>
<chassis name="server" implement="MUST"/>
<response name="select-ok"/>
</method>
<method name="select-ok" synchronous="1" index="11">
confirm transaction mode
<doc>
This method confirms to the client that the channel was successfully
set to use distributed transactions.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="start" synchronous="1" index="20">
start a new distributed transaction
<doc>
This method starts a new distributed transaction. This must be
the first method on a new channel that uses the distributed
transaction mode, before any methods that publish or consume
messages.
</doc>
<chassis name="server" implement="MAY"/>
<response name="start-ok"/>
<field name="dtx identifier" type="shortstr">
transaction identifier
<doc>
The distributed transaction key. This identifies the transaction
so that the AMQP server can coordinate with the distributed
transaction coordinator.
</doc>
<assert check="notnull"/>
</field>
</method>
<method name="start-ok" synchronous="1" index="21">
confirm the start of a new distributed transaction
<doc>
This method confirms to the client that the transaction started.
Note that if a start fails, the server raises a channel exception.
</doc>
<chassis name="client" implement="MUST"/>
</method>
</class>
<class name="tunnel" handler="tunnel" index="110">
<!--
======================================================
== TUNNEL
======================================================
-->
methods for protocol tunneling.
<doc>
The tunnel methods are used to send blocks of binary data - which
can be serialised AMQP methods or other protocol frames - between
AMQP peers.
</doc>
<doc name="grammar">
tunnel = C:REQUEST
/ S:REQUEST
</doc>
<chassis name="server" implement="MAY"/>
<chassis name="client" implement="MAY"/>
<field name="headers" type="table">
Message header field table
</field>
<field name="proxy name" type="shortstr">
The identity of the tunnelling proxy
</field>
<field name="data name" type="shortstr">
The name or type of the message being tunnelled
</field>
<field name="durable" type="octet">
The message durability indicator
</field>
<field name="broadcast" type="octet">
The message broadcast mode
</field>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="request" content="1" index="10">
sends a tunnelled method
<doc>
This method tunnels a block of binary data, which can be an
encoded AMQP method or other data. The binary data is sent
as the content for the Tunnel.Request method.
</doc>
<chassis name="server" implement="MUST"/>
<field name="meta data" type="table">
meta data for the tunnelled block
<doc>
This field table holds arbitrary meta-data that the sender needs
to pass to the recipient.
</doc>
</field>
</method>
</class>
<class name="test" handler="channel" index="120">
<!--
======================================================
== TEST - CHECK FUNCTIONAL CAPABILITIES OF AN IMPLEMENTATION
======================================================
-->
test functional primitives of the implementation
<doc>
The test class provides methods for a peer to test the basic
operational correctness of another peer. The test methods are
intended to ensure that all peers respect at least the basic
elements of the protocol, such as frame and content organisation
and field types. We assume that a specially-designed peer, a
"monitor client" would perform such tests.
</doc>
<doc name="grammar">
test = C:INTEGER S:INTEGER-OK
/ S:INTEGER C:INTEGER-OK
/ C:STRING S:STRING-OK
/ S:STRING C:STRING-OK
/ C:TABLE S:TABLE-OK
/ S:TABLE C:TABLE-OK
/ C:CONTENT S:CONTENT-OK
/ S:CONTENT C:CONTENT-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="SHOULD"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="integer" synchronous="1" index="10">
test integer handling
<doc>
This method tests the peer's capability to correctly marshal integer
data.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<response name="integer-ok"/>
<field name="integer 1" type="octet">
octet test value
<doc>
An octet integer test value.
</doc>
</field>
<field name="integer 2" type="short">
short test value
<doc>
A short integer test value.
</doc>
</field>
<field name="integer 3" type="long">
long test value
<doc>
A long integer test value.
</doc>
</field>
<field name="integer 4" type="longlong">
long-long test value
<doc>
A long long integer test value.
</doc>
</field>
<field name="operation" type="octet">
operation to test
<doc>
The client must execute this operation on the provided integer
test fields and return the result.
</doc>
<assert check="enum">
<value name="add">return sum of test values</value>
<value name="min">return lowest of test values</value>
<value name="max">return highest of test values</value>
</assert>
( run in 1.647 second using v1.01-cache-2.11-cpan-df04353d9ac )