Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] paho.mqtt.c library status
Hello Ian

Thank you for your answer, I understand maintaining a complex build system takes time.
There were targets in the deprecated Makefile to build test files and specifically stuff in 'test/ssl'. Using the new build system, I didn't find ways to build those examples. This would be helpful for SSL troubleshooting.

Just a quick question, in case there is an obvious answer: I have a program that work ok with the library and no SSL.
When I configure SSL, MQTTAsync_connect always returns -1.
I have:
- checked server conf using another client, with the exact same certs/keys, and it worked
- configured the server to be as lax as possible without disabling SSL
- tested with and without client certificates in the library configuration
- checked cert/key permissions and contents
I have digged a little bit in the sources, and MQTTAsync_connect should typically return some kind a meaningful error code. What is the subsequent call that fail and could explain this -1 code?
Could it be an issue with SHA2 certs, or 4096b RSA keys? I'm assuming the mqtt library is forwarding all SSL parameters to OpenSSL and letting it do its magic, maybe I'm wrong.

Regards,
Sylvain

2017-01-27 0:26 GMT+01:00 Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>:

Hello,

thanks for asking about the C client, I've been meaning to explain for a while.  The project is not abandoned, but I've had difficulty finding the time to look at it since the release last year including automatic reconnect and publishing while connected.  I've been focussed on work for the IBM Watson IoT Platform development for a while, but in the open source world I'm spread somewhat thinly too:

  • Eclipse Paho
    • project leading - managing contributions, etc
    • C client
    • embedded MQTT C client, including for mbed
    • embedded MQTT-SN C client
    • MQTT test material
I have thought that the MQTT clients would stabilize functionally at some point, and that the current C client is close to that point in terms of features, but not in other aspects of course.  If anyone disagrees on that point I'd be happy to hear :-)

My difficulties began when some alternative build mechanisms were contributed, which is good, but results in a greater maintenance effort.  I had originally provided build mechanisms for three platforms: Make for Linux and MacOS, and Visual Studio for Windows.  Then CMake followed later by Autotools builds were contributed, and at one point it was suggested that I drop make.  I'm not familiar with CMake or Autotools, but of course could become so with some effort.    It was suggested that CMake could be used for Windows too. 

I would rather not maintain so many build mechanisms.  I want to keep Make, because it needs little maintenance, and I use it in the automated tests for Linux.   If we include alternative build mechanisms they should really also be used in continuous integration tests too, to make sure any changes do not break those builds.    For Windows, I think that keeping Visual Studio builds is essential, as that is the natural build environment.

So there is a significant amount of effort needed to sort out the automated build and testing of the project, in addition to the functional defects.  In the near future, there is also the question of a C client for MQTT V5, which we will need to start.  I intend to write that one in the style of the MQTT embedded clients so that they are more flexible in function and use.

I'm open to suggestions of how to handle the proliferation of build mechanisms.  If anyone is interested in the idea of becoming an Eclipse Paho committer to help me with the C client, especially in the area of build and test, then please let me know.

I will be attempting to find some time to look at the C client soon, in any case.  Any and all thoughts, advice and/or help are very much appreciated.

Thanks

Ian

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

Back to the top