HiveMQ Publishing to particular client or endpoint for a common generic Topic

Hi There,

In HiveMQ is it possible to send or publish message directly to one particular endpoint.
This endpoint will be of Client or Subscriber.
The use case is that I want to send a message or publish a message to a particular client directly.

Thanks & Regards,
-Venkat

Hi @vgkkonda,

HiveMQ can only send messages itself via the PublishService.

There you can select between a “broadcast” publish that is sent out to all matching clients that are subscribed to the topic of the publish:

Services.publishService().publish(message);

This one should be of interest for you:
Or send the message only to the client you want (publish is only sent to client if the client is subscribed)

Services.publishService().publishToClient(message, "<insert-client-id>");

Hope this helps! If not please provide a more specific example what you want to achieve.

Greetings,
Michael from the HiveMQ team

1 Like

Hi @michael_w

My usecase is that,
I have multiple subscriber clients who are subscribed to one common topic called “test”.

My ask is that I want to send message to “test” topic but to only one particular client? Remaining clients should not receive this message.
Is this possible using the below code?

"Services.publishService().publishToClient(message, “”);"

How to achieve this?

Thanks & Regards,
-Venkat

Hi @vgkkonda,

before I give you a concrete solution, can you answer those two questions:

  • why would you want that only one client receives the message but subscribe multiple clients to the same topic?
  • also how would you pick the client out of the x clients that are subscribed to “test”?

Greetings,
Michael from the HiveMQ team

Hi @michael_w

Please find below my comments inline:

  • why would you want that only one client receives the message but subscribe multiple clients to the same topic?
    Venkat Comment: we want to send message to a particular client since the message may be related to one particular client. We do not want that to be received by other clients who subscribed to same topic.
    To achieve this we can go with unique topic for each client but we have some 10 to 20 million clients then we will end up with these many topics. To avoid this we want to go with the approach of sending message to a common topic which only one particular client can read.

  • also how would you pick the client out of the x clients that are subscribed to “test”?
    Venkat Comment: We have unique client id for each client subscribed to topic “test”.

Thanks & Regards,
-Venkat

Hi There,

Do we have any sample project which contains the code for using the HiveMQ Extension SDK Services in particular how to use Publish Services?

I need some sample project not just the code snippet or the function.

Thanks & Regards,
-Venkat

Hi @vgkkonda,

reading your response to my questions I would suggest you use unique topics instead of one shared topic. The broker has to store subscriptions anyway and HiveMQ can handle 20 million subscriptions (especially when the HiveMQ cluster can handle 20 million connections).

The more complex solution would be:

  • to intercept the incoming publish
  • prevent it from being forwarded
  • find out which client should get the message
  • use the PublishService.publishToClient method to forward the intercepted publish to that client

My suggestion is use the first solution.

For your latest comment: We have no sample project, but the documentation for the Extension SDK has examples for each feature: HiveMQ Extension Development :: HiveMQ Documentation

Greetings,
Michael

Hi @michael_w

Thanks for the response.
Second option I tried using the extension sdk by implementing the PublishInboundInterceptor interface and overriding the onInboundPublish method.

And regarding the first option of creating the unique topics for each client.
Want to know is there any disadvantage of creating so many topics?
Because by default all clients say 10 to 20 million clients connect and create each one of its one of its default topic. But very rare the message will be sent to each one of these 10 to 20 million topics. How is the topics get created and deleted if it is not used. Is there any resource issue of having such a huge number of topics created with empty messages in it.

What is meant by 20m subscriptions and 20mio connections? what is 20m and 20mio?

What is the maximum number of connections, subscriptions supported by HiveMQ in a cluster? Is there any upper limit? When will the topics be deleted and the data in the topics will be deleted?
Basically we need to know these information to dimension our HiveMQ cluster.

Thanks & Regards
-Venkat

Hi @vgkkonda,

What is meant by 20m subscriptions and 20mio connections? what is 20m and 20mio?

Those are abbreviations I use for million.

Want to know is there any disadvantage of creating so many topics?

The only disadvantage I can think of is that it uses more memory then having all subscribed to one topic. But that most likely is not an issue as many of our customer uses cases have exactly that setup where their MQTT clients have 1-x unique topics and have no problem with that.

When will the topics be deleted and the data in the topics will be deleted?

Topics are created when the MQTT client subscribes to a topic and is deleted a) when the client unsubscribes from the topic again or b) the session of the MQTT client has expired on the MQTT broker. The data generally is deleted when the session of the MQTT client has expired.

But very rare the message will be sent to each one of these 10 to 20 million topics.

That is not an problem for HiveMQ.

What is the maximum number of connections, subscriptions supported by HiveMQ in a cluster? Is there any upper limit? … Basically we need to know these information to dimension our HiveMQ cluster.

As this response gets longer I’m realizing you probably should get in contact with our sales/support (they are dedicated people to make sure you utilize HiveMQ as best as possible for your use case).

Because I can’t give answers to those question without understanding your use case, which takes time that I don’t have (I only answer questions when I have spare time).

Greetings,
Michael from the HiveMQ team