eclipse / paho.mqtt.cpp Goto Github PK

If an application is built without SSL enabled, and linked against the C++ library that was compiled with SSL enabled, then the application will crash (segfault) when trying to connect.

The reverse may be true as well.

I believe this is due to the conditional compilation in connect_options.h:

#if defined(OPENSSL)
	/** The SSL options  */
	ssl_options ssl_;
#endif

This makes the size of the connect_options different depending on whether or not OPENSSL was defined.

I renew my objection to conditionally compiling out the SSL components!

At the worst, an application should be given a friendly error when trying to connect using SSL, if linked to a library that doesn't support it. A segfault isn't the proper response.

See also:
eclipse/paho.mqtt.c#251

The classes connect_options, disconnect_options, response_options, ssl_options and will_options have many things in common. The idea is to create an options template class to hold the common code and create specializations for each type.

Something like this:

template<typename T>
class options {
private:
    T opts_;

public:
    using ptr_t = std::shared_ptr<options<T>>;
    using const_ptr_t = std::shared_ptr<const options<T>>;
};

using connect_options = mqtt::options<MQTTAsync_connectOptions>;
using disconnect_options = mqtt::options<MQTTAsync_disconnectOptions>;
using response_options = mqtt::options<MQTTAsync_responseOptions>;
using ssl_options = mqtt::options<MQTTAsync_SSLOptions>;
using will_options = mqtt::options<MQTTAsync_willOptions>;

There are some problems though. For example, how do we handle the differences accross specializations in:

• The std::string buffers for each class.
• The access methods to attributes. Because each specialization has its own set of access methods.
• Constructor argument list.
• Construction initialization list.

I'm using the synchronous client, but I still need to set a callback class in order to handle the incoming messages in an asynchronous way. I think it would be easier if the own client worked as a socket, buffering all the incoming messages. The client class would have a "receive" method or so, which pops the next message from the queue. If it's empty, it could block for some timeout period that would be passed as an argument.

Now there is no way to set/get data from underlying C connection structure if no setter/getter method explicitly defined. It is very easy to fix by applying protected visibility for opts_ member.

There should be a public interface to set the mqttVersion in
mqtt::connect_options

the underlaying c-strcture MQTTAsync_connectOptions in mqtt::connect_options has the member
but it's not accessible.

typedef struct
{
....
/**
* Sets the version of MQTT to be used on the connect.
* MQTTVERSION_DEFAULT (0) = default: start with 3.1.1, and if that fails, fall back to 3.1
* MQTTVERSION_3_1 (3) = only try version 3.1
* MQTTVERSION_3_1_1 (4) = only try version 3.1.1
*/
int MQTTVersion;
....
} MQTTAsync_connectOptions;

Or... do we replace the SSL conditional compilation by an exception throw mechanism?

As we do not have an active mailing list, I decided to gather ideas here.

Currently, the SSL support in Paho MQTT C++ is done at compile-time. And it depends on which kind of Paho MQTT C library is available. If the user has the libpaho-mqtt3as, it might use (or not) the SSL. The user has this choice during the build. Otherwise, if there is only the libpaho-mqtt3a available, the user has no choice but do not use SSL.

Conditional Compilation

The major problems with the current approach are:

• Complicates the building system.
• Code polluted with ifdefs.
• Difficult the source code maintenance.
• Might cause data conversion issues between C++ and C libraries. Like @fpagliughi said in #74,

If we compile out OPENSSL support, but link to the Paho C library that has SSL support, will there be any problems? Is there any way to mess up the structures passed to the C lib?

• Program crash if the application and the library don't agree on whether or not to use SSL (#76)

In the end, the SSL support in Paho MQTT C++ should not be a build option. It should be decided automatically based on the Paho MQTT C library available.

Exception Throw

This approach has its drawbacks too. Some of them are:

• Force the user to handle an extra kind of exception.
• Postpone to run-time errors that could be detected at compile-time.
• Require many parts of the library to be exception-safe and use exception-safe methods and containers.

Hi folks, I was trying to compile paho cpp client from source:

https://github.com/eclipse/paho.mqtt.cpp

However, the code in file "connect_options.cpp" gives me compilation error, due to it is trying to access an nonexist member "binarypwd" in C struct "MQTTAsync_connectOptions".

Besides, it is trying to copy two "MQTTAsync_connectOptions" struct object by invoking "=" operator, however, this operator overload is not defined in that C struct (obviously cause it is C struct!)

This is weird, because the code should be well maintained on github, do I miss something in here?

Thanks!

I tested your ssl_publish.cpp example but I always get:

pi@raspberrypi:~/paho.mqtt.cpp/src/samples $ ./ssl_publish 
Initializing for server 'ssl://localhost:18885'...
  ...OK

Connecting...
Error: MQTT exception -13

can you help me out?

A failed attempt to reconnect crashes the app with a segfault in the token::on_failure() callback, likely because the callback does not have the context to a valid token address.

The method void client::unsubscribe(const topic_filter_collection& topicFilters) calls async_client::subscribe() instead of async_client::unsubscribe(). Is it correct? If this is correct, should be there a comment explaining this counterintuitive behavior.

Linkage library /lib/libpaho-mqttpp3.dll.a is installed, but /bin/libpaho-mqttpp3.dll is not.

Export/expose the automatic reconnect fields of the connect options (automaticReconnect, minRetryInterval, maxRetryInterval).

Also export the MQTTAsync_reconnect() function from the mqtt::async_client and mqtt::client classes.

I understand that the Paho C does not use enumerations for QoS. Though it would help to document the code, the C language allows interchange of integer and enumeration. But the C++ considers enumerations as types and has more strict rules. I guess it should increase type safety (and prevent programming mistakes) if all QoS become enumeration type, or even an enum class.

Tokens with a zero ID may be getting placed into the async_client list of pending tokens (pendingTokens_), as reported by the attempt to fix it on the back end:
#50

A proper fix is to make sure that they don't get inserted in the first place, otherwise they are likely causing a memory leak by accumulating in the collection and never getting resolved and removed.

The original C++ API was closely derived from the (now) Paho Java API, which included interfaces for token classes, IMqttToken and IMqttDeliveryToken which became itoken and idelivery_token for us.

As tokens are dynamic objects, we use them almost exclusively through shared pointers, such as itoken_ptr or token_ptr for the interface and concrete object, respectively. But a number of issues have surfaced:

1. Since we use them as shared pointers, direct polymorphic behavior is not available. We need to do some ugly casting to go back and forth.
2. The main internal use of tokens in the library is to pass their raw values to the C library for callbacks. The callbacks require concrete token and delivery token objects.
3. The raw address - ptr.get() - of an itoken_ptr is not the same as the raw address on a token_ptr even when they refer to the same object! We always need the address of the token_ptr to interact with the C library. This has caused some nasty bugs during development.
4. Because of (2) & (3) we often can't pass around an itoken_ptr, when that would seem to be expected of the API. And if we do, we have to use and ugly cast to get a token_ptr, anyway, which could be dangerous if we did invent something else derived from itoken.
5. I haven't been able to dream up any other class that we might want to derive from itoken!
6. We could (should) keep the token interface virtual, in case we wanted to enhance its behavior. Delivery tokens would still be derived from normal tokens.

So, I suggest that we get rid of the interface classes itoken and idelivery_token and just use the concrete tokens directly - via their shared pointers, of course.

So, the async_client class would have members like:

token_ptr connect(connect_options options) override;
token_ptr disconnect() override;
delivery_token_ptr publish(const std::string& topic, const_message_ptr msg) override;

I'm proposing this just for the tokens. I think we should still keep interfaces for the clients, action listeners, and things like that.

Header mqtt/types.h referenced by:

• mqtt/connect_options.h
• mqtt/ipersistable.h
• mqtt/message.h
• mqtt/token.h
• mqtt/will_options.h

not installed with make install.

Is it possible to use file wildcards in the CMake and autotools builds? I think we can make the following assumptions:

• All source files in src should be built into the library (src/*.cpp)
• All header files in src/mqtt should be installed (src/mqtt/*.h)
• All the samples in src/samples should be built and installed when samples requested (src/samples/*.cpp)

The only complication is which of these should be excluded if SSL is not opted.

@guilhermeferreira

I have tried to SSL options to connect and it is not working.
Basically I have .pem file and providing it in the truststore and trying to connect.
Here is the code I have used to set SSL properties.

mqtt::ssl_options ssl;
ssl.set_trust_store(TRUST_STORE);
ssl.set_enable_server_cert_auth(0);
connectOptions.set_ssl(ssl);

Then it has coredumped.
Here is the output I am seeing in the console:

Setting SSL properties
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct null not valid
Aborted (core dumped)

I have commented out part of code in set_ssl in the connect_options.cpp as below

void connect_options::set_ssl(const ssl_options& ssl)
{
    ssl_.set_trust_store(ssl.get_trust_store());
    /*ssl_.set_key_store(ssl.get_key_store());
    ssl_.set_private_key(ssl.get_private_key());
    ssl_.set_private_key_password(ssl.get_private_key_password());
    ssl_.set_enabled_cipher_suites(ssl.get_enabled_cipher_suites());*/
    ssl_.set_enable_server_cert_auth(ssl.get_enable_server_cert_auth());

    opts_.ssl = &ssl_.opts_;
}

Then I am seeing MQTT exception as below:

Error: MQTT exception -1

Please let me know if you have any working sample.

Thanks,
Hari.

I have a problem with the sample programs:

pi@raspberrypi:~/paho.mqtt.cpp/src/samples $ sudo ./async_publish 
Initializing for server 'tcp://192.168.1.34:1883'...
  ...OK

Connecting...
pi@raspberrypi:~

After 'connecting' the program ends.

What I noticed is that the program creates a folder:
pi@raspberrypi:~/paho.mqtt.cpp/src/samples/AsyncPublisher-192.168.1.34-1883 $

Same with async_subscribe program.

What can I do to fix this behaviour?

I noticed many methods with a long parameter lists. For example:

virtual idelivery_token_ptr publish(const std::string& topic,
_________ const void* payload, size_t n,
_________ int qos, bool retained, void* userContext,
_________ iaction_listener& cb) throw(exception) =0;

The section 31.7 (Laying Out Routines) from Code Complete suggests a layout with one parameter per line:

virtual idelivery_token_ptr publish(
_________ const std::string& topic,
_________ const void* payload,
_________ size_t n,
_________ int qos,
_________ bool retained,
_________ void* userContext,
_________ iaction_listener& cb
) throw(exception) =0;

This layout provides a better visibility of all formal arguments and works better with version control systems, like Git, because the modification of each argument (or the routine's name) is spotted clearly.

What's your opinion about?

I got this errors:
error C3646: 'noexcept' : unknown override specifier
error C2797: 'mqtt::topic::name_': list initialization inside member initializer list or non-static data member initializer is not implemented

and need modified mqtt\types.h
#ifdef WIN32
#include <stdint.h>
#endif

Maybe it is more better to have universe code.

I put my project on a clean jessie installation and I get following error:

undefined reference to `mqtt::async_client::async_client(std::string const&, std::string const&)'

I call the async client like this:
this->client = new mqtt::async_client("tcp://192.168.1.36:1883", "AsyncSubcriber");

what I'm doing wrong or what I forgot to install?
I installed:

git clone https://github.com/eclipse/paho.mqtt.c.git
cd paho.mqtt.c
make
sudo make install
and
git clone https://github.com/eclipse/paho.mqtt.cpp
mkdir build
make
sudo make install

my CMakeLists contains this:

set(PAHO_MQTT_CPP paho-mqttpp3)
set(PAHO_MQTT_C paho-mqtt3a)


## Paho MQTT C include directory
get_filename_component(PAHO_MQTT_C_DEV_INC_DIR ${PAHO_MQTT_C_PATH}/src ABSOLUTE)
get_filename_component(PAHO_MQTT_C_STD_INC_DIR ${PAHO_MQTT_C_PATH}/include ABSOLUTE)
set(PAHO_MQTT_C_INC_DIR
        ${PAHO_MQTT_C_DEV_INC_DIR}
        ${PAHO_MQTT_C_STD_INC_DIR})

## Paho MQTT C++ include directory
get_filename_component(PAHO_MQTT_CPP_INC_DIR ${CMAKE_SOURCE_DIR}/src ABSOLUTE)

## include directories
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
include_directories(${PAHO_MQTT_C_INC_DIR})
include_directories(${PAHO_MQTT_CPP_INC_DIR})

## Paho MQTT C library directory
##get_filename_component(PAHO_MQTT_C_LIB_DIR ${PAHO_MQTT_C_LIB} DIRECTORY)

## Paho MQTT C++ library directory
get_filename_component(PAHO_MQTT_CPP_LIB_DIR ${CMAKE_BINARY_DIR}/src ABSOLUTE)

## link directories
link_directories(${PAHO_MQTT_C_LIB_DIR})
link_directories(${PAHO_MQTT_CPP_LIB_DIR})

sorry for bothering you
I really don't know what I did wrong...

We are trying to connect to the MQTT broker with username and password using this Paho MQTT CPP library. But found definitions for the following functions are missing,

/**

• Sets the password to use for the connection.
  */
  void set_password(const std::string& password);

/**

• Sets the user name to use for the connection.
• @param userName
  */
  void set_user_name(const std::string& userName);

Could you please suggest a solution?

In order to avoid confusion about different time units throughout the API, convert methods that take integer time values to take chrono duration types.

From:

void set_keep_alive_interval(int keepAliveInterval);

to:

template <class Rep, class Period>
void set_keep_alive_interval(const std::chrono::duration<Rep, Period>& keepAliveInterval) { ... }

These can also co-exist to keep backward compatibility. So we can have both.

But the getters that return a time value should return an appropriate duration value, like:

std::chrono::seconds get_keep_alive_interval() const;

The mqtt::message class encapsulates most of the data required for an MQTT PUBLISH message, but omits the topic. This was due to the fact that the underlying Paho C library does the same thing - includes everything except publish.

In order to queue up messages in C++ it would be extremely helpful to have the payload and all the meta-data for a message contained within a single structure.

First discussed in #92

What do you think about a text message, along with error code, in mqtt::exception?

void token::on_failure(MQTTAsync_failureData* rsp)
{
if (rsp) {
tok_ = rsp->token;
rc_ = rsp->code;
message_ = rsp->message;
}

}

see that

Using connect_options(username, password) doesn't really set connection username nor password as private opts_ member is not updated.

Tested CMake with a variety of compilers on Mint17/Ubuntu 14.04:
g++-4.8, 4.9, 5.4, 6.2
clang++3.6, 3.8

Of the compilers tested, only g++-6 built properly. The other compilers require the flag "--std=c++11"
g++ 6.x defaults to -std=gnu++14, but I believe all the others still use C++98 by default.

I suppose we can force the c++11 standard. The library doesn't currently use anything from C++14, though I believe it would still be compatible with applications compiled to a newer standard. But if CMake could detect the compiler and not set the standard backward for g++ 6 or newer, that would be cool.

This is the type of output I got from builds with all those other compilers:

$ cmake -DCMAKE_CXX_COMPILER=g++-4.8 -DPAHO_MQTT_C_PATH=../../paho.mqtt.c ..
-- The C compiler identification is GNU 4.9.4
-- The CXX compiler identification is GNU 4.8.5
...
-- Build files have been written to: /home/fmp/mqtt/paho.mqtt.cpp.merge.git/build
$ make
Scanning dependencies of target common_obj
[ 10%] Building CXX object src/CMakeFiles/common_obj.dir/async_client.cpp.o
In file included from /usr/include/c++/4.8/thread:35:0,
from /home/fmp/mqtt/paho.mqtt.cpp.merge.git/src/mqtt/token.h:33,
from /home/fmp/mqtt/paho.mqtt.cpp.merge.git/src/mqtt/async_client.h:28,
from /home/fmp/mqtt/paho.mqtt.cpp.merge.git/src/async_client.cpp:19:
/usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the
^

@guilhermeferreira

The library is currently using std::string to hold binary data packets, such as the mqtt::message payload. This is a great type for holding arbitrary, binary data, but using it directly is often confusing to users who would expect to find it holding text data.

A better solution would be to create a type specifically for binary buffers. This could just be a typedef to std::string or a std::vector of bytes, but a better solution might be a std::basic_string of bytes:

using byte_buffer = std::basic_string<uint8_t>;

This gives all the string manipulation functionality, but typed to binary data.

Hi,
I'm trying to use the paho.mqtt.cpp library to make a connectiion to my local mqtt mosquitto broker.
I have generated the certificates for my server and configured mosquitto using this file
mosquitto-m2mqtt.conf.txt

Then, I have compiled the paho-mqtt-cpp project and I have tried to use the ssl_publish sample to make a connection to my server, modifying the sample code in this way:

const string DFLT_ADDRESS {"ssl://127.0.0.0.1:1883"};

sslopts.set_trust_store("/home/pi/mosquitto-certs/m2mqtt_ca.crt");

And I have commented the line with the setting of user and password, since I'm not using them.

When I launch the ssl_publish, this is the output:

Initializing for server 'ssl://127.0.0.0.1:1883'...
...OK

Connecting...
Waiting for the connection...
Error: MQTT exception -1

I think that the broker is working, because using another java application I'm able to connect to it, using that certificate.

Do you have any suggestions? Am I doing something wrong?

Thanks,
Davide

Hi,

I noticed a problem when using a long password or username in the connOpts or the async_client.
The use of long strings in the connOpts.set_user_name() and connOpts.set_password-methods has as result that the User Name and Password-field of the MQTT Connect Command are empty (noticed this in Wireshark).

The problem seems to happen when the library makes a copy of the connect_options in the following method: itoken_ptr async_client::connect(connect_options opts). I looks like the copy of the connect_options goes out of scope and as a result the destructor of the connect_options class removes the username and password string. I don't know why this only happens for long passwords and usernames.

As a workaround for my project, I used a pointer to the connect_options in all the connect() methods instead, to avoid the copying of the connect_options.

For example:
`
itoken_ptr async_client::connect(connect_options* opts)
{
itoken_ptr tok = std::make_shared(*this);
add_token(tok);

opts->set_token(std::dynamic_pointer_cast<token>(tok));

int rc = MQTTAsync_connect(cli_, &opts->opts_);

if (rc != MQTTASYNC_SUCCESS) {
	remove_token(tok);
	throw exception(rc);
}

return tok;

}
`

Kind Regards,
Tomas

Up to now, neither Paho MQTT C nor Paho MQTT C++ libraries have support for WebSockets (RFC 6455). Also, there is an issue open for Paho MQTT C requesting WebSocket support.

There are some explanations regarding the need of MQTT over WebSockets here and here.

These are the implementation options I see so far:

• Wait for Paho MQTT C add the WebSocket support and create a wrapper for it. It might take time until the Paho MQTT C implementation stabilizes.
• Implement our own WebSocket. This might incur a lot of work for us.
• Use a 3rd party library, like libwebsockets, websocket++, or Beast C++ Library. We will add another dependency to Paho MQTT C++, creating more building problems.

Trying to connect to a server (mqtt.carriots.com) requiring an empty password:

• Setting connection_options.set_password(""); failed with code 4 (bad authentication).
• Leaving password uninitialized: connection OK.

If I am trying to create an instance of a mqtt::client (paho.mqtt.cpp built with SSL option on), there is a heap error.
This error occurs, when I create an instance in a class method initialize() of my class MQTT, which shouldn't make any difference. If I create the instance in the main function, I cannot reproduce the error.

My program flow is as following:

1. create last will message instance and configure the message
2. create connect_options instance and configure the options
3. Create client instance with hostname and clientid.

All the instances are created on the heap.
After creating the connect_options, it isn't possible to create the client on the heap.

After building mqttpp withOUT SSL, the error doesn't occur.

Output of the console:
sysmalloc: Assertion(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)' failed.

*** Error in `./IoT_Gateway': malloc(): memory corruption: 0x0000000001d34f30 ***

Valgrind output:
`
==17065== Memcheck, a memory error detector
==17065== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17065== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17065== Command: ./IoT_Gateway
==17065==
==17065== Invalid write of size 8
==17065== at 0x4E518A9: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== Address 0x9e16018 is 0 bytes after a block of size 200 alloc'd
==17065== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17065== by 0x404CED: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065==
==17065== Invalid write of size 8
==17065== at 0x4E518B1: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== Address 0x9e16020 is 8 bytes after a block of size 200 alloc'd
==17065== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17065== by 0x404CED: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065==
==17065== Invalid write of size 4
==17065== at 0x4E518B9: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== Address 0x9e16028 is 16 bytes after a block of size 200 alloc'd
==17065== at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17065== by 0x404CED: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065==
==17065== Invalid write of size 8
==17065== at 0x4E518C0: _Alloc_hider (basic_string.h:275)
==17065== by 0x4E518C0: basic_string (basic_string.h:439)
==17065== by 0x4E518C0: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== Address 0x9e16030 is 16 bytes after a block of size 208 in arena "client"
==17065==
==17065== Invalid write of size 8
==17065== at 0x4E518C4: _Alloc_hider (basic_string.h:275)
==17065== by 0x4E518C4: basic_string (basic_string.h:439)
==17065== by 0x4E518C4: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== Address 0x9e16038 is 24 bytes after a block of size 208 in arena "client"
==17065==

valgrind: m_mallocfree.c:304 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 272, hi = 94864344.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.

host stacktrace:
==17065== at 0x3805DB16: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x3805DC24: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x3805DDA6: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x3806AB83: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x380571EB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x38055CCB: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x38059B3B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x380552C7: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==17065== by 0x802DD871B: ???
==17065== by 0x802B99EEF: ???

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable
==17065== at 0x4E518C8: _Alloc_hider (basic_string.h:275)
==17065== by 0x4E518C8: basic_string (basic_string.h:439)
==17065== by 0x4E518C8: mqtt::ssl_options::ssl_options() (ssl_options.cpp:26)
==17065== by 0x4E5099C: mqtt::connect_options::connect_options() (connect_options.cpp:25)
==17065== by 0x404CF8: MQTT::initClient() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x4070B5: MQTT::initialize() (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)
==17065== by 0x402E91: main (in /home/renesas/ws_berat/SVN/IoT_Gateway_Embedded_Linux/Software/sw-c/IoT_Gateway/build-IoT_Gateway-Desktop_Qt_5_7_0_GCC_64bit-Release/IoT_Gateway)

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.

`

Several classes take raw pointer to objects, like the constructor to the disconnect_options class:

disconnect_options(int timeout, token* tok);

In the cases where ownership is important, classes should take and keep shared pointers. When ownership is not important, weak pointers can be used.

In some test cases, there are some member initializations like this:

MQTTAsync_successData data = {
	.token = MESSAGE_ID,
};

This feature is called designated initializers. It is an addition to C99 but left out of C++11. According to The C++ Programming Language, 4th edition, section 44.3.3.2 (C Features Not Adopted by C++):

A few additions to C99 (compared with C89) were deliberately not adopted in C++:
[1] Variable-length arrays (VLAs); use vector or some form of dynamic array
[2] Designated initializers; use constructors

The C11 grammar has the designated initializers [ISO/IEC 9899:2011 N1570 Committee Draft - April 12, 2011]

6.7.9 Initialization

    initializer:
        assignment-expression
        { initializer-list }
        { initializer-list , }
    initializer-list:
        designation_opt initializer
        initializer-list , designationopt initializer
    designation:
        designator-list =
    designator-list:
        designator
        designator-list designator
    designator:
        [ constant-expression ]
        . identifier

However, the C++11 grammar does not have designated initializers [ISO/IEC 14882:2011 N3690 Committee Draft - May 15, 2013]

8.5 Initializers

    initializer:
        brace-or-equal-initializer
        ( expression-list )
    brace-or-equal-initializer:
        = initializer-clause
        braced-init-list
    initializer-clause:
        assignment-expression
        braced-init-list
    initializer-list:
        initializer-clause ...opt
        initializer-list , initializer-clause ...opt
    braced-init-list:
        { initializer-list ,opt }
        { }

For a project using MQTT I need to get binary payload.
I Make a workaround by introducing two new functions in message class:
int get_payload_size();
void* get_payload_bytes();

Implemented as follow:

int message::get_payload_size()
{
	return msg_.payloadlen;
}

void* message::get_payload_bytes()
{
	return msg_.payload;
}

So I can copy the byte array to a std::array in my application.

What do you think about this implementation?
Do you foreseen to add a get_payload() function for retrieving binary data?

I need to enable TLS option for my MQTT client. I need to have a way to set SSL options when the OPENSSL compiler flag is enabled.

Unit tests occasionally fail with persistence errors. The tests then pass if re-run.

Perhaps the tests need to clean up after themselves upon completion?

.................................E..E.E..E.E..E.E..E.E.E..E..E.E..E..E..E..E..E..E..E..E.........................................................................................


!!!FAILURES!!!
Test Results:
Run:  156   Failures: 0   Errors: 21


1) test: mqtt::async_client_test::test_connect_1_arg (E) 
uncaught exception of type mqtt::exception
- MQTT exception -2


2) test: mqtt::async_client_test::test_connect_2_args (E) 
uncaught exception of type mqtt::exception
- MQTT exception -2


3) test: mqtt::async_client_test::test_connect_3_args (E) 
uncaught exception of type mqtt::exception
- MQTT exception -2
...

Both the unit test binary (mqttpp-unittest) and the samples binaries require the paho-mqttpp3.lib. However, the CMake scripts are creating only the paho-mqttpp3.dll.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Temp\paho.mqtt.cpp\build_cmake>"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64

C:\Temp\paho.mqtt.cpp\build_cmake>cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX="C:\Temp\paho-cpp" -DPAHO_MQTT_C_PATH="C:\Temp\paho-c" -DPAHO_WITH_SSL=FALSE -DPAHO_BUILD_DOCUMENTATION=FALSE -DCMAKE_CXX_FLAGS_RELEASE="-IC:\Temp\GTest" -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=FALSE ..
-- The CXX compiler identification is MSVC 19.0.23918.0
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The C compiler identification is MSVC 19.0.23918.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Temp/paho.mqtt.cpp/build_cmake

C:\Temp\paho.mqtt.cpp\build_cmake>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.23918.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Scanning dependencies of target common_obj
[  6%] Building CXX object src/CMakeFiles/common_obj.dir/async_client.cpp.obj
async_client.cpp
[ 13%] Building CXX object src/CMakeFiles/common_obj.dir/client.cpp.obj
client.cpp
[ 20%] Building CXX object src/CMakeFiles/common_obj.dir/disconnect_options.cpp.obj
disconnect_options.cpp
[ 26%] Building CXX object src/CMakeFiles/common_obj.dir/iclient_persistence.cpp.obj
iclient_persistence.cpp
[ 33%] Building CXX object src/CMakeFiles/common_obj.dir/message.cpp.obj
message.cpp
[ 40%] Building CXX object src/CMakeFiles/common_obj.dir/response_options.cpp.obj
response_options.cpp
[ 46%] Building CXX object src/CMakeFiles/common_obj.dir/ssl_options.cpp.obj
ssl_options.cpp
[ 53%] Building CXX object src/CMakeFiles/common_obj.dir/string_collection.cpp.obj
string_collection.cpp
[ 60%] Building CXX object src/CMakeFiles/common_obj.dir/token.cpp.obj
token.cpp
[ 66%] Building CXX object src/CMakeFiles/common_obj.dir/topic.cpp.obj
topic.cpp
[ 73%] Building CXX object src/CMakeFiles/common_obj.dir/connect_options.cpp.obj
connect_options.cpp
[ 80%] Building CXX object src/CMakeFiles/common_obj.dir/will_options.cpp.obj
will_options.cpp
[ 80%] Built target common_obj
Scanning dependencies of target paho-mqttpp3
[ 86%] Linking CXX shared library paho-mqttpp3.dll
[ 86%] Built target paho-mqttpp3
Scanning dependencies of target mqttpp-unittest
[ 93%] Building CXX object test/unit/CMakeFiles/mqttpp-unittest.dir/test.cpp.obj
test.cpp
NMAKE : fatal error U1073: don't know how to make 'src\paho-mqttpp3.lib'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.

C:\Temp\paho.mqtt.cpp\build_cmake>dir src
 Volume in drive C is OSDisk
 Volume Serial Number is C2D6-0DCE

 Directory of C:\Temp\paho.mqtt.cpp\build_cmake\src

05/31/2017  04:35 PM    <DIR>          .
05/31/2017  04:35 PM    <DIR>          ..
05/31/2017  04:34 PM    <DIR>          CMakeFiles
05/31/2017  04:34 PM             1,449 cmake_install.cmake
05/31/2017  04:34 PM            25,405 Makefile
05/31/2017  04:34 PM    <DIR>          mqtt
05/31/2017  04:35 PM           594,944 paho-mqttpp3.dll
05/31/2017  04:35 PM               381 paho-mqttpp3.dll.manifest
               4 File(s)        622,179 bytes
               4 Dir(s)  809,278,922,752 bytes free

The C library is about to support binary LWT messages

When that is ready, the C++ library should add support as well.

Hello Sir,

After running the code,suppose connection lost and passes messgae.It throws exception and come back out of program.Like in python it keeps the message in queue and as soon as connection established it publish all previous message.
Which api should you which will work as python publish.My code is

pub.txt

also i am not able to get.message() in mqtt exception.
How will it support Automatic Reconnect and Offline Buffering.

Thanks
Ravi

I am trying to test the API by creating a client, so I include the client.h file. When I try to compile, the compiler can't find the following headers in file async_client.h:

#include "mqtt/token.h"
#include "mqtt/delivery_token.h"
#include "mqtt/iclient_persistence.h"
#include "mqtt/iaction_listener.h"
#include "mqtt/exception.h"
#include "mqtt/message.h"
#include "mqtt/callback.h"
#include "mqtt/iasync_client.h"

This files are all copied into /usr/local/include while installing. So because they are not in a folder named mqtt, the header files arent found. Compiling the shared libraries worked, though.
Am I missing something or is this a bug?

CMake for the C++ library is asking for version 3.1. Is there anything significant that would need to be done to support slightly older versions of CMake, perhaps back to version 2.8?

This is the version that comes with Ubuntu 14.04 LTS, Linux Mint 17 LTS, and (I believe) the latest Raspberry Pi Raspbian, Nvidia TX1, and a number of other embedded Linux boards. These could use autotools or Make, but it would be nice to have CMake work for them as it is likely to became the default build standard.

[ubuntu-14.04] $ cmake ..
CMake Error at CMakeLists.txt:20 (cmake_minimum_required):
  CMake 3.1 or higher is required.  You are running version 2.8.12.2

-- Configuring incomplete, errors occurred!

@guilhermeferreira

As we support new versions of the underlying MQTT C library, it's often convenient to build against the development tree of the C library, without installing it (and overwriting a stable version). This is supported in our GNU Make build system using the DEVELOP=1 flag.

The problem is that the C library does not use the standard include/ and lib/ placement of files, as required by CMake:

## extract Paho MQTT C include directory
get_filename_component(PAHO_MQTT_C_INC_DIR ${PAHO_MQTT_C_PATH}/include ABSOLUTE)

## extract Paho MQTT C library directory
get_filename_component(PAHO_MQTT_C_LIB_DIR ${PAHO_MQTT_C_PATH}/lib ABSOLUTE)

In the dev tree,
Headers are in ${PAHO_MQTT_C_PATH}/src
Libraries are in ${PAHO_MQTT_C_PATH}/build/output

So, just setting PAHO_MQTT_C_PATH isn't sufficient.

@guilhermeferreira

Why not use the naming conventions of cpp. namespaces, classes, methods should written with Upper Camel Case.

Currently, both build systems (CMake and Autotools) only check the existence of Paho MQTT C library, not its version. In case the Paho MQTT C changes its interface, some errors might occur.

Implement a wrapper class for MQTTAsync_createOptions, such as mqtt::create_options, and deploy a version of create() that accepts them and calls MQTTAsync_createWithOptions

First mentioned in #77

Hi,

I encountered a problem when compiling the sample c++ code. It seems lack of libraries files. Is it because there's no "make install" option to add those libraries into system path?

I also tried paho.mqtt.c, that compile has no issue happen.

jason2015@ubuntu:~/mqtt/paho.mqtt.cpp/src/samples$ make sync_publish
g++ -I.. -I/home/fmp/static/opensrc/mqtt/paho/org.eclipse.paho.mqtt.c/src -D_NDEBUG -Wall -std=c++0x -O2 -o sync_publish sync_publish.cpp -L../lib -L/home/fmp/static/opensrc/mqtt/paho/org.eclipse.paho.mqtt.c/src/linux_ia64 -lmqttpp -lmqttv3a
/usr/bin/ld: cannot find -lmqttv3a
collect2: error: ld returned 1 exit status
make: *** [sync_publish] Error 1

Best Regards!