XenQTT

XenQTT Features

XenQTT includes multiple APIs and applications:

• Java MQTT client API
• Clustering proxy
• Mock MQTT Broker

Java MQTT Client API

Overview

The XenQTT library comes with a fully-featured Java MQTT client API. This client allows applications to connect to and interact with an MQTT broker. The client can be used either synchronously or asynchronously.

In synchronous mode all client initiated MQTT interactions block until they complete. For example, the connect method will not return until the CONNECT has been sent to the broker and the CONNACK has been received.

The asynchronous client employs a non-blocking strategy for all messages sent to the broker. A system of callbacks are employed to keep the client informed of various events that arise during the dispatch of messages. The callbacks available to the client are defined in the AsyncClientListener interface.

Both synchronous and asynchronous clients receive publish messages and disconnect notifications via the MqttClientListener interface.

Notes and Caveats

At the current time only QoS 0 (at most once) and QoS 1 (at least once) are supported in the client. It is the intention of the XenQTT team to add QoS 2 (exactly once) support at a later time.

Clustering Proxy

The Proxy allows 1..n MQTT client applications to interact with a single MQTT broker as a single client. The proxy treats all clients that share the same client ID as a cluster. From the clients' perspective they are all talking with the broker. From the broker's perspective it is interfacing with just a single client. The Proxy makes all of this transparent to both end points.

The Proxy is very useful for applications that are deployed in a cluster. Such deployments are often used to meet scaling and/or performance goals. Because of the nature of MQTT, if each clustered application instance connected directly to the broker they would either kick each other off until the last one to connect was the only one connected or they would all connect. Either scenario is bad: one client connected may not be able to handle scaling and performance needs and is a single point of failure while every client getting every message is not usually the desired behavior.

The Proxy solves this problem by managing traffic between the clients and the broker. It ensures messages published to the clients are routed to just one client. It acts as a load balancer, distributing messages across the clients in the cluster.