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
Recently in Discord, @tannewt encountered that zephyr uses different numeric values for some socket-related constants (vs lwip)
For core ssl support to work with pure Python socket implementations, such as wiznet, we had to promise that socket constants used by the ssl implementation would be the same numeric constants always, regardless of the internal implementation of sockets.
I think that the sole constant we depend on is is SOCK_STREAM = 1. This is because SSL can work on STREAM type sockets but not DGRAM type sockets.
@tannewt suggested that instead of the current approach of promising SOCK_STREAM = 1 (the lwip value, used by raspberrypi & espressif), anytime we enable ssl in the core we could provide a minimal socket library with SOCK_STREAM = (some value), not necessarily 1.
wiznet currently has to adapt to different SOCK_ type numbering anyway, because wiznet uses 0x21 for SOCK_STREAM. (though it does so in a somewhat clever way that assumes the current values of 1 & 2)
Marking as a 10.0 milestone because undoing the promise that SOCK_STREAM=1 is an incompatible change.
The text was updated successfully, but these errors were encountered:
Recently in Discord, @tannewt encountered that zephyr uses different numeric values for some socket-related constants (vs lwip)
For core ssl support to work with pure Python socket implementations, such as wiznet, we had to promise that socket constants used by the ssl implementation would be the same numeric constants always, regardless of the internal implementation of sockets.
I think that the sole constant we depend on is is
SOCK_STREAM = 1
. This is because SSL can work on STREAM type sockets but not DGRAM type sockets.@tannewt suggested that instead of the current approach of promising
SOCK_STREAM = 1
(the lwip value, used by raspberrypi & espressif), anytime we enable ssl in the core we could provide a minimalsocket
library withSOCK_STREAM = (some value)
, not necessarily 1.Then, wiznet would have to do something like
wiznet currently has to adapt to different SOCK_ type numbering anyway, because wiznet uses 0x21 for SOCK_STREAM. (though it does so in a somewhat clever way that assumes the current values of 1 & 2)
Marking as a 10.0 milestone because undoing the promise that SOCK_STREAM=1 is an incompatible change.
The text was updated successfully, but these errors were encountered: