The only edge case I can see for reference counting is if you get disconnected before publishing the "on" message, causing the publishing to stop prematurely when the off LWT is sent. In that case you would have to track some identifier for each. That could become a problem for constrained devices and more than a couple clients.
That's also why I would suggest using retained messages in a topic subtree if possible. The publisher could sanity check by unsubscribing and resubscribing to reset the ref count. That of course assumes that the broker storage can handle retrained messages for the expected number of clients at a time.
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.
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.