18

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

ralight
  • 11,033
  • 3
  • 49
  • 59
Dilip
  • 628
  • 2
  • 10
  • 23
  • Can you add some more details about what tools you are using? The question is very light on details. – ralight Sep 27 '13 at 18:46
  • 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 Sep 27 '13 at 19:28
  • 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 Sep 28 '13 at 02:39

2 Answers2

29

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.

knolleary
  • 9,777
  • 2
  • 28
  • 35
  • Thanks Knolleary. I was looking for something like this. So hopefully this will serve my purpose. Also thanks everyone for your support. – Dilip Sep 30 '13 at 14:19
6

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

Christian Götz
  • 818
  • 1
  • 8
  • 11
  • Thanks for your suggestion Goetzchr. Email addresses will be stored on the database, when a client successfully connect with the broker, it will publish all the details for Python client running on broker machine to pick up and insert them onto DB. I'm not sure if we want to move into HiveMQ at this point of time as we have already done a quite a bit of development using MQTT broker. My main aim was to somehow notify Python client when a particular client gets disconnected from the broker. We already have another module which will take care of sending emails to the desired email address. – Dilip Sep 28 '13 at 10:21
  • 1
    Ah ok, I think a possible solution would be to use last will and testament feature of MQTT. This gives you the ability of sending a message to a topic when a client is disconnected unexpectedly. The topic and message can be specified individually for each client in the Connect message. – Christian Götz Sep 28 '13 at 17:02
  • Thanks Goetzchr. I was looking for something like this. – Dilip Sep 30 '13 at 14:21
  • @ChristianGötz: Can you tell me how to print message(for logging) at server side at the time of subscriber? Plz check this https://github.com/mqttjs/MQTT.js/issues/291. Thanks – Pritam May 30 '15 at 11:21
  • @Pritam you can do this by using the OnPublishSend callback in HiveMQ. More information are in the HiveMQ plugin developer guide here http://www.hivemq.com/docs/plugins/latest/, search for OnPublishSend. – Christian Götz Jun 30 '15 at 13:59
  • @ChristianGötz: Thanks for your response. I am using Mosca as a broker. I figured it out for that. Thanks. – Pritam Jul 01 '15 at 04:48