[Libwebsockets] LWS on the Texas Instruments SimpleLink CC3220.
andy at warmcat.com
Sun May 17 17:28:26 CEST 2020
On 5/17/20 2:54 PM, Ralph Corderoy wrote:
> Hi Andy,
> Thanks for the prompt reply.
>>> (TI say this is to make it more awkward to accidentally have a
>>> plain-text connection.)
> Quite. I suspect it's more to do with fitting TLS in given the narrow
> interconnect between the two CPUs.
TLS is very expensive in this class of system... maybe it's as much
about pressure on RAM on the application CPU side. If it's not all
integrated on one die, it's not ideal securitywise that what passes
between the two CPUs is plaintext.
I guess it has no ALPN, if you want h2 you'll have to use the recently
contributed "prior knowledge" stuff
but that also assumes tls so it'll also need fiddling even so. The rest
of the actual h2 implementation doesn't rely on tls and it should be
willing to work without it.
>>> It follows from the above that FreeRTOS is providing threading, a
>>> heap, ..., but not a TCP/IP stack.
>> Normally freertos is paired with lwip. If there's no lwip on your cpu
>> there's no posix sockets, no socket fd and no easy way for lws to talk
>> to it IIUI.
> TI provide a range of SlNet* APIs which look like BSD sockets if
> squinting, and ‘SlNetSock provides a standard BSD API, built atop the
> SlNet* APIs’ says
> Of course, the seamlessness of the BSD API support may be found wanting
> when stressed by LWS. For example, AFAICS its select(2) works for
> reading, accepts, and connects, but not writes so there's no detecting
> when the output buffer has space.
It's not a million miles away by the sound of it, but no POLLOUT means
you can't regulate your sending to what the link is doing from event
wakes. I guess it regulates it by just failing sends.
What I'd look at is restricting your sends to below 1 mtu (eg, like 1200
bytes) to increase the chance it rejects the whole send, and handle
fails by using an lws_sul to schedule a retry in a fixed time, eg in
+10ms if you don't have any real throughput requirement. Fiddle the
delay according to latency and power tradeoff.
>> Tbh it sounds like the kind of proprietary mess it's best to stay as
>> far as possible from.
> Yes. Did I mention its HTTP client only allows access to a restricted
> set of headers from the server's reply, blocking implementation of an
> upgrade to WebSocket? :-)
> Next time, I'd be interested in a plain Cortex-M4 with FreeRTOS and
> lwip, or Zephyr, aided by something like the Microchip ATECC608A.
>> From lws side, if there's posix sockets api it can likely interface to
>> it without huge pain, since the tls is handled transparently. If
>> there's not, the key point is how can you do the equivalent of a poll
>> wait? It seems yoll basically need to add a plat implementation if
>> it's like that.
>> LWS_PLAT_FREERTOS is already supporting lwip + freertos, if it's
>> basically that wired up to an opaque but transparent-in-operation tls
>> proxy basically then it should work out.
> Yes, this sounds closest to what appears to be there. I'll take a look.
> Thanks for the guidance.
More information about the Libwebsockets