* 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>
### 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>
* Update code sizes after adding verison number
* Round as much as possible when multiplying by 1024
* Add code size when no optimisation is used
* Update totals
* Change MQTT RC1 to coreMQTT
* Add link to gcc arm toolchain
* Update link
* Use english spellings
Co-authored-by: Gary Wicker <14828980+gkwicker@users.noreply.github.com>
