mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-16 00:00:07 +01:00
48366de1d1
An lws context usually contains a processwide fd -> wsi lookup table. This allows any possible fd returned by a *nix type OS to be immediately converted to a wsi just by indexing an array of struct lws * the size of the highest possible fd, as found by ulimit -n or similar. This works modestly for Linux type systems where the default ulimit -n for a process is 1024, it means a 4KB or 8KB lookup table for 32-bit or 64-bit systems. However in the case your lws usage is much simpler, like one outgoing client connection and no serving, this represents increasing waste. It's made much worse if the system has a much larger default ulimit -n, eg 1M, the table is occupying 4MB or 8MB, of which you will only use one. Even so, because lws can't be sure the OS won't return a socket fd at any number up to (ulimit -n - 1), it has to allocate the whole lookup table at the moment. This patch looks to see if the context creation info is setting info->fd_limit_per_thread... if it leaves it at the default 0, then everything is as it was before this patch. However if finds that (info->fd_limit_per_thread * actual_number_of_service_threads) where the default number of service threads is 1, is less than the fd limit set by ulimit -n, lws switches to a slower lookup table scheme, which only allocates the requested number of slots. Lookups happen then by iterating the table and comparing rather than indexing the array directly, which is obviously somewhat of a performance hit. However in the case where you know lws will only have a very few wsi maximum, this method can very usefully trade off speed to be able to avoid the allocation sized by ulimit -n. minimal examples for client that can make use of this are also modified by this patch to use the smaller context allocations. |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| minimal-http-client-custom-headers.c | ||
| README.md | ||
| warmcat.com.cer | ||
lws minimal http client custom headers
This http client application shows how to send and receive custom headers.
This currently only works on http 1, so the app forces that even if h2 enables.
build
$ cmake . && make
usage
| Commandline option | Meaning |
|---|---|
| -d | Debug verbosity in decimal, eg, -d15 |
| -l | Connect to https://localhost:7681 and accept selfsigned cert |
| -n | no TLS |
The app looks for a custom header "test-custom-header" sent by warmcat.com.
$ ./lws-minimal-http-client-custom-headers
[2019/03/11 05:46:45:7582] USER: LWS minimal http client Custom Headers [-d<verbosity>] [-l] [--h1]
[2019/03/11 05:46:45:7671] NOTICE: created client ssl context for default
[2019/03/11 05:46:46:7812] USER: Connected with server response: 200
[2019/03/11 05:46:46:7812] NOTICE: callback_http: custom header: 'hello'
[2019/03/11 05:46:46:7814] USER: RECEIVE_CLIENT_HTTP_READ: read 1024
...
You can use the -n and -l to make this test app connect to localhost:7681 over http, and confirm the "dnt:1" header was sent either by tcpdump or by running the test server on :7681 with -d1151
[2019/03/11 05:48:53:6806] PARSER: WSI_TOKEN_NAME_PART 'd' 0x64 (role=0x20000000) wsi->lextable_pos=0
[2019/03/11 05:48:53:6807] PARSER: WSI_TOKEN_NAME_PART 'n' 0x6E (role=0x20000000) wsi->lextable_pos=567
[2019/03/11 05:48:53:6807] PARSER: WSI_TOKEN_NAME_PART 't' 0x74 (role=0x20000000) wsi->lextable_pos=-1
[2019/03/11 05:48:53:6807] PARSER: WSI_TOKEN_NAME_PART ' ' 0x20 (role=0x20000000) wsi->lextable_pos=-1
[2019/03/11 05:48:53:6807] PARSER: WSI_TOKEN_NAME_PART '1' 0x31 (role=0x20000000) wsi->lextable_pos=-1
' 0x0D (role=0x20000000) wsi->lextable_pos=-1NAME_PART '
[2019/03/11 05:48:53:6807] PARSER: WSI_TOKEN_NAME_PART '