Direct Messages

Direct messaging provides a reliable, but not guaranteed, delivery of messages from the Solace message bus to consuming clients, and is the default message delivery system for Solace PubSub+. It doesn't require any configuration beyond that required to set up and start other features. By default, direct messaging is always available to all clients connecting to an event broker.

Characteristics of direct messages

  • Delivered to subscribing clients in the order in which publishers publish them.
  • Don't require acknowledgment of receipt by subscribing clients.
  • Aren't spooled on the message bus for consuming clients.
  • Aren't retained for a client when it's not connected to an event broker.
  • Can be discarded when congestion or system failures are encountered.

Typical applications

  • Extremely high message rates and extremely low latency are required.
  • Consuming clients can tolerate message loss in the event of network congestion.
  • Messages don't need to be persisted for later delivery to slow or offline consumers.
  • Messages must be efficiently published to a large number of clients with matching subscriptions.

Situations where direct messages aren't delivered

  • A client disconnects from an event broker while messages are being published.
  • A client fails to consume messages at the published rate and egress message buffer overflow results.

Shared Subscriptions

Shared subscriptions can be used to load balance large volumes of client data across multiple instances of back end data center applications. They are especially useful in situations where those applications parallelize the processing of published messages.

To control whether a client may create or join in a shared subscription, the allow-shared-subscriptions attribute in the client’s client-profile is set to the desired value. For more information, see Allowing Shared Subscriptions.

Syntax of Shared Subscriptions

A shared subscription has the form:

#share/<ShareName>/<topicFilter>

Where:

  • ShareName is the identifier associated with the shared subscription. It may not contain * or >.
  • topicFilter is the topic filter.

Shared subscriptions are exported (advertised by the local node to other nodes in the network) by default. To prevent this export, start the shared subscription with #noexport, as follows:

#noexport/#share/<ShareName>/<topicFilter>

Where:

  • ShareName is the identifier associated with the shared subscription. It may not contain * or >.
  • topicFilter is the topic filter.

For more information, see Preventing Subscription Export and the #noexport entry of the table in Reserved Topics.

How Shared Subscriptions Work

To illustrate how shared subscriptions work, consider the following example:

  • #share/ottawa/weathersensor/yow/temperature

A number of clients are subscribing to #share/ottawa/weathersensor/yow/temperature. When a message is published to weathersensor/yow/temperature one of those clients will be randomly chosen to receive the message. For example, for each message that arrives that matches weathersensor/yow/temperature, a new random choice is made as to which subscribing client will receive the message. With a large enough number of messages, n, to subscribing clients, m, the number of messages delivered to each subscriber evens out to approximately n/m.

Shared Subscription Identifiers

A ShareName is included in a shared subscription so that there can be more than one shared subscription on an event broker that has the same topicFilter.

For example, consider the following shared subscriptions, which differ only by ShareName:

  • #share/weatherapp/weathersensor/*/temperature
  • #share/temperaturelog/weathersensor/*/temperature

Although the shared subscriptions have the same topicFilter, they are unique. When a message is published to weathersensor/yow/temperature, and a number of clients are subscribing to #share/weatherapp/weathersensor/*/temperature, one of those clients will be randomly chosen to receive the message. Likewise, from all the clients subscribing to #share/temperaturelog/weathersensor/*/temperature, one of those clients with that subscription will be chosen at random to receive the message.

In typical use, application instances wishing to share messages on a subscription agree upon a ShareName to use in the shared subscription. Messages whose topics match the shared subscription are then randomly distributed between those application instances.

Feature Interactions

Guaranteed Messaging

Shared subscriptions are not allowed on queues and will be rejected, whether they are configured or signaled in.

Eliding

When a client, whose client-profile indicates eliding is being used, adds a shared subscription, eliding won't be performed on messages matching the shared subscription.

Class-of-Service

Direct Messaging Class of Service (CoS) is always handled as COS1 when being delivered on a shared subscription, regardless of the message’s CoS.

No Local Sessions

Shared subscriptions ignore the no-local attribute of a session. If a client adds a shared subscription on a no-local session, messages published on that session are eligible for delivery on the same session via the shared subscription.

API LocalDispatchOnly subscriptions

Shared subscriptions cannot be added as API LocalDispatchOnly subscriptions. If an application is trying to create a shared subscription limited in scope to a single session, use some randomly generated content within the shared subscription’s sharedSubID that would be unknown to other applications.

PubSub+ Cache

Shared subscriptions are not supported as being configurable against PubSub+ Cache.

Dynamic Message Routing (DMR) and Multi-Node Routing (MNR)

Shared subscription topic filters are exported. This attracts traffic that matches the shared subscription from other nodes, but it doesn't have the effect of a distributed shared subscription. If a remote node has the same shared subscription, they are treated as different shared subscriptions, where one member of the group on each node will receive a copy of a published message that matches the shared subscription.

Message Eliding

Message eliding allows client applications to receive only the most current Direct messages published to topics that they subscribe to, at a rate they can manage, rather than queue up outdated messages. It can be useful in situations where there are slow consumers, or where a slower message rate is required. Only Direct messages can be elided.

To use message eliding:

  • Client applications must flag published message as eligible for message eliding.
    • Although only a Direct message can be elided, it is possible for a publishing client to flag a persistent or non-persistent message as eliding‑eligible. However, the message will not be elided unless the delivery mode of the message is changed to Direct. This could happen if the persistent or non-persistent message is published to a topic that matches a client’s topic subscription. In that case, to accommodate the client topic subscription, the message is changed to Direct; it can then be elided.
    • All messages published by MQTT client applications are treated as non‑eliding eligible.
  • A receiving client application must be assigned a client profile through its client username that permits it to:
    • Use message eliding
    • After the first message, receive subsequent messages with a time delay interval. The delay interval, which is configured in the client profile, controls the rate of message updates sent to a client on a topic-by-topic basis (for example, five messages per second per topic).
    • Receive up to the maximum number of topics the event broker can track for performing the eliding function on each client connection (up to 32,000 per client as configured in the client profile, with a total of 2,000,000 per event broker; the default is 256 per client). Once the maximum number of topics is reached, the event broker ages out the elided topics for the client to prevent the consumption of more eliding resources than have been allocated for the connection. Eliding behavior then continues as if this were a new client connection, and a one-time Syslog event is generated on a per client basis.
      • Event brokers dynamically track the number of topics on a client connection. Whenever this number is below the set maximum, eliding is applied to the new incoming messages.
      • For subscribers with wildcard subscriptions, each topic that matches the subscription is elided, up to the maximum number of subscriptions specified by the client profile.
      • It's recommended that consuming clients don't use discard indications when using message eliding. In a situation where an event broker’s egress priority queue for a client fills up with received messages, the oldest messages on the egress queue are discarded to make room for newly arriving messages, and the message at the head of the queue is flagged with the discard indication. However, if eliding is enabled, that message could be elided, and the client would not receive the discard indication.

How Message Eliding Works

The following example shows how message eliding works:

  1. Client P is publishing messages on topic T at a rate of one message per millisecond; each message is flagged as eliding-eligible.
  2. Consuming Client S is assigned a client profile that has eliding enabled, and has an eliding delay of 200 ms, which imposes a cap of five updates per second per topic.
  3. When the first message, M1, for topic T arrives at the event broker for client S, it's sent to the client without any delay, assuming the TCP window is open.
  4. When message M2 for topic T arrives a moment later at the event broker for subscriber S, it's held by the event broker, but not sent to the client since there has already been a message (that is, M1) for this same topic sent within the 200ms delay time.
  5. When subsequent messages, M3, M4, .... Mn, arrive at the event broker for client S, each newer message replaces the previous message and is continuously held by the event broker.
  6. Then 200ms after the previous message was sent for Client S, the held message is then sent to that client, assuming the TCP window is open.

Eliding Use Cases

Use cases for this feature include:

  • Eliding for congestion management

    A client application wants to receive every message provided it is able to keep up with the message flow. If the client cannot keep up, then any queued messages can be elided to provide only the most recent message for each topic. For this use case a delay interval time of 0 is set.

  • Eliding for Message Rate Control

    A client application wants to receive at most five messages per second per topic. In this case, the event broker rate controls the output of messages to it. For this use case a delay interval time of 200 ms (that is, five messages per second per topic) is set.

Some example uses are:

  • Streaming market data to human traders

    Even though market data updates might be published at a very high rate, humans can only deal with a few updates per second. The client always wants the latest information, but at a slower rate than the total feed rate. Message eliding can be used to limit the output stream to a few updates per topic per second.

  • Controlling update rates to subscribers over a Wide Area Network (WAN)

    Sometimes, WAN bandwidth versus receiver processing capacity require that only a subset of the entire feed rate be provided over the WAN. Message eliding can be used to control the message update rates to a client.

Managing Client Subscriptions

Once clients are authenticated on the event broker they can add and remove topic subscriptions for Direct messages published to the Message VPN to which they have connected. These topic subscriptions are not durable - the clients’ subscriptions are not maintained for them after they disconnect from the event broker.

A client typically performs the following steps for managing their own subscriptions:

  1. The client connects to the event broker and authenticates itself. At this point, the event broker has no subscriptions for that client.
  2. The client adds subscriptions to the event broker.
  3. The client receives messages that match the requested subscriptions.
  4. When the client disconnects from the event broker, it immediately removes all subscriptions associated with that client.

The topics that a client is permitted to subscribe to can be limited by an ACL assigned to the client username account used by the client. For more information, refer to ACL Configuration.

Managing Subscriptions on Behalf of Other Clients

A client application can manage subscriptions on behalf of other clients within a Message VPN when its client username is configured to be a Subscription Manager (see Configuring Subscription Managers ). This is useful for centralizing the assignment of a Message VPN's clients and services to direct messaging subscriptions. However, it should be noted that a Subscription Manager has no control over guaranteed messaging.

When a client is configured as a Subscription Manager, the subscriptions that it manages are subject to the access control permissions configured on that client’s associated Access Control List (ACL) profile - the ACLs of destination clients are not used. So, the client configured as a Subscription Manager can't add or remove subscriptions that its own ACL rules would deny adding. This prevents it from inadvertently adding or removing subscriptions that it's not entitled to.

When a client is configured as a Subscription Manager, other clients within the Message VPN typically perform the following steps for managing their subscriptions:

  1. The client connects to the event broker.
  2. The client notifies the Subscription Manager that it's ready to receive messages.
  3. The Subscription Manager authenticates the client, determines the subscription set needed by the client, and adds subscriptions to the event broker on behalf of the client.

    Subscriptions added by the Subscription Manager on behalf of the client have the same subscription rate (subscriptions per second) as those added by the client directly for itself.

  4. The client receives messages that match the associated subscription set.
  5. Once the client is done, it disconnects, and its associated subscription set is deleted from the event broker.

Once subscriptions have been added by a Subscription Manager on behalf of another client, they behave like any other subscriptions (for example, the subscriptions are removed if the client is disconnected). Disconnecting the Subscription Manager has no effect on the subscriptions already added by it.

For information on how clients using Solace APIs can act as Subscription Managers to add and remove subscriptions on behalf of others, see Managing Topic Subscriptions on Behalf of Other Clients.