1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
libwebsockets/lib/secure-streams/protocols
Andy Green 1a93e73402 fakewsi: replace with smaller substructure
Currently we always reserve a fakewsi per pt so events that don't have a related actual
wsi, like vhost-protocol-init or vhost cert init via protocol callback can make callbacks
that look reasonable to user protocol handler code expecting a valid wsi every time.

This patch splits out stuff that user callbacks often unconditionally expect to be in
a wsi, like context pointer, vhost pointer etc into a substructure, which is composed
into struct lws at the top of it.  Internal references (struct lws is opaque, so there
are only internal references) are all updated to go via the substructre, the compiler
should make that a NOP.

Helpers are added when fakewsi is used and referenced.

If not PLAT_FREERTOS, we continue to provide a full fakewsi in the pt as before,
although the helpers improve consistency by zeroing down the substructure.  There is
a huge amount of user code out there over the last 10 years that did not always have
the minimal examples to follow, some of it does some unexpected things.

If it is PLAT_FREERTOS, that is a newer thing in lws and users have the benefit of
being able to follow the minimal examples' approach.  For PLAT_FREERTOS we don't
reserve the fakewsi in the pt any more, saving around 800 bytes.  The helpers then
create a struct lws_a (the substructure) on the stack, zero it down (but it is only
like 4 pointers) and prepare it with whatever we know like the context.

Then we cast it to a struct lws * and use it in the user protocol handler call.
In this case, the remainder of the struct lws is undefined.  However the amount of
old protocol handlers that might touch things outside of the substructure in
PLAT_FREERTOS is very limited compared to legacy lws user code and the saving is
significant on constrained devices.

User handlers should not be touching everything in a wsi every time anyway, there
are several cases where there is no valid wsi to do the call with.  Dereference of
things outside the substructure should only happen when the callback reason shows
there is a valid wsi bound to the activity (as in all the minimal examples).
2020-07-20 06:28:52 +01:00
..
README.md client: secure streams 2020-03-04 12:17:49 +00:00
ss-h1.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00
ss-h2.c lws_netdev: use lws_settings 2020-07-07 15:23:19 +01:00
ss-mqtt.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00
ss-raw.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00
ss-ws.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00

Lws Protocol bindings for Secure Streams

This directory contains the code wiring up normal lws protocols to Secure Streams.

The lws_protocols callback

This is the normal lws struct lws_protocols callback that handles events and traffic on the lws protocol being supported.

The various events and traffic are converted into calls using the Secure Streams api, and Secure Streams events.

The connect_munge helper

Different protocols have different semantics in the arguments to the client connect function, this protocol-specific helper is called to munge the connect_info struct to match the details of the protocol selected.

The ss->policy->aux string is used to hold protocol-specific information passed in the from the policy, eg, the URL path or websockets subprotocol name.

The (library-private) ss_pcols export

Each protocol binding exports two things to other parts of lws (they are not exported to user code)

  • a struct lws_protocols, including a pointer to the callback

  • a struct ss_pcols describing how secure_streams should use, including a pointer to the related connect_munge helper.

In ./lib/core-net/vhost.c, enabled protocols are added to vhost protcols lists so they may be used. And in ./lib/secure-streams/secure-streams.c, enabled struct ss_pcols are listed and checked for matches when the user creates a new Secure Stream.