Reliable messaging

The reliable messaging feature improves the quality of message delivery between clients and destinations on the LiveCycle Data Services server.

Reliable messaging provides the following benefits above what is provided with standard messaging:

Benefit	Description
No message loss	No messages are lost when transient network failures occur if the AdvancedChannelSet object's immediate reliable reconnect attempt succeeds. If this single attempt fails the reliable sequence is closed and the client proceed to regular channel failover and channel set hunting.
Ordered message delivery	Reliable messaging ensures the delivery of correctly ordered messages when using AMF or HTTP channels/endpoints that use more than one TCP socket concurrently to send or receive messages. Message order is ensured even if the intended order differs from the order in which the messages are received from the network. When you use RTMP channels/endpoints, messages are delivered in the correct order whether you use reliable messaging.
No duplicate message processing	There is no duplicate processing of messages even when messages for reliable destination are automatically sent following a disconnect and reconnect.
Reconnection to server following unexpected connection loss	For deployments where network connections are forced to close periodically, reliable messaging allows the client to seamlessly reconnect to the same server. The client resumes exactly where it left off, as long as the server has not crashed, or exited. A single reliable reconnection is attempted immediately following connection loss. This reconnection attempt allows the reliable connection to survive due to an idle timeout or when firewalls, proxies, or other network components force a TCP connection to close periodically. If this single attempt fails, the reliable sequence is closed and the client proceeds to regular channel failover and channel set hunting. The feature currently does not support repeated reliable reconnect attempts.

Note: To use reliable messaging, you enable advanced messaging support.

To enable reliable messaging, you set the reliable property to true in the network properties section of the destination definition, as the following example shows:

... 
<destination id="trade-settlement"> 
    <properties> 
        <network> 
            <reliable>true</reliable> 
        </network> 
    </properties> 
</destination> 
...

By default, if a channel was successfully connected before experiencing a fault or disconnection, it attempts a pinned reconnection to the same endpoint URL once. If this immediate reconnection attempt fails, the channel falls back to its previous failover strategy and attempts to fail over to other server nodes in the cluster or fall back to alternate channel protocols. To support IP mobility use cases, the AdvancedChannelSet object provides the following property that you can assign in ActionScript code to extend the time duration for reliable reconnect attempts to continue. One such use case is undocking a laptop and waiting several seconds for its wireless modem to start up and acquire network connectivity and a new IP address.

advancedChannelSet.reliableReconnectDuration = 60000; // In milliseconds.

The default value is 0. The default behavior is to try a single, immediate reliable reconnection. By assigning a value larger than 0, you give the AdvancedChannelSet more time to attempt to reconnect reliably more than once.

You can also set this value statically in the services-config.xml file within the flex-client section, as the following example shows:

... 
<flex-client> 
<reliable-reconnect-duration-millis>60000</reliable-reconnect-duration-millis> 
<!-- Idle timeout for FlexClient state at the server, including reliable messaging sequences. 
In order to support reliable reconnects consistently across all supported channels and 
endpoints, this value must be defined and greater than 0. 
Note: Any active sessions/connections keep idle FlexClient instances alive. This timeout 
only applies to instances that have no currently active associated sessions/connections. 
--> 
<timeout-minutes>1</timeout-minutes> 
</flex-client> 
...

Note: If you do not define an explicit FlexClient timeoutand at least one RTMP endpoint is registered with the message broker, the server uses a default timeout of 5 seconds for FlexClient timeout. This allows reliable messaging over RTMP to work with no configuration other than setting destinations as reliable. If you want to use a longer reliable reconnect interval, use the optional timeout-minutes and reliable-reconnect-duration-millis elements within the flex-client section of services-config.xml file.

Standard behavior without reliable messaging

RTMP channels use a single TCP connection and never deliver messages to the server out of order whether you enable reliable messaging. However, standard AMF channels do not guarantee in-order delivery of sent messages. Server-to-client AMF messages are rolled up into a batch and sent as binary body content in an HTTP POST when Flash Player is able to issue a request. Within a batch, AMF messages are guaranteed to be delivered for processing on the server in order. However, there is a slim chance that clients on slow networks could put themselves into a conflict state unintentionally due to separate HTTP requests that contain individual batches of AMF messages arriving at the server out of order. Nothing in Flash Player or in standard AMF channels prevents sending more than one HTTP request containing a batch of AMF messages at a time. Standard HTTP channels use a unique URLLoader for each message sent, but they serialize the flow of sent messages and only send a subsequent message after an ack (acknowledgement) or fault for the previous message is received. These channels lack the efficiency introduced by the batching behavior of the AMF channels, but they do guarantee in-order message delivery during regular operation.

RTMP channels use a single TCP connection and never receive messages from the server out of order whether you enable reliable messaging. However, standard AMF and HTTP channels sometimes issue concurrent HTTP requests over multiple TCP connections. Polling or streaming, which simulates a duplex connection by overlapping of concurrent HTTP requests more of the time sometimes exacerbates this situation. Standard AMF and HTTP channels provide no guarantee for delivery order across reply messages and pushed messages because data arrives at the client over separate connections concurrently.

Received messages are either replies (acknowledgements/results/faults) for sent messages or they are pushed messages generated by other clients, backend processes, or the server directly. All reliable messages traveling from the server to the client's AdvancedChannelSet object belong to a common sequence. As messages are received, the AdvancedChannelSet object uses a reliable receive buffer to re-order them if necessary, and any in-order messages are removed from the buffer and dispatched to application code. Reply messages are dispatched to the acknowledgment or fault handler of the component that sent the correlated request message. Pushed messages are dispatched to any listeners that have registered for MessageEvents.

Regardless of the runtime message ordering behavior for the various standard channels discussed here, none of these channels can seamlessly survive a transient network disconnect event on its own. By enabling reliable messaging, the channel and server endpoint enforce a guarantee of in-order, once-and-only-once message delivery between the client and server that survives any transient disconnect followed by a successful reconnect to the same server.

Important: There is a trade-off between quickly detecting that clients have disconnected versus supporting long reliable reconnect durations. For applications where timely server detection of clients disconnecting is important, leave the reliable reconnect duration at its default setting or use a short duration value based on the requirements of your application. For applications where you want to favor reliable reconnections, you can tune this value higher.