core_mqtt.h and other coreMQTT headers pull in core_mqtt_config.h and core_mqtt_config_defaults.h.
core_mqtt_config_defaults.h defines empty logging macros. This means every application that uses coreMQTT needs to be careful to set up the logging stack before including core_mqtt.h or they may mysteriously not have logging output.
The logging setup should be in each compilation object, not set up in headers. This moves the inclusion of default logging macros from the headers to the library c files.
This fixes the issue with the logging macros for customers who do not set the logging macros in their core_mqtt_config.h. However, those who do enable logging for coreMQTT will still have their coreMQTT logging setup in all their c files using coreMQTT.
* Change logging level on CONNACK from 'Info' to 'Debug' to reflect CONNECT
* Changed Debug logging to Error logging where MQTTBadResponse is set
* Fix formatting
* Update source/core_mqtt_serializer.c
Co-authored-by: Archit Gupta <71798289+archigup@users.noreply.github.com>
* Change LogInfo to LogDebug on line 958 to mirror line 970
* Fix comments with inconsistent byte indexes
Co-authored-by: Hendrickson <johnrhen@88665a3d649f.ant.amazon.com>
Co-authored-by: Archit Gupta <71798289+archigup@users.noreply.github.com>
Non-functional change to handle all enum values for MQTTPublishState_t
and MQTTQoS_t in switch statements. This allows users to compile with
-Werror=switch-enum.
* Update version numbers
* Update CHANGELOG.md
* Add guards for C++ linkage
* Link to Memory estimates markdown from README
* Make possible to override CMake C Standard for tests
The debug-level log that is printed on not receiving any data from the network (when the first byte of an MQTT packet is attempted for reading) can be problematic when the transport interface TransportInterfaceRecv_t function is implemented in non-blocking behavior.
The problem it will cause is overwhelming logging of the message when MQTT_ProcessLoop API is called with a non-zero timeout (or the API is called multiple times with zero timeout but within a loop until some data is achieved). Due to over-logging of this message, the DEBUG logging level configured build of the coreMQTT library will be non-valuable.
This PR removes the problematic log statement.
* Fix keep alive checking interval
* Update default ping response timeout to a more reasonable value
* Update changelog
* Update doc for MQTT_PINGRESP_TIMEOUT_MS
Update API of the transport interface functions for the following:
* Transport recv() should NOT block when requested to read a single byte. It MAY block for the underlying socket timeout when requested to read n > 1 bytes.
* Transport send() should NOT return an error when the send fails because of a full TX buffer of the underlying network stack, so that the calling library can retry the send operation.
Update API doc to mention that the keep-alive mechanism is not supported by MQTT_ProcessLoop API when a dummy timer function that always returns zero is supplied to the library.
* Fix issue of data recv being interrupted
* Rename elapsedTimeMs variable to its express its new meaning
* Use configuration const for recvExact timeout
* Remove timeout check from discardPacket and address CI check failures
* Fix more CI check failures
* Remove another unused local variable
* Re-instate timeout in discard to reduce scope of changes
* Remove unused variable again
* Fix failing unit test
* Rename new config macro, and attempt to fix CBMC failures
* Doc: Improvement suggestions from code review
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
* Fix quality check failures
* Add test case to check partial network reads with zero timeout duration for ProcessLoop
* style: Improving naming
* Address complexity failure
* Address comments
* Doc: Add blocking time equation of Receive/ProcessLoop functions in their API doc
* Improvement in API doc
* Set MQTT_RECV_POLLING_TIMEOUT_MS so that recvExact runs in one iteration always for cbmc.
* doc: Add information about zero return value for Transport_Recv_t
* fix: prevent possibility of infinite loop in timeout logic of ProcessLoop
* style: Minor changes
* hygiene: minor name fix
* fix: Possibility of infinite loop in sendPacket
* Add the new configuration to doxygen
* test: Add mock transport send function that always returns zero
* fix: Issues in sendPacket and sendPublish
* test: add test for sendPacket timeout
* Update Timer Overflow test
* test: temporarily comment out unused variable
* test: fix the timer overflow test
* Address review comments
* style: make log messages concise
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
* Update call sites of sendPacket to treat partial sends as failure
* test: Add send timeout coverage for APIs calling sendPacket
* test: Add coverage for send timeout in APIs calling sendPacket
* test: review feedback
* ci: address spell check error
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
Co-authored-by: Sarena Meas <sarem@amazon.com>
* Fix issue of data recv being interrupted
* Rename elapsedTimeMs variable to its express its new meaning
* Use configuration const for recvExact timeout
* Remove timeout check from discardPacket and address CI check failures
* Fix more CI check failures
* Remove another unused local variable
* Re-instate timeout in discard to reduce scope of changes
* Remove unused variable again
* Fix failing unit test
* Rename new config macro, and attempt to fix CBMC failures
* Doc: Improvement suggestions from code review
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
* Fix quality check failures
* Add test case to check partial network reads with zero timeout duration for ProcessLoop
* style: Improving naming
* Address complexity failure
* Address comments
* Doc: Add blocking time equation of Receive/ProcessLoop functions in their API doc
* Improvement in API doc
* Set MQTT_RECV_POLLING_TIMEOUT_MS so that recvExact runs in one iteration always for cbmc.
* doc: Add information about zero return value for Transport_Recv_t
* fix: prevent possibility of infinite loop in timeout logic of ProcessLoop
* style: Minor changes
* hygiene: minor name fix
* fix: Possibility of infinite loop in sendPacket
* Add the new configuration to doxygen
* test: Add mock transport send function that always returns zero
* fix: Issues in sendPacket and sendPublish
* test: add test for sendPacket timeout
* Update Timer Overflow test
* test: temporarily comment out unused variable
* test: fix the timer overflow test
* Address review comments
* style: make log messages concise
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
Co-authored-by: Muneeb Ahmed <54290492+muneebahmed10@users.noreply.github.com>
Co-authored-by: Sarena Meas <sarem@amazon.com>
- Update core_mqtt_config.h to specify logging level as LOG_NONE
- Update GA to set logging level as LOG_DEBUG
- Fix compile error in LogDebug of recvExact
### Problem
The `MQTT_ProcessLoop` and `MQTT_ReceiveLoop` read incoming MQTT packet payload over the network by calling the `recvExact` function. The `recvExact` function can be called multiple times to read the expected number of bytes for the MQTT packet but it also implements a timeout functionality of receiving the expected number of payload within the timeout value passed to the function.
This causes problems when the `Transport_Recv` call returns less than requested number of bytes, and there is a timeout (for example, when calling `MQTT_ProcessLoop` with 0ms duration) which causes the function to assume failure instead of reading the remaining payload of the MQTT packet by calling `Transport_Recv` again. Thus, in such cases, the MQTT connection is severed prematurely even though there is a high probability of receiving the remaining bytes of the MQTT packet over the network.
### Solution
Instead of implementing a timeout on the entire duration of receiving the expected number of remaining MQTT packet bytes in `recvExact`, the use of timeout is being changed to be relevant only on the total time of receiving 0 bytes over the network over multiple calls to `Transport_Recv`.
As this modified meaning of the timeout duration is now unrelated to the timeout duration that the `MQTT_ProcessLoop` or `MQTT_ReceiveLoop` functions are called, a new configuration constant for the `recvExact` timeout value, `MQTT_RECV_POLLING_TIMEOUT_MS`, has been added to the library which will carry a default value of 10ms.
Co-authored-by: Sarena Meas <sarem@amazon.com>
This follows changes from FreeRTOS/FreeRTOS@398abba. The const qualifier is removed from send/recv because there are transport implementations that require a member of the network context to be modified such as in the case of mbedtls.
This updates the coreMQTT library so as to resend a PUBACK and PUBREC for an incoming duplicate publish packet, irrespective of the broker setting the DUP flag.
* Set publish payload to NULL when zero length
* Add unit test for zero length payload
* Fix unit tests for deserialize publish
* Rename setupWillInfo to setupPublishInfo
* Remove void * from memset
* Add version numbers
* Add missing @file tags
* Update lexicon.txt
* Update @brief tag for MQTT cbmc state
Co-authored-by: Gary Wicker <14828980+gkwicker@users.noreply.github.com>