Since `mbedtls_error.c` is already part of the mbedTLS submodule, the duplicate files are removed from this repository.
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
* Added spell check
* All words
* Add a missing word
* Fix header checks
* Fix header checks v1
* Fix header check v2
* Updated freertos link in header
* Fixed afr link in the header
* Fix last of header checks
* Update the spell check script to check amazon licensed files only
* Fixed paths and added comments
* Try with modified repo
* Add inplace substitute option to sed
* Use official repo as the spell checker source
* Add vendor file to the ignored list
Co-authored-by: root <root@ip-172-31-5-28.us-west-2.compute.internal>
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>
By removing the definition of the NetworkContext struct in the header file, we allow the application to define it. This allows an application writer to use multiple transports in the same compilation unit. That way, multiple .c files do not have to be created for each transport.
This updates the platform and logging directory and moves it to the following places:
FreeRTOS\FreeRTOS-Plus\Source\Utilities
FreeRTOS\FreeRTOS-Plus\Source\Application-Protocols\network_transport\freertos_plus_tcp
Project files are updated to follow suite. All updated demos are tested to work as expected.
tianmc1
Oscar Michael Abrina
Aniruddha Kanhere
Archit Aggarwal
Joseph Julicher