1# Implementation background
2
3## Client connection Queueing
4
5By default lws treats each client connection as completely separate, and each is
6made from scratch with its own network connection independently.
7
8If the user code sets the `LCCSCF_PIPELINE` bit on `info.ssl_connection` when
9creating the client connection though, lws attempts to optimize multiple client
10connections to the same place by sharing any existing connection and its tls
11tunnel where possible.
12
13There are two basic approaches, for h1 additional connections of the same type
14and endpoint basically queue on a leader and happen sequentially.
15
16For muxed protocols like h2, they may also queue if the initial connection is
17not up yet, but subsequently the will all join the existing connection
18simultaneously "broadside".
19
20## h1 queueing
21
22The initial wsi to start the network connection becomes the "leader" that
23subsequent connection attempts will queue against.  Each vhost has a dll2_owner
24`wsi->dll_cli_active_conns_owner` that "leaders" who are actually making network
25connections themselves can register on as "active client connections".
26
27Other client wsi being created who find there is already a leader on the active
28client connection list for the vhost, can join their dll2 wsi->dll2_cli_txn_queue
29to the leader's wsi->dll2_cli_txn_queue_owner to "queue" on the leader.
30
31The user code does not know which wsi was first or is queued, it just waits for
32stuff to happen the same either way.
33
34When the "leader" wsi connects, it performs its client transaction as normal,
35and at the end arrives at `lws_http_transaction_completed_client()`.  Here, it
36calls through to the lws_mux `_lws_generic_transaction_completed_active_conn()`
37helper.  This helper sees if anything else is queued, and if so, migrates assets
38like the SSL *, the socket fd, and any remaining queue from the original leader
39to the head of the list, which replaces the old leader as the "active client
40connection" any subsequent connects would queue on.
41
42It has to be done this way so that user code which may know each client wsi by
43its wsi, or have marked it with an opaque_user_data pointer, is getting its
44specific request handled by the wsi it expects it to be handled by.
45
46A side effect of this, and in order to be able to handle POSTs cleanly, lws
47does not attempt to send the headers for the next queued child before the
48previous child has finished.
49
50The process of moving the SSL context and fd etc between the queued wsi continues
51until the queue is all handled.
52
53## muxed protocol queueing and stream binding
54
55h2 connections act the same as h1 before the initial connection has been made,
56but once it is made all the queued connections join the network connection as
57child mux streams immediately, "broadside", binding the stream to the existing
58network connection.
59