Add information of MQTT Agent (library + demo), OTA (library + demos) and Device Defender Demo changes in History.txt. Also, mention about the coreMQTT-Agent-Demos repository in README.md
This change adds the OTA demos and required dependencies and helper components .
* Add demos , configs and project files
* Add subscription manager
* Add HTTP utils
* Submodules the OTA LTS 3.0 Library.
* Add OTA pal
* Fix build failure in STM32 Discovery MPU Projects
Privileged data region size needs to be increased because heap is now
placed in this region.
Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
Add URL file links to the MQTT agent documentation page.
Add comment blocks into each demo that also point toward the MQTT agent documentation to ensure users are aware the agent method exists.
From the FreeRTOS documentation, pdFREERTOS_ERRNO_ENOSPC means that timeout occurred before any data could be sent or received.
- In the plaintext transport-interface implementation, we would directly return `-pdFREERTOS_ERRNO_ENOSPC`. However, an error like this can occur when the TCP buffer is full, so this ought to be retriable. Libraries that consume the transport interface interpret a return value of 0 to mean that send/recv can be invoked again to get the data. As such, we should appropriately set the return value as 0 when the status is `-pdFREERTOS_ERRNO_ENOSPC`.
- In the mbedTLS port, we would directly return whatever `FreeRTOS_send` or `FreeRTOS_recv` returns. However, sometimes, the return value can be an error. In such cases, we ought to map an error from FreeRTOS+TCP to an equivalent error in mbedTLS. In the case of `-pdFREERTOS_ERRNO_ENOSPC`, we map that to `MBEDTLS_ERR_SSL_TIMEOUT`. When the mbedTLS transport-interface send/recv wrapper sees that value, it appropriately returns 0, so that the library can retry the send/recv. I've verified that when the mbedTLS port returns an error, that same error is returned by `mbedtls_ssl_write` & `mbedtls_ssl_read`.
- The TCP socket may have a receive block time. If bytesToRecv is greater than 1 then a frame is likely already part way through reception and blocking to wait for the desired number of bytes to be available is the
most efficient thing to do. If bytesToRecv is 1 then this may be a speculative call to read to find the start of a new frame, in which case blocking is not desirable as it could block an entire protocol agent task for the duration of the read block time and therefore negatively impact performance. So if bytesToRecv is 1 then don't call recv unless it is known that bytes are already available.
Co-authored-by: abhidixi11 <44424462+abhidixi11@users.noreply.github.com>
Co-authored-by: RichardBarry <3073890+RichardBarry@users.noreply.github.com>
