Throttling and Limits

CPU, memory and bandwidth are limited resources. It can be crucial to limit the bandwidth or the maximum TCP connections HiveMQ can accept to save resources and avoid abuse by malicious clients.

All throttling and limit properties reside in the config.xml file, which has a restrictions element where all global throttling can be configured.

Limiting connections

You can apply a global connection limit to HiveMQ. That means, after a defined number of open MQTT connections, HiveMQ automatically inhibits new client connections. Limiting the connections can be pretty handy if your server hardware resources are limited.

By default, the max-connections property is set to -1, which means HiveMQ can handle unlimited connections (setting the property to 0 also results in unlimited connections). [1].

Table 1. Available limiting connections configurations
Option Default Value Description

max-connections

-1 (unlimited)

The maximum allowed MQTT connections.

The following example shows how to configure HiveMQ to allow a maximum of 100 concurrent connections:

Limiting concurrent connections
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
   <restrictions>
       <max-connections>100</max-connections>
   </restrictions>
    ...
</hivemq>

If there are multiple listeners configured, be aware that the concurrent connections are global for this HiveMQ instance.

Connection Limits
If you set a connection limit which is higher than the connection limit defined by your license, the higher limit will have no effect and the lower of the two limits will be used.

Throttling connection rates

This is a HiveMQ Enterprise Edition feature. Find out more about HiveMQ Editions.

The rates of allowed MQTT CONNECT packets per second can be configured.

The <connect-overload-protection> tag enables the connect overload protection feature of HiveMQ per listener. This is useful if your deployment makes use of extended authentication and/or authorization systems that can only handle a certain average rate of authentications per second.

If this feature is enabled HiveMQ will accept MQTT CONNECT messages only at the configured <connect-rate> over a sustained period of time. HiveMQ will allow short time bursts of CONNECT events up to the <connect-burst-size>. If this limit is reached and there are still incoming CONNECT messages above the rate HiveMQ will temporary stop reading from new sockets and finally disconnect newly connecting clients.

Table 2. Available connect overload protection configurations
Option Required Default Value Description

connect-rate

true

-1

The maximum sustained rate of connects that the listener is able to handle per second. This depends to a large amount on the system and the authentication logic.

connect-burst-size

false

<connect-rate> * 2

The maximum amount of simultaneous arriving CONNECT messages that the listener will accept and process. This can not be set to 0 (zero).
Connect overload protection example xml
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <listeners>
        <tcp-listener>
            <port>1883</port>
            <bind-address>0.0.0.0</bind-address>
            <connect-overload-protection>
                <!-- 2000 C/s == 2C/ms -->
                <connect-rate>2000</connect-rate>
                <connect-burst-size>4000</connect-burst-size>
            </connect-overload-protection>
        </tcp-listener>
    </listeners>
   ...

</hivemq>

Throttling SSL handshakes

This is a HiveMQ Enterprise Edition feature. Find out more about HiveMQ Editions.

The number of SSL handshake operations per listener that can occur concurrently can be configured.

The <concurrent-handshake-limit> setting can be used to limit the amount of concurrently occurring SSL handshakes. This can work as an overload protection for the broker during bulk (re)-connection scenarios.

Table 3. Available ssl handshake overload protection configurations
Option Required Default Value Description

concurrent-handshake-limit

false

-1

The maximum number of SSL handshakes, that can be in progress at any time (set to a positive non zero integer to activate)
SSL handshake overload protection example xml
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

        <listeners>
            ...
            <tls-tcp-listener>
                <port>8883</port>
                <bind-address>0.0.0.0</bind-address>
                <name>my-secure-tcp-listener</name>
                <tls>
                    <keystore>
                        <path>/path/to/the/key/store.jks</path>
                        <password>password-keystore</password>
                        <private-key-password>password-key</private-key-password>
                    </keystore>
                    <!-- Allow a maximumn of 500 concurrent SSL handshakes for this listener -->
                    <concurrent-handshake-limit>500</concurrent-handshake-limit>
                </tls>
            </tls-tcp-listener>
        </listeners>
   ...

</hivemq>

Throttling bandwidth

You can configure HiveMQ to globally throttle the incoming network traffic for MQTT clients if you don’t want to reserve all your bandwidth for HiveMQ or if you want to artificially slow down all clients.

Throttling message throughput
A convenient way of limiting the message throughput of HiveMQ when you have many subscribers is to throttle the incoming traffic. If your system resources such as CPU and RAM are at premium this is an efficient and quick way to limit the maximum incoming messages. A sane global throttling by default can prevent resource exhaustion.

Available throttling bandwidth configurations

Option Default Value Description

incoming-bandwidth-throttling

0 (unlimited)

The maximum incoming traffic as bytes per second (b/s).

The following example makes the incoming traffic unlimited.

Limiting bandwidth
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
   <restrictions>
        <incoming-bandwidth-throttling>0</incoming-bandwidth-throttling>
   </restrictions>
    ...
</hivemq>

Connection Timeouts

MQTT, as layer 7 protocol in the OSI layer model, relies on TCP and so it’s required for clients to open a TCP connection before they can send a MQTT CONNECT message to initiate the MQTT connection.

The fact that MQTT operates at application layer means that just because a client initiates a TCP connection, doesn’t necessarily mean that it initiates a MQTT connection. So malicious MQTT clients could drain server resources by opening a TCP connection and never initiating a MQTT connection by sending a MQTT CONNECT message. These kind of clients can attack your MQTT broker by draining all system resources (like memory) quickly.

To avoid these kind of attacks, it’s important that you disconnect clients which don’t initiate a MQTT connection as soon as possible.

HiveMQ by default waits 10 seconds for the CONNECT message of a client before it closes an open TCP socket. You can tune this behaviour to your application needs.

Available throttling bandwidth configurations

Option Default Value Description

no-connect-idle-timeout

10

The time in seconds where HiveMQ waits for a CONNECT message of a client before it closes an open TCP socket.
Change the idle timeout
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
    <!-- Disconnect idle clients after 10 seconds -->
    <restrictions>
        <no-connect-idle-timeout>10000</no-connect-idle-timeout>
    </restrictions>
    ...

</hivemq>
Clients with a slow connection
If you have clients which use a network with very high latency, a few seconds might not be enough and these clients could get disconnected although they try to send a CONNECT message. So make sure the timeout fits your use case.

Restrict MQTT Client ID Length

You can configure HiveMQ to only accept MQTT-client IDs up to a certain length. If a client tries to connect with an MQTT client ID that is longer than the 'max-client-id-length', the broker rejects the connection attempt. The maximum number of characters that HiveMQ can accept in an MQTT Client ID is 65535. The default setting for 'max-client-id-length' is 65535. The minimum value for 'max-client-id-length' is 1. If you configure a value less than 1 or more than 65535, HiveMQ uses the default value of 65535.

Option Default Value Description

max-client-id-length

65535

The maximum number of characters HiveMQ accepts in an MQTT-client ID
Change the max client ID length
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    ...
    <!-- allow clients that have identifiers with up to 1000 characters-->
    <restrictions>
        <max-client-id-length>1000</max-client-id-length>
    </restrictions>
    ...

</hivemq>

Restrict Topic Length

You can configure HiveMQ to only accept topic strings up to a certain length. If a client tries to publish with a topic that is longer than the 'max-topic-length', the broker rejects the publish attempt. The broker also rejects subscriptions with topic filters that are longer than the configured 'max-topic-length' value. The maximum number of characters that HiveMQ can accept in a topic string is 65535. The default setting for 'max-topic-length' is 65535. If you configure a value less than 1 or more than 65535, HiveMQ uses the default value of 65535.

Option Default Value Description

max-topic-length

65535

The maximum number of characters HiveMQ accepts in a topic string
Change the max topic length
<?xml version="1.0"?>
<hivemq xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <!-- allow topic strings with up to 1000 characters -->
    <restrictions>
        <max-topic-length>1000</max-topic-length>
    </restrictions>
    ...

</hivemq>
1. This is only true if your license allows unlimited connections. Otherwise, you are restricted to the maximum connections which is defined by your license