0

The question is already posted, Mqtt How a client can get to know that another client is connected or not and How to Find Connected MQTT Client Details

In my case, if client X is already subscribed in a channel A, client Y can't subcribe to the channel A, until X unsubcribes. I can only have one client subscribed in the channel

Can I also use the idea of retained messages and LWT?

If yes, I don't know exactly from where should I start. It would be good to start with a simple example to see how the retained messages and LWT work. So far, I just have experience in publishing and subscribing but no more.

Could you please, tell me some advises may be some links or examples or any useful information so I can have a starting point.

frogatto
  • 28,539
  • 11
  • 83
  • 129
marhg
  • 659
  • 1
  • 17
  • 30
  • Why do you only want one subscriber? – hardillb Aug 12 '16 at 12:04
  • because the client wants that. The idea is to have different communication types: one publisher/one client, many publishers/many clients. Therefore there are channels that can only have one subscriber, but also, i can publish the same data but in a different channel that allows more subscribers.eg channel temperature only accepts one subscribers while temperature2 many – marhg Aug 12 '16 at 12:13

1 Answers1

3

MQTT is all about having multiple clients subscribing to the same topics, it's part of the whole pub/sub pattern and sharing information. So there is nothing baked into the protocol that will do what you want.

You may be able to implement something like the following:

If have a topic say foo/bar and you only want one subscriber you could publish a retained message with a payload of the client-id of the subscriber to lock/foo/bar. You could then publish a "free" to this lock topic when you disconnected and set up a LWT to do the same in case the client dies.

The problem with this is that everything is asynchronous so it opens up lots of timing windows for race conditions. e.g. say client-1 and client-2 both want to subscribe to foo/bar, they would both need to first subscribe to lock/foo/bar to check it's state. They both do this at very nearly the same time, they then have to wait for some time to see what message they get back ("free" or a client-id). They would both get "free" so would both assume that they can publish their client-ids. client-1 published first shortly followed by client-2 and then they both subscribe to foo/bar.

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • Hi hardillb, yes, you are right with the problem. But then, what could be a good alternative? in another post i read about sending subscribe events to the channel. then i guess that if someone wants to subscribe he needs to know if there is already a subscribe event – marhg Aug 12 '16 at 12:20
  • Basically I'm trying to say it's not possible with MQTT – hardillb Aug 12 '16 at 12:21
  • oh no! ... well i guess my only option is the retained message and lwt, but i don't know how i will overcome the problem, at least avoid subscribes at the same time :/. Do you know where i can find a small implementation using the retained message, I read in the hivemq.com but i couldn't find – marhg Aug 12 '16 at 12:34
  • the retained message is defined in the setWill options.setWill(client.getTopic("home/LWT"), "I'm gone :(".getBytes(), 0, false); right? but you mentioned "you could publish a retained message with a payload of the client-id of the subscriber to lock/foo/bar" but what if i don't know who is the client? or what did you mean? – marhg Aug 12 '16 at 12:49
  • A client should always know it's own client-id – hardillb Aug 12 '16 at 13:12
  • Thank you hardillb, i will try to do a small example. See you in the next post ;) – marhg Aug 12 '16 at 13:44