Since dcf3bbb980 introduced
autoKeepAlive, users should not send a ping message manually
unless it is disabled.
Change-Id: I4b717e2aebc8f40cabf009d4df7e1d146988d434
Fixes: QTBUG-79444
Reviewed-by: hjk <hjk@qt.io>
Use the QMqttClient::connectToHostEncrypted() version taking a
QSslConfiguration instead of applying global settings.
Furthermore, the deprecated version will be removed in Qt6.
Change-Id: I4b2a9ff2616ed1c0c645d0081719f2d40c6e3b20
Reviewed-by: hjk <hjk@qt.io>
get rid of dubious code by generalizing template specializations
Change-Id: Ib23f423f10e63985a11d18a9cfd37178ad18551e
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
In certain scenarios, a user wants to manually handle the keepAlive.
Introduce autoKeepAlive as a property. If set to false, then the user
needs to handle the keepAlive by invoking requestPing.
The default for this property is true and keeps the current behavior.
Task-number: QTBUG-76782
Change-Id: I073874e6bdacf3c8d128c20431606affe1d9eeb1
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
closeConnection() clears m_readBuffer, so that
`m_readBuffer.constData() + m_readPosition` accesses a disposed memory
Change-Id: Ide4e4d8fdafe81181fceb9ebe2692aaa25ba8034
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Initially the keepAlive was considered to be specified in ms to more
match the Qt API. However, no server allows this granularity and the
specs also state seconds. Internally it was using this pattern already.
Change-Id: I0a25d1ef636c2b909997223c631dc248b613536c
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
A will message is allowed to be empty. Hence, check whether a will topic
exists to identify incorporating the last will to the connect message.
Task-number: QTBUG-76783
Change-Id: Ifb7f5467e8e7e70c6d9c050b36a35df2419f4171
Reviewed-by: hjk <hjk@qt.io>
amortized O(1) for QHash VS. stable O(log n) for QMap
+ optimize usage cases by decreasing the amount of key lookups
Change-Id: I169b2d97f07854ce5aca030321820a866d0038ed
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
as per MQTT Version 5.0 Standard, `Maximum Receive` property
is the maximum amount of unaknowledged messages (QoS>0),
whilst `Maximum QoS` property is the message's maximum allowed QoS level.
Change-Id: Ia23b259a95f075f71b7eb090f48fc9143aeb4811
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Examples requiring a user interface recently need to check for its
availability.
Task-number: QTQAINFRA-2576
Change-Id: I731dfee16bd1a9b5eb0396433213243dfa9b23da
Reviewed-by: Liang Qi <liang.qi@qt.io>
For MQTT 5 the fake server did not send any property information. Hence,
the client (potentially) read among the buffer.
Change-Id: I58c7d1b4a1f15a0803c04495c82537f648c8a642
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
So far, the implementation relied on the datagrams received to be
correct. This can cause buffer overwrites, including crashes or worse.
While unlikely, verify that requested read size matches the existing
buffer.
Change-Id: I695318142348e58b3b9568135896c52da75109e7
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Change-Id: If08d050a92db812e95a668d141d8774e56f9516e
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
When users click the Qt version number on the bread crumb bar in
the Qt Qt MQTT docs, they are directed to the Qt for Automation
docs at doc.qt.io.
Change-Id: Ib59b3497dacb96049ddaaa440f596f2ea67822e1
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Added documentation flag and also mark the function itself as
deprecated.
Change-Id: I4cc84b2c79ee0849d09b91e1778f38da5478b3c0
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
