Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Subscriber list
Hey Nick and Darren,

Yes, I was already down the combined path that you two mentioned. For each data publisher topic, like:
    data/gps/location

there is a matching "control" topic, like:
    control/gps/location

A client can send an "on" or "off" message to the control topic to get the messages flowing or stopped, respectively. The publisher then does reference counting. Since the clients might crash, the last will is helpful, but then you need to start tracking client PID's per topic instead of a simple reference counts.

So all this is workable, and portable from one broker to the next. But if the device is shipping with mosquitto burned into Flash, there's little worry about working with a different broker. So if this specific broker has a reliable back door into message subscriptions on individual topics I just started wondering if this same thing could be done with less code. I'm guessing that for the publisher it's about the same. But the client would be a little simpler because it wouldn't need to remember to turn things on and off.

Frank

On 10/10/2014 07:05 PM, Darren Clark wrote:
I can see where a subscriber list could be useful, but it sounds like from these use cases a subscriber count might be more useful. I had a similar case where units would publish status updates every 15 minutes for regular logging, but if someone was watching that unit it would publish every few seconds. I did it with a control type message, but thinking about it a subscriber count would work better.

However in my case I would typically always have a single subscriber that was simply putting the data into a database for historical reporting. You guys got me thinking and here's the design I would use(and may go back and fix my own code):

Decide subscribes to <device-id>/listening/#
Listener connects, and publishes a retained message to  <device-id>/listening/<topic>/<client-id>, setting a LWT to clear the message.
Device keeps a count of listeners, and starts/stops(or increases frequency) based on that.  I'm pretty sure it wouldn't even need to keep track of the individual clients. Just add one if there's a body, and remove it if there isn't. Assuming that it resets to its idle state when disconnected, or is a non-clean session(so it doesn't miss the removal of the retained message while disconnected).

That way you could have passive listeners that don't trigger device behavior changes without cluttering up the device code.

-Darren

On Fri, Oct 10, 2014 at 3:17 PM, Nicholas Humfrey <njh@xxxxxxxxxx> wrote:
Hello Frank,

One of the main uses of the 'Will Messages' feature of the MQTT protocol was to keep track of online clients.

The client sets a "I'm offline" Will message when connecting to the broker, and then publish a message saying "I'm online" when it finishes connecting. If the client disconnects, deliberately or unintentionally, then the broker will deliver the Will message, informing other clients that it has been disconnected.

If the messages are retained, then it is easy to check if a particular client is currently online.


nick.



On 2014-10-10 14:30, Frank Pagliughi wrote:
Hello Roger,

This is potentially very useful if you also consider that mosquitto
is being deployed into situations that you may not have considered
originally. I'm currently testing out its viability in a low-power
ARM/Linux board to act as a central, standard, IPC mechanism within
the board itself. Several applications are running, each monitoring
the data from a smart peripheral on Serial, SPI, or I2C connection,
and when data arrives it is simply published to mosquitto. There might
only be one or two clients listening on a topic.

Several of the peripherals are power hogs, and need to be kept off
when not in use. The GPS is a good example. It consumes as much power
as the rest of the system. So it can be powered up when the first
client subscribes to the topic "data/gps/location" or "data/gps/time",
and then powered down after the last client unsubscribes from those
topics.

This could be done by having the clients manually publish control
requests ("control/gps [on|off]") but this $SYS/broker/log facility
might be a more elegant solution.

What does the broker do if a client disconnects unexpectedly? At the
point where a last will message would be sent out? Is this noted in
$SYS/broker/log in any way?  The last thing we'd want to do is keep
the GPS powered up forever if the last client crashed before
unsubscribing.

Thanks,
Frank

On 10/10/2014 03:39 AM, Roger Light wrote:
Hi Romu,

You could do this quite easily by configuring the broker to do
subscribe and unsubscribe logging. You could write a client that
listens to $SYS/broker/log/M/subscribe and
$SYS/broker/log/M/unsubscribe and publishes the list to a topic as a
retained message.

In general I'm not sure about how wise this is though. If you've got a
fairly active server with clients connecting and disconnecting, then
the amount of bandwidth you'd be devoting to this task would be
considerable.With a naive implementation, if you had 10,000 clients
connected each with a 36 byte client id (e.g. UUID), then you would be
sending a 360kB message each time a client subscribed/unsubscribed.

Cheers,

Roger

On Fri, Oct 10, 2014 at 4:55 AM, Romu Hu <huruomu@xxxxxxxxx> wrote:
Hi,

Is it possible for mosquitto to provide subscriber list to client? For
example, to get the subscriber list of a topic, the client subscribes to
$SYS/broker/subscribers/[topic], the broker sends the list to the client.

Any hint on how to implement this in mosquitto?


Thanks
Romu
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev


_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev



_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

Back to the top