You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Socketpool/Socket API somewhat awkwardly crams two different libraries into the same implementation, using LWIP for non-encrypted TCP and datagrams, and the IDF/mbed TLS library for encrypted communication. Since TLS isn't really a transport layer library, it would be better to separate it into a different implementation of Socket, so the current Socket code doesn't need to infer what kind of socket it's dealing with for each call.
@tannewt this would be implemented all the way through shared-bindings, correct? So we'd have a new Socket.c file under ssl recreating the functions that can use TLS?
Currently, the Socketpool/Socket API somewhat awkwardly crams two different libraries into the same implementation, using LWIP for non-encrypted TCP and datagrams, and the IDF/mbed TLS library for encrypted communication. Since TLS isn't really a transport layer library, it would be better to separate it into a different implementation of Socket, so the current Socket code doesn't need to infer what kind of socket it's dealing with for each call.
This is a follow up issue to PR #3854.
The text was updated successfully, but these errors were encountered: