Expand Collapse
Just a second...

Client reconnection

You can configure the client reconnection feature by configuring the connectors at the Diffusion™ server to keep the client session in a disconnected state for a period before closing the session.

Normally when a client application loses its connection to the server, perhaps due to some communications error, the only option is for it to connect again and then re-establish the state of the topics to which it was subscribed. There is however, the facility for clients to be able to reconnect a lost connection without losing its topic state or messages that were queued for it whilst it was not connected.

This can be useful for mobile clients where connections are less reliable.

Server configuration

To enable clients to reconnect, connectors must be configured to keep client sessions in the DISCONNECTED state for a period during which the client can reconnect. To do this a reconnection timeout must be specified for the connector.

Specify a reconnection timeout, maximum queue depth, and recovery buffer size by using the <reconnect> element in the etc/Connectors.xml configuration file.
Reconnection timeout (keep-alive)
How long a disconnected client's session remains available on the server before being closed. By default, this is 60 seconds.
Maximum queue depth (max-depth)
Optional maximum limit on the number of messages to queue for a disconnected client session. By default, this is the same as the queue depth for a connected client session, which is defined by the queue definitions in Connectors.xml and Server.xml.
Recovery buffer size (recovery-buffer-size)
The maximum number of sent messages to keep in a buffer. These messages can then be recovered on reconnection.
<connector>
	...
	<reconnect>
		<keep-alive>60s</keep-alive>
		<max-depth>1000</max-depth>
		<recovery-buffer-size>64</recovery-buffer-size>
	</reconnect>
	...
</connector>
A client can reconnect to the server through this connector within 60 seconds of becoming disconnected. While the client is disconnected, up to 1000 messages are queued for it. These messages are delivered to the client when it reconnects. A buffer of up to 64 sent messages are retained in the recovery buffer. When a client reconnects, the Diffusion server use this buffer to re-send any messages that the client has not received.

If a client signals that it wants to disconnect, the client state on the server is removed when the client disconnects. However, in all other circumstances where the client loses connection, the client goes into the DISCONNECTED state, where the subscriptions are retained and messages are queued as normal for the amount of time specified by the reconnection timeout of the connector.

If the server is configured to expect reconnecting clients, clients that are currently disconnected and might reconnect are excluded from the regular system pings that the server sends to clients.

If the client then reconnects during the period that the session is in DISCONNECTED state, the sending of messages to the client resumes from the point when the failure occurred. Messages that were in transit at the time of disconnection might be lost.

The only way to ensure the delivery of messages on reconnection is for the publisher to mark the messages as requiring acknowledgment as any such messages that have been sent but not acknowledged on reconnection are requeued for the client. The delivery of acknowledged messages is assured. However, because an ack from the client might have been lost during the disconnection, there is the possibility that a message might be delivered to the client twice in this scenario.

It is important when using acknowledged messages to ensure delivery after reconnect that the ack timeout set for messages is sufficiently long to allow for the time that a message can be queued for a client plus the reconnection timeout configured for reconnection.

If an ack timeout expires before a message is even dequeued for a client, the non-acknowledgment is notified and the message is not sent to the client.

Message queue management

Managing message queues when using client reconnection

When a client session is in DISCONNECTED state, messages for the client continue queuing for the client until the reconnection timeout expires or the client reconnects. This puts an unusual load on the client queue and the facility exists to adjust the maximum client queue depth for the period of disconnection.

This is done by specifying a queue depth which is greater than the normal maximum queue depth. When disconnected the queue can expand to the higher value and when reconnection occurs and the queue starts to drain, when the queue size goes down to a value of 80% of its previous limit, the maximum queue depth reverts to the normal value.

The queue depth has an effect only if it represents a value higher than the normal maximum queue depth.

Client reconnection

Configuring the reconnection of clients

Not all clients support reconnection but those that do have a reconnect method which they can call on notification of a lost connection.

If the reconnection succeeds, the client is subscribed to all of the same topics as before and starts to receive messages again, including all of those queued whilst the client was disconnected.

Messages in transit at the time of disconnection might be lost, however any message marked as requiring acknowledgment and sent by the server that was not acknowledged by the client is retransmitted on reconnect. The delivery of acknowledged messages from client to server is assured on reconnect although there is the possibility that the client might receive a message it had acknowledged before the connection again after reconnection if the ack had never reached the server.

A reconnection might not succeed, either because a reconnection timeout is not specified on the connector that the client has connected to, or the specified time period has expired. In this case a normal new connection is established with the same topic set as was specified on the original connection.

How to test reconnection in my environment?

To simulate a communication error, we use a proxy between the client and the server.

  • Start Diffusion. (By default it uses port 8080)
  • Set the proxy to listen on a different port (for example, 9090) and redirect the connection to 8080
  • Connect the client through the proxy on port 9090.
  • Kill the proxy.
  • Start the proxy.
  • Reconnect the client.
Figure 1. Reconnection scenario
Flow diagram of a connection through a proxy and subsequent reconnect. The client sends a can connect request to the proxy. The proxy relays the can connect request to the Diffusion server. The Diffusion server responds "Yes" and sends the client ID to the proxy. The proxy relays this information to the client. In the event of a disconnection, the proxy sends and IO error to the client and to the Diffusion server. THe client sends a reconnect request that includes its client ID to the proxy. The proxy relays the reconnect request to the Diffusion server. If the client can reconnect, the Diffusion server responds "Yes" and sends the client ID to the proxy. The proxy relays this response to the client.

Note: The proxy behaviors are different depending on the operating system and the TCP/IP stack configuration.

Common errors

  1. From the client, request a connection close and call reconnect.

    After a close request, the client cannot reconnect. In this case, the client will establish a new connection with a different client ID assigned by Diffusion.

  2. Unplug the network wire from the computer where the client is running

    This will not throw an IO_ERROR in the other end of the connection.

This page last modified: 2016/09/23