How to Find Connected MQTT Client Details

17
votes

Is there any way we can find about all the connected client details(IP & name) from another client? I know there is a topic "$SYS/broker/clients/active" which gives the number of currently connected clients but if I want to know more about each connected client, is there any way?

I'm developing a solution where number of client will be connected (using Wireless network) to MQTT broker located on a server. I will also have another client running on the same machine and connected to the broker which will observe if any new client connected with the broker or for a gets disconnected client. I can see message on broker console when a new client connects or connected client gets disconnected. Can we get something similar from a client connected to the broker? Please suggest what would be the best possible way to achieve this?

Thanks in advance.

-Dilip

2
mqtt
Can you add some more details about what tools you are using? The question is very light on details. – ralight
The sort of thing you are asking will be implementation specific - the MQTT protocol doesn't provide this; hence ralight's question about what tools/clients/brokers you are using. – knolleary
Thanks Roger and Knolleary for your response. I'm using a c-client on a router which will be connected to the broker located on a remote location over the internet and a python client on the server(where broker is installed). There can be n-numbers of router at any point of time. Now if router's n/w goes down, broker will disconnect that client and at this point I would like to inform user of the router(via email using google API) that his/her n/w is down.Hope this gives you some insight, let me know if you need further details. – Dilip

2 Answers

27
votes

Your original question, nor responses to subsequent questions identify which broker implementation you are using. So there may be a more efficient answer to your question.

Without that information, let's focus on what you can do in the protocol itself.

MQTT supports RETAINED messages. This is where the broker will store the most recent retained message against each topic. When a client subscribes to the topic, it will receive the retained message (if one exists).

There is also the Last Will and Testament (LWT) feature (that goetzchr refers to), that can be used to publish a message on behalf of the client if it abnormally disconnects.

Combining these two features allows you to build a simple presence service on the broker, all within the protocol. It works like this:

  1. when a client connects, it publishes a RETAINED message to a topic unique to it, for example:

    clients/my_client_id/state

    with a payload of 1. (substituting my_client_id with the client's own id.

  2. it also, on connect, sets a LWT message to be published to the same topic, but with a payload of 0. This should also be a RETAINED message.

  3. when a client disconnects cleanly, it publishes a RETAINED message to the same topic with a payload of 0

This allows another client to subscribe to clients/# to receive all the messages indicating the changes in clients' connection state (the full topic identifying the client, and the value of the payload indicating the connection state).

To obtain more information than just connected state, the clients can publish another retained message on connect, to another topic, eg clients/my_client_id/info that contains all of the information you're interested in.

This only works if you have control of all the clients that are connecting to your broker and able to get them to behave like this.

This is not an ideal approach; hopefully your broker implementation will provide some server-side means of doing this.

6
votes

like Knolleary already stated this is implementation specific and not provided by MQTT itself.

One solution could be to use the HiveMQ MQTT broker. It has a Plugin SDK, which allows you to do such customization over callbacks, meaning every time a client connects, disconnects, send a message, subscribes to a message you can execute custom code, like in your case sending an email. When writing your custom code you can access all information about the client, which has invoked the callback. So it would be easy to implement your behavior. The only thing is where do you store the email address? Is it the username?

For more information on writing custom HiveMQ plugins see the getting started guide and the example plugin on GitHub

(Disclosure: I'm one of the HiveMQ developers)

Cheers, Chris