Required. Each server URI specifies the address of a server that the client may connect to. Two types of connection are supported: tcp:// for a TCP connection and ssl:// for a TCP connection secured by TLS/SSL. For example:

• tcp://localhost:1883
• ssl://localhost:8883

If the port is not specified, it will default to 1883 for tcp:// URIs, and 8883 for ssl:// URIs. 

When an attempt to connect is initiated, the client will start with the first server URI in the list and work through the list until a connection is established with a server. If a connection cannot be made to any of the servers then the connect attempt fails. 

Specifying a list of servers that a client may connect to has several uses:

• High Availability and reliable message delivery
• Some MQTT servers support a high availability feature where two or more "equal" MQTT servers share a state. An MQTT client can connect to any of the "equal" servers and be assured that messages are reliably delivered and durable subscriptions are maintained no matter which server the client connects to.
• The “clean session” flag must be set to false if durable subscriptions and/or reliable message delivery is required.
• Hunt List
• A set of servers may be specified that are not "equal" (as in the high availability option). As no state is shared across the servers reliable message delivery and durable subscriptions are not valid. The “clean session” flag must be set to true if the hunt list mode is used

Client ID. If not specified, a randomly generated client identifier based on  the fixed prefix (paho-) and the system time.   

A client identifier must be less than 65535 characters. It must be unique across all clients connecting to the same server. The clientId is used by the server to store data related to the client, hence it is important that the clientId remain the same when connecting to a server if durable subscriptions or reliable messaging are required. 

The best practice is to specify a unique Client ID if you are using durable/reliable messaging. If not, you can leave this field blank and allow it to be automatically generated.

Default value: [None]

MQTT servers that support the MQTT v3.1 protocol provide authentication and authorization by username and password. This is the username parameter.

Default value: [None]

MQTT servers that support the MQTT v3.1 protocol provide authentication and authorization by username and password. This is the password parameter.

Default value: [None]

The time interval in seconds to allow a connect to complete.

Default value: 30

This is a boolean value. The setting controls the behavior of both the client and the server at connection and disconnection time. The client and server both maintain session state information. This information is used to ensure "at least once" and "exactly once" delivery, and "exactly once" receipt of messages. Session state also includes subscriptions created by an MQTT client. You can choose to maintain or discard state information between sessions.

When set to true (selected), the state information is discarded at connect and disconnect. Setting Clean Session to false keeps the state information. When you connect an MQTT client application, the client identifies the connection using the client identifier and the address of the server. The server checks whether session information for this client has been saved from a previous connection to the server. If a previous session still exists, and this setting is true, then the previous session information at the client and server is cleared. If this setting is false, the previous session is resumed. If no previous session exists, a new session is started.

Default value: Selected

The "keep alive" interval, measured in seconds, defines the maximum time that should pass without communication between the client and the server. The client will ensure that at least one message travels across the network within each keep alive period. In the absence of a data-related message during the time period, the client sends a very small MQTT "ping" message, which the server will acknowledge. The keep alive interval enables the client to detect when the server is no longer available without having to wait for the long TCP/IP timeout.

Default value: 60