eclipse / paho.mqtt.cpp Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
Trying to connect to a server (mqtt.carriots.com) requiring an empty password:
Why not use the naming conventions of cpp. namespaces, classes, methods should written with Upper Camel Case.
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.
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.
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.
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.
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,
/**
/**
Could you please suggest a solution?
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?
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
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:
ifdefs
.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?
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:
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
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
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.
Linkage library /lib/libpaho-mqttpp3.dll.a is installed, but /bin/libpaho-mqttpp3.dll is not.
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;
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;
}
}
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
^
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:
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?
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.
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
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;
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.
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!
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:
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...
Using connect_options(username, password) doesn't really set connection username nor password as private opts_ member is not updated.
Header mqtt/types.h referenced by:
not installed with make install
.
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'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
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.
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
...
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.
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.
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 }
{ }
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.
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
also i am not able to get.message() in mqtt exception.
How will it support Automatic Reconnect and Offline Buffering.
Thanks
Ravi
The C library is about to support binary LWT messages
When that is ready, the C++ library should add support as well.
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!
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.
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:
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.
`
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.
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.
Is it possible to use file wildcards in the CMake and autotools builds? I think we can make the following assumptions:
The only complication is which of these should be excluded if SSL is not opted.
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?
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?
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?
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:
token
and delivery
token objects.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.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
.itoken
!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.
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!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.