Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Differences between paho-c and mosquitto

Mark,

I'm interested in your comment 'My one complaint about the paho project is it is so confusing at first which of the many options to use' - I could include advice in the project.  What particular options are confusing?  I wrote a blog post in 2013: http://modelbasedtesting.co.uk/2013/10/13/which-paho-mqtt-c-api-to-use-and-some-history/ - is that the sort of information?

This page does have some indicators of features in the different Paho clients: https://www.eclipse.org/paho/downloads.php

One feature that might figure in 'robustness' is the ability to persist message state over application invocations.  The last time I looked, libmosquitto does not have that capability.  To many people, this seems not to be important, though.

Paho does have a broker, written in Python, in paho.mqtt.testing.  However, given that the method of communication is standard MQTT, I'm not sure that should be an important factor.  MQTT brokers and client libraries are generally interoperable to any extent.  I'm not currently aware of any broker/client lib combination that depend on each other for a feature.

Ian

On 13/03/2019 12:46, Mark Oeltjenbruns wrote:
>  Mainly I am interested in when I should choose mosquittopp and when paho.mqtt.cpp?
I started with the mosquitto library and found it fairly easy to work with.  The error handling has been a bit vague, but then our security group has wanted some 'interesting' restrictions placed on communications with a broker, so that may be part of the issue.

Lately I've used paho, in the same application.  I refactored my implementation to be able to use either library at run time.  They are implemented using slightly different approaches, but overall the details where not that significant.  I've had a lot more experience with the mosquitto suite. I have nothing against paho but would suggest mosquitto based on my experience with it.
Why would I need 2 MQTT clients?  The application group thought that websockets and SOCKS5 support is now a mandatory requirement.
This is where having to use non-MQTT binary protocol comes into play.  Mosquitto supported SOCKS5, but not websockets and paho supported websockets but not SOCKS5. Perhaps this has changed since then.
>- Fast C/C++ bugs fixes and supports.
I struggled with the SOCKS5 setup and just couldn't get it to work.  Thinking perhaps it wasn't something on my end I reached out to this list.  Very quickly Roger Light had agreed it was a problem and had a fix for me in a short period of time.  [In case of searching emails, SOCKS5 did not work correctly with TLS connections.]  He also issued an official release with the patch he sent me applied not long after as well.
I have not had to contact the paho group so can't comment on that aspect.
> - The project is compiled on AMD and ARM architecture, used OS: Ubuntu and Debian.
My application is for embedded products running PowerPC cores, have used it on PCs and ARMS, although to be honest, I'm pretty sure both code bases are written pretty generic with no operating or CPU special requirements.
>- stability, robustness.
I found both to be very reliable.
Another reason to go with mosquitto is that it also contains a broker, which AFAICT paho does not at this point.  I've had to work with several different brokers and found several issues with some of them.  It was very crucial for me to be able to have very fine control over the broker setup to minimize the debug surface.  Again, this is partly due to the unusual security requirements.

My one complaint about the paho project is it is so confusing at first which of the many options to use.  Since my only criteria was the websockets support, the decision was made for me as only one option had it at the time.  From that perspective I again found mosquitto a better option as it is very clear what it is and what it contains.
> I have seen there are two directions of development of this topic by eclipse.
If there is someone here that can answer that I'd be interested in why this is so.  It seems like focusing efforts on improving one solid code base would be better in the long run.


On Wed, Mar 13, 2019 at 2:32 AM Kristóf Makó <makokristof@xxxxxxxxx> wrote:
Hi all,

I would like to apply a robust MQTT cpp library on linux system in my project. I have seen there are two directions of development of this topic by eclipse. Which one is called mosquittopp (https://github.com/eclipse/mosquitto) and second one is called paho.mqtt.cpp (https://github.com/eclipse/paho.mqtt.cpp). Whereas I found a few of forum in this topic, I can't decide which is the best from aspects like up-to-date, robustness, stability.

Mainly I am interested in when I should choose mosquittopp and when paho.mqtt.cpp?

Probably the answer lies in details, I saw mosquittopp based on mosquitto until paho.mqtt.cpp based on paho.mqtt.c. Which are the differents between two C library?

Most important aspects for me:
- The project is compiled on AMD and ARM architecture, used OS: Ubuntu and Debian.
- Fast C/C++ bugs fixes and supports.
- stability, robustness.

If this question already asked, I am sorry and please link to me that section of topic where I can find the answer.

Thanking your reply in advance.
Best regards,
Makó Kristóf
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/mosquitto-dev
-- 
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Eclipse Paho Project Lead & Mosquitto Committer

Back to the top