1
0
Fork 0
mirror of https://github.com/warmcat/libwebsockets.git synced 2025-03-16 00:00:07 +01:00
libwebsockets/lib/core-net
Andy Green 39e89328b0 logs: prioritize WITH_NO_LOGS even in release
Really not having any logs makes it difficult to know what is really
happening, but if that's you're thing this will align debug and release
modes to just have ERR and USER if you give WITH_NO_LOGS
2021-03-16 08:20:03 +00:00
..
adopt.c smp: additional locking for libuv 2020-10-11 13:04:52 +01:00
client.c cleaning 2020-01-05 22:17:58 +00:00
close.c close: ensure any pending sul_connect_timeout cancelled 2020-10-09 21:33:13 +01:00
CMakeLists.txt context: option to disable system state management 2020-06-27 07:57:22 +01:00
connect.c event libs: default to building as dynamically loaded plugins 2020-08-31 16:51:37 +01:00
detailed-latency.c detailed latency stats 2019-09-22 03:06:59 -07:00
dummy-callback.c logging: reduce serving logs 2020-11-25 07:42:09 +00:00
lws-dsh.c logs: prioritize WITH_NO_LOGS even in release 2021-03-16 08:20:03 +00:00
network.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00
output.c docs: add README-debugging.md and provide example points for decrypted traffic handling 2020-07-30 16:23:59 +01:00
pollfd.c smp: lws_mutex_refcount: add assert held helper 2020-08-31 16:51:37 +01:00
private-lib-core-net.h vhost_destroy: refactor 2021-01-22 16:22:25 +00:00
README.md minimal-http-client-multi: add POST 2020-02-21 17:32:41 +00:00
sequencer.c sul: multiple timer domains 2020-06-02 08:37:10 +01:00
server.c event libs: default to building as dynamically loaded plugins 2020-08-31 16:51:37 +01:00
service.c testapp: extpoll: add back missing EXTERNAL_POLL pieces 2020-09-18 09:31:29 +01:00
socks5-client.c fakewsi: replace with smaller substructure 2020-07-20 06:28:52 +01:00
sorted-usec-list.c fix zombie sul detection 2020-10-10 06:48:24 +01:00
state.c lws_smd: system message distribution 2020-06-27 07:57:22 +01:00
stats.c cleaning 2020-01-05 22:17:58 +00:00
vhost.c vhost_destroy: refactor 2021-01-22 16:22:25 +00:00
wsi-timeout.c smp: additional locking for libuv 2020-10-11 13:04:52 +01:00
wsi.c smp: lws_wsi_tsi 2020-10-11 13:04:29 +01:00

Implementation background

Client connection Queueing

By default lws treats each client connection as completely separate, and each is made from scratch with its own network connection independently.

If the user code sets the LCCSCF_PIPELINE bit on info.ssl_connection when creating the client connection though, lws attempts to optimize multiple client connections to the same place by sharing any existing connection and its tls tunnel where possible.

There are two basic approaches, for h1 additional connections of the same type and endpoint basically queue on a leader and happen sequentially.

For muxed protocols like h2, they may also queue if the initial connection is not up yet, but subsequently the will all join the existing connection simultaneously "broadside".

h1 queueing

The initial wsi to start the network connection becomes the "leader" that subsequent connection attempts will queue against. Each vhost has a dll2_owner wsi->dll_cli_active_conns_owner that "leaders" who are actually making network connections themselves can register on as "active client connections".

Other client wsi being created who find there is already a leader on the active client connection list for the vhost, can join their dll2 wsi->dll2_cli_txn_queue to the leader's wsi->dll2_cli_txn_queue_owner to "queue" on the leader.

The user code does not know which wsi was first or is queued, it just waits for stuff to happen the same either way.

When the "leader" wsi connects, it performs its client transaction as normal, and at the end arrives at lws_http_transaction_completed_client(). Here, it calls through to the lws_mux _lws_generic_transaction_completed_active_conn() helper. This helper sees if anything else is queued, and if so, migrates assets like the SSL *, the socket fd, and any remaining queue from the original leader to the head of the list, which replaces the old leader as the "active client connection" any subsequent connects would queue on.

It has to be done this way so that user code which may know each client wsi by its wsi, or have marked it with an opaque_user_data pointer, is getting its specific request handled by the wsi it expects it to be handled by.

A side effect of this, and in order to be able to handle POSTs cleanly, lws does not attempt to send the headers for the next queued child before the previous child has finished.

The process of moving the SSL context and fd etc between the queued wsi continues until the queue is all handled.

muxed protocol queueing and stream binding

h2 connections act the same as h1 before the initial connection has been made, but once it is made all the queued connections join the network connection as child mux streams immediately, "broadside", binding the stream to the existing network connection.