Problems with rx flow control implementation were the underlying cause
of the connection stalling issue that was covered up with the udelay()
patch that was removed recently.
This get rx flow control working properly and corrects problems with
fifo management in the test server mirror protocol code too.
The rxfow control api has been changed to just set a flag, so it's very cheap
to call from user code. After the callbacks that might use the rxflow control
api the flag is checked and any pending actions done.
rx flow control now stops any rx packet coming immediately, with compessed
connections "just what was left in the pipe" might be hundreds of KBytes. To
implement that the current packet being decoded is copied into a malloc'd buffer
by the rx processing code now.
When rxflow is allows to come again, the buffer is drained and freed before any
new packet content is accepted.
Signed-off-by: Andy Green <andy.green@linaro.org>
This rips out the connection hashtable implementation along with
MAX_CLIENTS and replaces it with a dynamically allocated fds array
and lookup table along the same lines as the new extpoll implementation
from Edwin van den Oetelaar.
It detects the max number of file descriptors possible at context init
time and allocates accordingly; this can be externally controlled by
ulimit and the server run as a specific user to facilitate targeting
specific ulimit rules at it.
Many operations that translated between socket descriptors and struct
websocket or pollfd objects have had iteration removed by this patch
and under load will be a lot faster.
Signed-off-by: Andy Green <andy.green@linaro.org>
This leverages the refactor patches to introduce the ability to
disable building any client side code in the library or the client
side test apps.
This will be a considerable size saving for embedded server-only
case.
Signed-off-by: Andy Green <andy.green@linaro.org>
This adapts the approach from the single-packet-per-poll-loop improvement
to sending more packets while the socket can take them.
It still falls back to the multi-state scheme if the socket ever chokes,
which it certainly will on larger files, so it's safe while being highly
efficient at smaller file sizes.
Nor should it significantly add to latency for other sockets, it simply
stuffs the pipe asynchronously as much as the pipe can take.
We also increase the packet payoad size from 512 to 1400 a time.
This reduces the time taken in the 300 connection / 5000 transfers ab test
from >8s to ~3.4s, transferring the same amount of data.
$ ab -t 100 -n 5000 -c 300 'http://127.0.0.1:7681/'
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests
Server Software: libwebsockets
Server Hostname: 127.0.0.1
Server Port: 7681
Document Path: /
Document Length: 8447 bytes
Concurrency Level: 300
Time taken for tests: 3.400 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Total transferred: 42680000 bytes
HTML transferred: 42235000 bytes
Requests per second: 1470.76 [#/sec] (mean)
Time per request: 203.976 [ms] (mean)
Time per request: 0.680 [ms] (mean, across all concurrent requests)
Transfer rate: 12260.17 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 7 24 15.6 20 125
Processing: 32 172 50.2 161 407
Waiting: 27 154 49.4 142 386
Total: 81 196 48.3 182 428
Percentage of the requests served within a certain time (ms)
50% 182
66% 185
75% 188
80% 194
90% 304
95% 316
98% 322
99% 328
100% 428 (longest request)
Signed-off-by: Andy Green <andy.green@linaro.org>
From an idea by Edwin van den Oetelaar <oetelaar.automatisering@gmail.com>
When testing libwebsockets with ab, Edwin found an unexpected bump in
the distribution of latencies, some connections were held back almost
the whole test duration.
http://ml.libwebsockets.org/pipermail/libwebsockets/2013-January/000006.html
Studying the problem revealed that when there are mass pending connections
amongst many active connections, we do not service the listen socket often
enough to clear the backlog, some seem to get stale violating FIFO ordering.
This patch introduces listen socket service "piggybacking", where every n
normal socket service actions we also check the listen socket and deal with
pending connections there.
Normally, it checks the listen socket gratuitously every 10 normal socket
services. However, if it finds something waiting, it forces a check on the
next normal socket service too by keeping stats on how often something was
waiting. If the probability of something waiting each time becomes high,
it will allow up to two waiting connections to be serviced for each normal
socket service.
In that way it has low burden in the normal case, but rapidly adapts by
detecting mass connection loads as found in ab.
Signed-off-by: Andy Green <andy.green@linaro.org>
Default remains at SOMAXCONN, you can force it at configure time
along these lines
./configure CFLAGS="-DLWS_SOMAXCONN=16384"
Signed-off-by: Andy Green <andy.green@linaro.org>
Previously we sat and looped to dump a file over http protocol.
Actually that's a source of blocking to the other sockets being serviced.
This patch breaks up the file service into a roundtrip around the poll()
loop for each 512-byte packet. It doesn't make much difference if the
server is idle, but if it's busy it makes sure everyone else is getting
service while the file is sent.
It doesn't try to optimize multiple users of the file or to keep the
descriptor open, the point of this patch is to establish the breaking up
of the file send action into the poll loop.
On the user side, there are two differences:
- context is now needed in the first argument to libwebsockets_serve_http_file()
that's not too bad since we provide context in the callback.
- file send is now asynchronous to the user code, you get a new callback coming
in protocol 0 when it's done, LWS_CALLBACK_HTTP_FILE_COMPLETION
libwebsockets-test-server is updated accordingly.
Signed-off-by: Andy Green <andy.green@linaro.org>
"4b0e01f Retry SSL_connect when SSL_get_error requests it. " from David Galeano
noticed the problem that client connect may receive SSL_ERROR_WANT_* from
SSL_connect, which is basically WOULDBLOCK. That patch tried to deal with it
by blocking in a while(1) until the condition went away.
That's problematic because of it blocks service of anything else (including
the host application sockets in the external socket poll sharing case) for
up to 5s controlled by conditions at one client.
After fiddling with and researching this, the actual problem with the code is
we are not getting the SSL layer error correctly, it is not contained in the
code returned from the Connect api directly.
I was unable to get a renegotiation forced on my modern SSL libs, it complained
about protocol error are reopened the connection instead. So I think the stuff
found in the docs and the web about the SSL_ERROR_WANT_ is probably not something
we will see in reality (if we check the right error code...)
Signed-off-by: Andy Green <andy.green@linaro.org>
I run a web socket server that requires clients to present a certificate.
context_ssl_ = libwebsocket_create_context(wssPort_, wssIpAddr_.c_str(), protocols_ssl,
libwebsocket_internal_extensions,
cert_path.c_str(), key_path.c_str(), -1, -1,
LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT);
I am getting a crash in the OpenSSL_verify_callback().
The SSL_get_ex_data() call is returning NULL
I could not find a call to SSL_set_ex_data() for server mode operation.
Has anyone seen this crash in the newer versions?
Signed-off-by: Larry Hayes <larry.hayes@prodeasystems.com>
Some of the advice in README.rst became deprecated with recent patches,
the (good) advice about http connection close is better demonstrated
in the code and API docs, and the remainder can go in the main README,
which will have to be refactored itself at some point.
Signed-off-by: Andy Green <andy.green@linaro.org>
This patch allows control of the main compiletime constants in libwebsockets
from the configure commandline.
README is updated with documentation on what's available, how to set them
and the defaults.
The constants are logged with "info" severity (not visible by default) at
context create time.
The zlib constant previously exposed like this is moved to private-libwebsockets.h
so it can be printed along with the rest.
Signed-off-by: Andy Green <andy.green@linaro.org>
This reverts the removal of the deflate_frame code that was crashing after porting
David Galeano's code: he pointed out there's a typo in the merged version causing
the crash which is fixed here.
However the fixed code has a problem, there's no limit (other than int size) to the
amount of memory it will try to malloc, which can allow a DoS of the server by the
client sending malicious compression states that inflate to a large amount. I have
added checking for OOM already that will avert the segfault that would otherwise follow
but the server will be unusuable if malicious connections were made repeatedly each
forcing it to allocate large buffers and cause small allocations on other connections
to fail.
The patch changes the code to use realloc(), and introduces a configurable limit
on the amount of memory one connection may need for zlib before the server hangs
up the connection. It defaults to 64KBytes but can be set from ./configure as
described now in the README.
Signed-off-by: Andy Green <andy.green@linaro.org>
David found that uclibc did not provide this slightly esoteric api
and provided one from BSD that can be built by the library internally.
AG: Made contingent on configure option --enable-builtin-getifaddrs
Signed-off-by: David <cymerio@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
- multiple debug context calls lwsl_ err, warn, debug, parser, ext, client
- api added to set which contexts output to stderr using a bitfield log_level
- --disable-debug on configure removes all code that is not err or warn severity
- err and warn contexts always output to stderr unless disabled by log_level
- err and warn enabled by default in log_level
Signed-off-by: Andy Green <andy@warmcat.com>
Here testing with the test serer and chrome 25, the buffer expansion
code on Rx was triggered by a valid no data output condition and looped
until it exhausted all memory.
This patch adds OOM check to all malloc()s and removes the buffer expansion
code on the rx path... leaving the code on tx path for now.
Signed-off-by: Andy Green <andy.green@linaro.org>
