1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
libwebsockets/lib/system
Andy Green 28ce32af64 client: secure streams
Secure Streams is an optional layer on top of lws that separates policy
like endpoint selection and tls cert validation into a device JSON
policy document.

Code that wants to open a client connection just specifies a streamtype name,
and no longer deals with details like the endpoint, the protocol (!) or anything
else other than payloads and optionally generic metadata; the JSON policy
contains all the details for each streamtype.  h1, h2, ws and mqtt client
connections are supported.

Logical secure streams outlive any particular connection and supports "nailed-up"
connectivity regardless of underlying connection stability.
2020-03-04 12:17:49 +00:00
..
async-dns client: secure streams 2020-03-04 12:17:49 +00:00
dhcpclient coverity: fixes plugin error path leak and logging method sign check 2020-01-14 08:23:25 +00:00
ntpclient client: secure streams 2020-03-04 12:17:49 +00:00
README.md lws_system: helpers for attaching to existing event loop from other threads 2020-01-05 22:17:58 +00:00
system.c client: secure streams 2020-03-04 12:17:49 +00:00

LWS System Helpers

Lws now has a little collection of helper utilities for common network-based functions necessary for normal device operation, eg, async DNS, ntpclient (necessary for tls validation), and DHCP client.

Conventions

If any system helper is enabled for build, lws creates an additional vhost "system" at Context Creation time. Wsi that are created for the system features are bound to this. In the context object, this is available as .vhost_system.

Attaching to an existing context from other threads

To simplify the case different pieces of code want to attach to a single lws_context at runtime, from different thread contexts, lws_system has an api via an lws_system operation function pointer where the other threads can use platform-specific locking to request callbacks to their own code from the lws event loop thread context safely.

For convenience, the callback can be delayed until the system has entered or passed a specified system state, eg, LWS_SYSTATE_OPERATIONAL so the code will only get called back after the network, ntpclient and auth have been done. Additionally an opaque pointer can be passed to the callback when it is called from the lws event loop context.

Implementing the system-specific locking

lws_system_ops_t struct has a member .attach

	int (*attach)(struct lws_context *context, int tsi, lws_attach_cb_t *cb,
		      lws_system_states_t state, void *opaque,
		      struct lws_attach_item **get);

This should be defined in user code as setting locking, then passing the arguments through to a non-threadsafe helper

int
__lws_system_attach(struct lws_context *context, int tsi, lws_attach_cb_t *cb,
		    lws_system_states_t state, void *opaque,
		    struct lws_attach_item **get);

that does the actual attach work. When it returns, the locking should be unlocked and the return passed back.

Attaching the callback request

User code should call the lws_system_ops_t .attach function like

	lws_system_get_ops(context)->attach(...);

The callback function which will be called from the lws event loop context should look like this

void my_callback(struct lws_context *context, int tsi, void *opaque);

with the callback function name passed into the (*attach)() call above. When the callback happens, the opaque user pointer set at the (*attach)() call is passed back to it as an argument.