AMQP 1.0 Protocol Conformance

This page is a statement of functionally-visible restrictions, limitations and non-conformances between OASIS AMQP Version 1.0 and Solaceʼs AMQP implementation. Each section noted on this page indicates an area of deviation between some aspect of the AMQP protocol and Solace's implementation. It should be noted that Solace PubSub+ event brokers support only the server-side role.

The section numbers in each heading refer to the corresponding section in this OASIS AMQP protocol specification:

[amqp-core-complete-v1.0]

OASIS AMQP Version 1.0. 24 July 2017. OASIS Working Draft.

../../v1.0/wd/amqp-core-complete-v1.0-wd.pdf.

It should also be noted that the implementation follows AMQP JMS mapping version 1.0 draft 8.

Section 2.1.2: Communication Endpoints

1. Applicable specification text:

“The retained state at the termini can be used to reestablish the link on a new connection (and session) with precise control over delivery guarantees (e.g., ensuring “exactly once” delivery).”

Solace implementation:

The event broker does not retain any state with respect to AMQP links or sessions, which persists across AMQP connection failure and re-establishment.

Section 2.2: Version Negotiation

1. Applicable specification text:

“Two AMQP peers agree on a protocol version as follows (where the words “client” and “server” refer to the roles being played by the peers at the TCP connection level):”

Solace implementation:

The event brokers always act as TCP servers for AMQP connections.

2. Applicable specification text:

“Based on this behavior a client can discover which protocol versions a server supports by attempting to connect with its highest supported version and reconnecting with a version less than or equal to the version received back from the server.”

Solace implementation:

The event brokers support only AMQP major=1, minor=0, revision=0 in their received and send protocol headers.

3. Applicable specification text:

Entire section.

Solace implementation:

On a newly-established TCP or TLS connection, an event broker first waits for the client to send the protocol header, which may be for protocol 0 (AMQP) or 3 (SASL). The event broker will then respond with the same protocol header.

However, a client sending a protocol header with protocol 0 (AMQP) will succeed in bringing the connection to the OPENED state (see subsection 2.4.6) only if the authentication for the VPN is configured as “none”.

Section 2.4.1: Opening A Connection

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker never initiates an AMQP connection.

An event broker considers that the client has been created, and performs follow-on actions such as generating CLIENT CLIENT CONNECT event logs, once the event broker processes the open frame received from the partner.

An event broker will not open any new AMQP connections from partners if the event broker has already reached its limit of connected enterprise clients.

Section 2.4.3: Closing a Connection

1. Applicable specification text:

Entire section.

Solace implementation:

The Solace PubSub+ event broker only sends AMQP close frames on a best effort basis; so, there is no guarantee that the event broker will always send the close frame.

Section 2.4.5: Idle Timeout Of A Connection

1. Applicable specification text:

“The use of idle timeouts is in addition to any network protocol level control. Implementations SHOULD make use of TCP keep-alive wherever possible in order to be good citizens.”

Solace implementation:

An event broker will not propose any AMQP idle timeout to its peer. That is, an event broker does not require that the peer sends it periodic AMQP frames in the absence of other traffic from the peer. However, an event broker will honor any idle timeout of at least 500 ms proposed by its peer.

An event broker does use TCP keep-alives on AMQP connections, in accordance with the client-profile associated with the connection’s client.

Section 2.5.1: Establishing A Session

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker will never locally initiate an AMQP session. AMQP clients must remotely initiate any AMQP session to an event broker.

An event broker limits the number of concurrently opened AMQP sessions within an AMQP connection to 255.

An event broker will always assign its lowest available outgoing channel number to a newly remotely initiated session, except that it reserves outgoing channel number 0 for open and close frames, and for back-to-back begin and end frames necessary when the event broker encounters an error during session opening.

An event broker has a system-wide limit on the number of concurrently opened AMQP sessions, equal to the sum of the maximum number of AD ingress flows and AD egress flows allowed by the system.

Section 2.6: Links

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker limits the number of concurrently attached AMQP links within an AMQP session to 575.

An event broker has a system-wide limit on the number of concurrently attached AMQP links, equal to the sum of the maximum number of AD ingress flows and AD egress flows allowed by the system.

Section 2.6.3: Establishing Or Resuming A Link

1. Applicable specification text:

Figure 2.33: Refusing a Link.

Solace implementation:

An event broker reserves local link handle 0 for the purposes of refusing a link. That is, if an event broker refuses a link as illustrated above, the event broker will send its attach frame immediately followed by its detach frame using local link handle 0. An event broker will not use local link handle 0 for any other purpose.

2. Applicable specification text:

“If either end of the link is already associated with a terminus, the attach frame MUST include its unsettled delivery state.”

Solace implementation:

An event broker will never have any unsettled delivery state included in its sent attach frame.

Section 2.6.7: Flow Control

1. Applicable specification text:

"If the link-credit is less than or equal to zero, i.e., the delivery-count is the same as or greater than the delivery-limit, a sender MUST NOT send more messages. If the link-credit is reduced by the receiver when transfers are in-flight, the receiver MAY either handle the excess messages normally or detach the link with a transfer-limit-exceeded error code."

Solace implementation:

An event broker will never offer a link-credit greater than 255 on a link for which it is the receiver.

Section 2.6.12: Transferring A Message

1. Applicable specification text:

“This basic pattern can be modified in a variety of ways to achieve different guarantees. For example if the sending application settles the delivery before sending it, this results in an at-most-once guarantee. The sender has indicated up front with his initial transmission that he has forgotten everything about this delivery and will therefore make no further attempts to send it. If this delivery makes it to the receiver, the receiver clearly has no obligation to respond with updates of the receiver’s delivery state, as they would be meaningless and ignored by the sender.”

and

Figure 2.55: At-Most-Once.

Solace implementation:

An event broker supports at-most-once deliveries of messages for which it is the receiver. An event broker does not support at-most-once deliveries of messages for which it is the sender.

2. Applicable specification text:

“Similarly, if the basic scenario is modified such that the receiving application chooses to settle immediately upon processing the message rather than waiting for the sender to settle first, that yields an at-least-once guarantee. If the disposition frame indicated below is lost, then upon link recovery the sender will not see the delivery-tag in the receiver’s unsettled map and will therefore assume the delivery was lost and resend it, resulting in duplicate processing of the message at the receiver.”

and

Figure 2.56: At-Least-Once.

Solace implementation:

An event broker supports at-least-once deliveries of messages for which it is either the sender or the receiver.

3. Applicable specification text:

“As one might guess, the scenario presented initially where the sending application settles when the receiver reaches a terminal state, and the receiving application settles when the sender settles, results in an exactly-once guarantee. More generally if the receiver settles prior to the sender, it is possible for duplicate messages to occur, except in the case where the sender settles before the initial transmission. Similarly, if the sender settles before the receiver reaches a terminal state, it is possible for messages to be lost.”

Solace implementation:

An event broker does not support exactly-once deliveries of messages.

Section 2.6.13: Resuming Deliveries

1. Applicable specification text:

“Note that in the case where an endpoint indicates that the unsettled map is incomplete, the absence of an entry in the unsettled map is not an indication of settlement. In this case the two endpoints MUST reduce the levels of unsettled state as much as they can by the sender resuming and/or settling transfers that it observes that the receiver considers unsettled. Upon completion of this reduction of state, the two parties MUST suspend and re-attempt to resume the link. Only when both sides have complete unsettled maps can new unsettled state be created by the sending of non-resuming transfers.”

Solace implementation:

An event broker will never have any unsettled delivery state included in its sent attach frame.

Section 2.6.14: Transferring Large Messages

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker applies ingress admission control to received messages from clients of all protocols, including AMQP. Ingress admission control ensures that, if multiple clients are concurrently sending large messages to an event broker, that the event broker’s ingress buffering is not exhausted by a set of clients with partially-sent large messages. If the event broker were to all such ingress buffer exhaustion to occur, no client could make forward progress in completing its message transfer.

AMQP allows a sender to interleave multiple partially-transferred messages on different AMQP links within a single AMQP connection. No other protocol currently supported by the event broker allows this.

AMQP’s potential interleaving of multiple partially-transferred messages requires a change to the event broker’s ingress admission control. Specifically, if the sum of the sizes of all partially-transferred messages within a single AMQP connection exceeds about 64 MiB, the event broker will close the AMQP connection with an error of resource-limit-exceeded.

An event broker will not interleave multiple partially-transferred messages on AMQP links for which it is the sender.

Section 2.7.1: Open

1. Applicable specification text:

channel-max Field Details.

Solace implementation:

An event broker has a channel-max of 255.

2. Applicable specification text:

idle-time-out Field Details.

Solace implementation:

An event broker does not send any idle-time-out.

3. Applicable specification text:

offered-capabilities Field Details.

Solace implementation:

An event broker always sends offered-capabilities of ANONYMOUS-RELAY and sole-connection-for-container.

4. Applicable specification text:

desired-capabilities Field Details.

Solace implementation:

An event broker always behaves as though the client’s desired-capabilities include ANONYMOUS-RELAY. This is because some clients use the event broker’s offered-capabilities of ANONYMOUS-RELAY even though the client does not specify it in its desired-capabilities.

5. Applicable specification text:

properties Field Details.

Solace implementation:

An event broker always sends properties with keys of platform and version, and string values describing the Solace PubSub+ product and version, respectively. It also sends keys of topic-prefix and queue-prefix, and string values of topic:// and queue://, respectively, to be used by clients that support this functionality.

An event broker sends properties with key of amqp:connection-establishment-failed and value of boolean true if the AMQP connection establishment has failed while the event broker processed the open frame received from the client, and the event broker’s transmitted open frame will be followed immediately by a close frame. The client receiving an

open frame with the amqp:connection-establishment-failed property may treat it as a hint that it should expect to receive a close frame immediately afterward.

Section 2.7.2: Begin

1. Applicable specification text:

handle-max Field Details.

Solace implementation:

An event broker has a handle-max of 575.

Section 2.7.3: Attach

1. Applicable specification text:

unsettled Field Details.

Solace implementation:

An event broker always sends a null unsettled map in any sent attach frame.

2. Applicable specification text:

max-message-size Field Details.

Solace implementation:

A software event broker with < 12 GB RAM sends a max-message-size of 10000000 (10 MB). A software event brokers with >= 12 GB RAM, as well as Solace PubsSub+ 3530s and 3560s, send a max-message-size of 30000000 (30 MB).

Section 2.7.4: Flow

1. Applicable specification text:

link-credit Field Details.

Solace implementation:

On a link for which an event broker is the receiver, the event broker will never set link-credit to more than 255.

2. Applicable specification text:

available Field Details.

Solace implementation:

On a link for which an event broker has the sender role, the event broker will the available field to a value greater than zero if the event broker has messages to send on this link. However, the value in the available field may be lower than the actual number of messages the event broker has available to send.

Section 2.7.5: Transfer

1. Applicable specification text:

batchable Field Details.

Solace implementation:

An event broker may take advantage of a received message whose batchable value is true to delay and aggregate multiple transfers’ delivery states into a single subsequent transmitted disposition frame. This may improve the performance of the event broker.

Section 2.8.14: Error

1. Applicable specification text:

info Field Details.

Solace implementation:

An event broker may generate an error with an info map containing two entries. The map entry with key “solace.response_code” will have a uint value with the numeric Solace response code. The map entry with key “solace.response_text” will have a string value with the Solace response text. Both of these are taken from SMF responses internal to the event broker for the internal operation triggering the error.

Section 3.2: Message Format

1. Applicable specification text:

“The bare message is immutable within the AMQP network. That is, none of the sections can be changed by any node acting as an AMQP intermediary. If a section of the bare message is omitted, one MUST NOT be inserted by an intermediary. The exact encoding of sections of the bare message MUST NOT be modified. This preserves message hashes, HMACs and signatures based on the binary encoding of the bare message.”

Solace implementation:

An event broker does not guarantee that it will bit-for-bit preserve the bare message of an AMQP message passing through it.

2. Applicable specification text:

The exact structure of a message, together with its encoding, is defined by the message format. This document defines the structure and semantics of message format 0 (MESSAGE-FORMAT). Altogether a message consists of the following sections:

Zero or one header.
Zero or one delivery-annotations.
Zero or one message-annotations.
Zero or one properties.
Zero or one application-properties.
The body consists of one of the following three choices: one or more data sections, one or more amqp-sequence sections, or a single amqp-value section.
Zero or one footer.

Solace implementation:

An event broker will always send messages whose sections (if present) are in the above order. However, an event broker can receive messages whose sections are in any order.

An event broker does not support message bodies consisting of any number of amqp-sequence sections.

An event broker receiving a message consisting of more than one data sections will concatenate these into a single data section.

Section 3.2.1: Header

1. Applicable specification text:

delivery-count Field Details.

Solace implementation:

An event broker may send a message with a delivery-count of one even though the message may have had more than one previous delivery attempt. That is, the delivery-count of message sent by an event broker should be interpreted more as a flag indicating that the message has had some number of previous delivery attempts, rather than a count of the number of such delivery attempts.

Section 3.2.2: Delivery Annotations

1. Applicable specification text:

"If the delivery-annotations section is omitted, it is equivalent to a delivery-annotations section containing an empty map of annotations."

Solace implementation:

An event broker does not support any delivery-annotations section. An event broker discards any received delivery-annotations section, and will never send any delivery-annotations section.

Section 3.2.3: Message Annotations

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker supports only message-annotations with the following symbol keys:

x-opt-delivery-time
x-opt-jms-dest
x-opt-jms-reply-to
x-opt-jms-msg-type

These are all described in Advanced Message Queuing Protocol (AMQP) JMS Mapping Version 1.0 Working Draft 8.

An event broker discards any other message-annotations in received messages.

Section 3.2.5: Application Properties

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker restricts the number of entries in the application-properties map to a maximum 96.

Section 3.2.7: AMQP Sequence

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker does not support amqp-sequence message sections.

Section 3.2.8: AMQP Value

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker supports amqp-value message sections containing values of types null, string, binary,or symbol.

Section 3.2.9: Footer

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker does not support any footer section. An event broker discards any received footer section, and will never send any footer section.

Section 3.2.15: Address String

1. Applicable specification text:

Entire section.

Solace implementation:

The address-string used to identify a terminus within an event broker will be a queue name or a topic.

JMS address types (durable queue, durable topic, temporary queue, temporary topic) are disambiguated using the x-opt-jms-dest and x-opt-jms-reply-to message-annotations.

For information regarding addressing for Non-JMS APIs, refer to Addressing Support for AMQP Non-JMS APIs.

Section 3.4: Delivery State

1. Applicable specification text:

Entire text.

Solace implementation:

An event broker supports only the accepted, rejected or released delivery states.

Section 3.5.3: Source

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker receiving an attach message with the role of receiver (i.e., the event broker will be the sender) uses one of the following capabilities in the received attach source to determine the messaging service desired by the link:

queue
topic
temporary-queue
temporary-topic

Section 3.5.4: Target

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker receiving an attach frame with the role of sender (i.e., the event broker will be the receiver) uses one of the following capabilities in the received attach target to determine the messaging service desired by the link:

queue
topic
temporary-queue
temporary-topic

An event broker in the receiver role supports the ANONYMOUS-RELAY capability.

Section 4.1: Transactional Messaging

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker does not support transactional messaging.

Section 5.2: TLS

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker does not support TLS session establishment as described in this section (using a protocol header to encapsulate a TLS handshake).

Section 5.2.1: Alternative Establishment

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker only supports TLS session establishment as described in this section (establishing a TLS connection on a separate TCP port, in which AMQP is encapsulated).

Section 5.3.3.1: SASL Mechanisms

1. Applicable specification text:

Entire section.

Solace implementation:

An event broker supports SASL mechanisms of:

ANONYMOUS, when the Message VPN has no authentication enabled;
PLAIN, when the Message VPN has authentication enabled;
EXTERNAL, when the AMQP connection is over TLS and the Message VPN has client-certificate authentication enabled.
XOAUTH2, when the Message VPN has OAuth authentication enabled.

Provide feedback