HiveMQ vs Mosquitto

3,550 views
Skip to first unread message

Dip

unread,
Jun 26, 2018, 3:24:07 AM6/26/18
to MQTT

Hello Everyone,

 
First of all sorry for asking a similar question, Same question ask before 3-4 years but i didn't find information relevant (because of new release on protocols).
 
I am Student and beginner on communication Protocols. I want to use most secure, resistent, scalable and ease to implement protocol on my Project. Here I describe my Use-Case so everyone has a basic idea. As per recent trends and new release, I am confuse between HiveMQ and Mosquitto.
 
Client A wants to send some small information to Client B with Acknowledgment (exactly once) with persistent Session. In my Case 1 or many Publisher can publish on same topic but every topic subscribe by specific only one subscriber (see attached image1).  In that case, I thought, would be better to publish message with "subscriberID" as a topic. As a Broker I want to use MQTT Cluster Broker on Cloud with Load-Balancer. 
 
As I know in PUB-SUB architecture Clients are decouple, that means publisher don't get acknowledgment if subscriber receive his message or not. Publisher get acknowledgment that broker get his message. But What if i can set mechanism like, Client A publish message with topic "ABC" with packetID "4320" and Client B subscribe for topic "ABC". Once Client B  get message, it publish another message with topic "reABC" with payload "packetID 4320"and Client A subscribe for topic "reABC". That means Client B get successfully message that publish by Client A. is that a good mechanism or there is another better way.  (see attached image2).

 

1. Which is most secure and most suitable in my use-case ? (security is my first aspect)

2. Is MQTT good choice for this Use-Case or might be any another protocol is more suitable for it ?

 

Thanks in Advance for your reply and suggestions.

 

Best Regards,

Dip

Image1.png
Image2.png

ran...@bevywise.com

unread,
Jun 26, 2018, 9:09:46 PM6/26/18
to MQTT
Hello Dip, 

Your image 2 implementation is right. 

You should not depend on the acknowledgement provided by the Protocol.  This is applicable to any protocol you choose, as the action completion is not based on the message delivery acknowledgement. We should really make the device who does the action reply back saying the action is complete.  More on Data Flow designs

MQTT is secure with the TLS enabled version.

MQTT is good, but you should not try to use it for mobile application building over your server.  You should use MQTT for the communication between devices.  When it comes to mobile apps or other application integration with the broker, you should choose it based on the need.

Hope this helps. 

Thanks, 
Ranjith 

Dip

unread,
Jun 27, 2018, 3:05:04 AM6/27/18
to MQTT
Hello Ranjith,
 
Thanks a lot for your suggestion, but unfortunately i forget to mention in main post, that I am going to use mobile as a publisher and on other hand Raspberry Pi 3 as a subscriber. So user can control Raspberry PI via mobile application. For example - Garden caring system, Raspberry Pi is connected to water supply main valve to control via mobile application. 

MQTT is good, but you should not try to use it for mobile application building over your server.

Do you mean that integrate MQTT in mobile application (as a Client) is bad practice ? if yes, then please let me know why is not good and which protocol is best to integrate in Mobile application (i found some Library like. Paho Android Service for integration MQTT to mobile app). 

You are expert, can you please suggest me which is best protocol to use in that case.  :)  

Regards,
Dip

ran...@bevywise.com

unread,
Jun 27, 2018, 11:44:45 PM6/27/18
to MQTT
Hello Dip , 

Mobile Application will not allow live connections to your server when your mobile app is running in the background. So when you integrate the MQTT to your mobile app, you cannot receive messages or notifications when the app is closed. 

Definitely you can invoke the APP and publish MQTT Messages. But FCM based messages should be used for receiving messages and notifications when app is in background.  So you should use MQTT, FCM and APIs from your application in combination to achieve a complete flow. 

If you are building a complete business case app, you cannot just have a Broker.  I would recommend a Application server over the MQTT Broker or some IoT Platform like our Platform or something which you are familiar with and  which provides API / SDKs for Mobile APP with FCM integration to get a perfect work flow.  

Hope this helps. 

Ranjith 

Dip

unread,
Jun 28, 2018, 10:24:57 AM6/28/18
to MQTT
Hello Ranjith,

Again thanks, Your answer helped me a lot.

I already visit your Enterprise MQTT Broker, that really cool. :)

Actually i didn't get you correctly "Application Server over the MQTT Broker". Could you please bit more elaborate ?

Currently My University provide some developer space on Cloud for practice purpose and i try to deploy my Broker using Docker Container. Initially I choose HiveMQ Broker Cloud Cluster because i want closed (not public) MQTT system. Do you have any suggestion or any recommandation please feel free to tell me. 

Thanks and Regards,
Dip

ran...@bevywise.com

unread,
Jun 28, 2018, 1:12:52 PM6/28/18
to MQTT
Hello Dip, 

Thanks for those words about our MQTTRoute, the enterprise MQTT Broker. 

MQTT Broker is a middleware. It just enables you to connect devices that can send and receive messages via the Broker. But your overall application needs a human touch which is more specific to the use case you are building and will not be provided by the MQTT Broker.   By Application, I meant the business logics, algorithm for the analysing the data received by the Broker, the mobile application, the web interface and all. 

For example, MQTTRoute provides options to extend it by enabling the custom storage where you can receive all the data from the edge device and store it any BIG Data storage like MongoDB or ElasticSearch and build your application over it. 

Platforms will provide some specific UIs which can be used. 

Hope this clarifies. 

Thanks, 
Ranjtih 
Reply all
Reply to author
Forward
0 new messages