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 routers 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.

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 Solace router 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:

Solace routers 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:

Solace routers 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, a Solace router first waits for the client to send the protocol header, which may be for protocol 0 (AMQP) or 3 (SASL). The Solace router 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:

A Solace router never initiates an AMQP connection.

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

A Solace router will not open any new AMQP connections from partners if the Solace router has already reached its limit of connected Solace enterprise clients.

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:

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

A Solace router does use TCP keep-alives on AMQP connections, in accordance with the Solace client-profile associated with the connection’s client.

Section 2.5.1: Establishing A Session

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router will never locally initiate an AMQP session. AMQP clients must remotely initiate any AMQP session to a Solace router.

A Solace router limits the number of concurrently opened AMQP sessions within an AMQP connection to 255.

A Solace router 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 Solace router encounters an error during session opening.

A Solace router 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:

A Solace router limits the number of concurrently attached AMQP links within an AMQP session to 575.

A Solace router 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:

A Solace router reserves local link handle 0 for the purposes of refusing a link. That is, if a Solace router refuses a link as illustrated above, the Solace router will send its attach frame immediately followed by its detach frame using local link handle 0. A Solace router 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:

A Solace router 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:

A Solace router 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:

A Solace router supports at-most-once deliveries of messages for which it is the receiver. A Solace router 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:

A Solace router 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:

A Solace router 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:

A Solace router 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:

A Solace router 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 a Solace router, that the Solace router’s ingress buffering is not exhausted by a set of clients with partially-sent large messages. If the Solace router 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 Solace router allows this.

AMQP’s potential interleaving of multiple partially-transferred messages requires a change to the Solace router’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 Solace router will close the AMQP connection with an error of resource-limit-exceeded.

A Solace router 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:

A Solace router has a channel-max of 255.

2. Applicable specification text:

idle-time-out Field Details.

Solace implementation:

A Solace router does not send any idle-time-out.

3. Applicable specification text:

offered-capabilities Field Details.

Solace implementation:

A Solace router always sends offered-capabilities of ANONYMOUS-RELAY and sole-connection-for-container.

4. Applicable specification text:

desired-capabilities Field Details.

Solace implementation:

A Solace router always behaves as though the client’s desired-capabilities include ANONYMOUS-RELAY. This is because some clients use the Solace router’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:

A Solace router always sends properties with keys of platform and version, and string values describing the Solace platform and software version, respectively.

A Solace router sends properties with key of amqp:connection-establishment-failed and value of boolean true if the AMQP connection establishment has failed while the Solace

router processed the open frame received from the client, and the Solace router’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:

A Solace router has a handle-max of 575.

Section 2.7.3: Attach

1. Applicable specification text:

unsettled Field Details.

Solace implementation:

A Solace router always sends a null unsettled map in any sent attach frame.

2. Applicable specification text:

max-message-size Field Details.

Solace implementation:

A Solace router sends a max-message-size of 10000000 (10 MB).

Section 2.7.4: Flow

1. Applicable specification text:

link-credit Field Details.

Solace implementation:

On a link for which a Solace router is the receiver, the Solace router will never set link-credit to more than 255.

2. Applicable specification text:

available Field Details.

Solace implementation:

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

Section 2.7.5: Transfer

1. Applicable specification text:

batchable Field Details.

Solace implementation:

A Solace router 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 Solace router.

Section 2.8.14: Error

1. Applicable specification text:

info Field Details.

Solace implementation:

A Solace router 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 Solace router 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:

A Solace router 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:

A Solace router will always send messages whose sections (if present) are in the above order. However, a Solace router can receive messages whose sections are in any order.

A Solace router does not support message bodies consisting of any number of amqp-sequence sections.

A Solace router 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:

A Solace router 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 a Solace router 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:

A Solace router does not support any delivery-annotations section. A Solace router 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:

A Solace router supports only message-annotations with the following symbol keys:

  • x-opt-app-correlation-id
  • x-opt-app-delivery-time
  • x-opt-app-jms-dest
  • x-opt-app-jms-reply-to
  • x-opt-app-jms-msg-type

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

A Solace router discards any other message-annotations in received messages.

Section 3.2.5: Application Properties

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router 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:

A Solace router does not support amqp-sequence message sections.

Section 3.2.8: AMQP Value

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router supports amqp-value message sections containing values of types null, string, binary, symbol, symbol, or uuid.

Section 3.2.9: Footer

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router does not support any footer section. A Solace router 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 a Solace router will be a queue name or a topic.

There is no further ornamentation (i.e. no prefix of “/QUEUE/” or “/TOPIC/”, no embedded JMS destination type) within the address-string itself. Durable queues have their queue name, without any “#P2P/QUE/” prefix, in the address-string. However, temporary queues and temporary topic endpoints do have prefixes of “#P2P/QTMP/” and “#P2P/TTMP/”, respectively, at the start of their address-string.

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

Section 3.4: Delivery State

1. Applicable specification text:

Entire text.

Solace implementation:

A Solace router supports only the accepted, rejected or released delivery states.

Section 3.5.1: Filtering Messages

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router does not support message filtering.

Section 3.5.3: Source

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router receiving an attach message with the role of receiver (i.e., the Solace router 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:

A Solace router receiving an attach frame with the role of sender (i.e., the Solace router 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

A Solace router in the receiver role supports the ANONYMOUS-RELAY capability.

Section 4.1: Transactional Messaging

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router does not support transactional messaging.

Section 5.2: TLS

1. Applicable specification text:

Entire section.

Solace implementation:

A Solace router 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:

A Solace router 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:

A Solace router 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.