- Made tcp_transport_errors codes public to indicate
TCP connection issues not covered in socket's errno
- Added API to translate tcp_transport_error codes
to esp_err_t codes for TCP Transport
Co-authored-by: Shubham Kulkarni <shubham.kulkarni@espressif.com>
Transport's error_handle is used to capture different types of errors
including esp_err_t from esp-tls and socket/system errors.
This change adds the following error codes for TCP transport:
* connection closed by a FIN flag (clean closure from server)
* DNS resolution problem
* connection timeout
These errors are already defined in esp-tls component and since this
component will be used in the future for both TCP and SSL transport, we
currently report these issues in transport::error_handle::esp_tls_last_error
of standard esp error type (esp_err_t)
Closes https://github.com/espressif/esp-mqtt/issues/182
Client could choose if they want to receive control packets and handle
them.
* If disabled (default) the transport itself tries to handle PING
and CLOSE frames automatically during read operation. If handled
correctly, read outputs 0 indicating no (actual app) data received.
* if enabled, all control frames are passed to the application to be
processed there.
Closes https://github.com/espressif/esp-idf/issues/6307
Internal tcp_transport functions could now use custom socket operations.
This is used for WebSocket transport, when we typically wait for clean
connection closure, i.e. selecting for read/error with expected errno or
recv size=0 while socket readable (=connection terminated by FIN flag)
tcp-transport component did not support wait forever. this update uses value of -1 to request this state.
websocket client uses timeouts in RTOS ticks. fixed recalculation to ms (including special value of -1) to use correctly tcp-transport component
Closes https://github.com/espressif/esp-idf/issues/4316
Euripedes Rocha