21

According to the specifications, it is always the client who should establish connection to a server.

Client:

A program or device that uses MQTT. A Client always establishes the Network Connection to the Server. It can

  • Publish Application Messages that other Clients might be interested in.

  • Subscribe to request Application Messages that it is interested in receiving.

  • Unsubscribe to remove a request for Application Messages.

  • Disconnect from the Server.

And if this client subscribes for an Application Message, then the server should forward those messages to this particular client.

Server:

A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions. A Server

  • Accepts Network Connections from Clients.

  • Accepts Application Messages published by Clients.

  • Processes Subscribe and Unsubscribe requests from Clients.

  • Forwards Application Messages that match Client Subscriptions.

Does this mean that if a client subscribes, then it remains connected to the server while the subscription is valid even though there are no data flow in most of the time?

I come to this conclusion because if the client disconnects after subscription, then a server cannot forward messages to it because it is the client that should establish connection. But it won't know when to re-establish it.

Improve this question

3 Answers 3

Reset to default
11

Does this mean that if a Client subscribes, then it remains connected to the server while the subscription is valid even though there are no data flow in most of the time?

Yes, once the connection is made the client will wait for messages, however it will also send PING messages to the server regularly based upon the keepalive value. If a PING message is not received by the server then it may disconnect you.

if the Client disconnects after subscription, then a server cannot forward messages to it because it is the Client that should establish conenction.

If the client is disconnected then yes, it will not receive messages, however there are features in MQTT that work around this.

If the client connects to the server with the 'Clean session' flag set to false, then the server will remember the subscription for that client ID. Once the client reconnects, it will not need to re-subscribe as the server will have remembered it.

Furthermore, you can subscribe using QoS Level 1 or 2. With these QoS Levels, the Server will store messages and wait for the client to reconnect before sending them on. This way, even if the client disconnects and reconnects they will still receive all published messages.

This site has some good resources explaining the MQTT protocol.

Improve this answer
9

Does this mean that if a Client subscribes, then it remains connected to the server while the subscription is valid even though there are no data flow in most of the time?

Yes, your client will wait for messages.

... if the Client disconnects after subscription, then a server cannot forward messages

You have to manage disconnection (especially in battery powered devices). This can be done using the "last will and testament" feature of MQTT : when a device disconnects it will send a last message.

Improve this answer
1

You should differentiate connection and session.

Everything is defined by the session. When MQTT connection is authorized to the broker first time, broker creates session for this connection, usually based on client-id connection parameter.

In MQTT 3.1.1 protocol (default currently in most clients/brokers) during connection you may specify clean=true or clean=false flag. If clean=true then broker will automatically create new session and close it when connection is broken/closed. If clean=false, broker will maintain session and deliver there events (into some kind of session storage) even when client disconnected. It depends on the brokers implementation if it allow clean=false session at all and what is maximum ttl of such session.

In MQTT 5.0 protocol (very fresh, but perspective) it is possible to specify session ttl from client side or even change it after connection has been made. This is extremely useful for unstable WAN connections(IoT mostly) or stateful connections like you described.

AFAIK currently MQTT 5.0 protocol from client perspective can be used in python with gmqtt and in javascript with mqtt.js.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.