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>
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>
- 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>
The code to prevent memory leaks caused by reallocating a wsi->utf8_token
was also causing wsi->parser_state to not be updated, preventing the
handshake from completing.
This patch changes the logic to append to previous allocation which is
correct behaviour actually.
Signed-off-by: Nick Dowell <nick@nickdowell.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Carlo wrote
''I'm interested to use the libwebsockets server (C based) with a Java
websocket client. I was able to implement a Java websocket client based
on JWebSocket library that works fine with the libwebsockets server, but
I was obliged to patch the libwebsockets server in order to reach my
goal. In particular I patched the handshake_00() function because
JWebSocket library uses hixie 76 version. The problem was that the
JWebSocket library sends only WSI_TOKEN_SWORIGIN token instead
WSI_TOKEN_ORIGIN token. For this reason the handshake_00 failed because
the token length of WSI_TOKEN_ORIGIN was 0. I have written a patch in
order to control if at least one of the two tokens (WSI_TOKEN_SWORIGIN
and WSI_TOKEN_ORIGIN) is defined. I have attached into the e-mail the
patch. Probably it can be written better, but in any case I think that
this problem should be fixed for client/server compatibility.''
I found a simpler approach which is convert WSORIGIN processing to
go into ORIGIN token at the earliest point, then everything else can
stay the same.
I also noticed we would leak on duplicated headers and fixed that.
Reported-by: Carlo PARATA <carlo.parata@st.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This quietens the spew so all typical debug info now is coming from
the user code (mirror protocol in the sample server / client case).
Signed-off-by: Andy Green <andy@warmcat.com>
Andy,
According http://www.ietf.org/rfc/rfc2616.txt HTTP character sets are identified by case-insensitive tokens.
Please replase
if (strcmp(lws_tokens[n].token, wsi->name_buffer))
continue;
to
if (stricmp(lws_tokens[n].token, wsi->name_buffer))
continue;
Oleg
Also introduce strcasecmp definition for win32
Signed-off-by: Oleg Golosovskiy <ogolosovskiy@unison.com>
This patch gets deflate-stream working with x-google-mux.
It adds a clean veto system where are extension can veto the proposal
of any extension when opening a new connection. x-google-mux uses that
in its callback to defeat any use of deflate-stream on mux children.
However deflate stream is allowed on the parent connection and works
transparently now alongside x-google-mux.
Signed-off-by: Andy Green <andy@warmcat.com>
This implements clean client and server close for mux child connections,
and deals with accounting for parent child lists.
The mux link can then survive constant connection bringup and teardown
found in the new test client.
Signed-off-by: Andy Green <andy@warmcat.com>
Zero length payloads aren't handled properly. This patch
should solve that.
Reported-by: Chee Wooi Saw <cheewooi@gtwholdings.com>
Signed-off-by: Andy Green <andy@warmcat.com>
Client does auto-service server's ping, but then it
fell through and issued it as payload. This fixes that
so there is no payload issued.
Reported-by: Chee Wooi Saw <cheewooi@gtwholdings.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This is initial x-google-mux support. It's disabled by default
since it's very pre-alpha.
1) To enable it, reconfigure with --enable-x-google-mux
2) It conflicts with deflate-stream, use the -u switch on
the test client to disable deflate-stream
3) It deviates from the google standard by sending full
headers in the addchannel subcommand rather than just
changed ones from original connect
4) Quota is not implemented yet
5) Close of subchannel is not really implemented yet
6) Google opcode 0xf is changed to 0x7 to account for
v7 protocol changes to opcode layout
However despite those caveats, in fact it can run the
test client reliably over one socket (both dumb-increment
and lws-mirror-protocol), you can open a browser on the
same test server too and see the circles, etc.
Signed-off-by: Andy Green <andy@warmcat.com>
Since 'shift' has unsigned integer type,
the following code may lead to infinite cycle
and segfault:
while (shift >= 0) {
if (shift)
buf[0 - pre + n] =
((len >> shift) & 127) | 0x80;
else
buf[0 - pre + n] =
((len >> shift) & 127);
n++;
shift -= 7;
}
Change type to signed integer.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@auriga.com>
... this afternoon I was just doing a little
interoperability testing around close... in my test-server I added
libwebsocket_close_and_free_session(this, wsi, LWS_CLOSE_STATUS_NORMAL);
in order to generate a server driven close.. I hope that was the right
way to go about it. In any event, in generated an invalid websocket
frame - I think you want this patch, or something like it:
Signed-off-by: \"Pat McManus @Mozilla\" <mcmanus@ducksong.com>
This adds win32 build compatability to libwebsockets.
The patch is from Peter Hinz, Andy Green has cleaned it up a bit and
possibly broken win32 compatability since I can't test it, so there
may be followup patches. It compiles fine under Linux after this
patch anyway.
Much of the patch is changing a reserved keyword for Visual C compiler
"this" to "context", but there is no real C99 support in the MSFT
compiler even though it is 2011 so C99 style array declarations
have been mangled back into "ancient C" style.
Some windows-isms are also added like closesocket() but these are
quite localized. Win32 random is just using C library random() call
at the moment vs Linux /dev/urandom. canonical hostname detection is
broken in win32 at the moment.
Signed-off-by: Peter Hinz <cerebusrc@gmail.com>
Signed-off-by: Andy Green <andy@warmcat.com>
This adds 76/00 client support to libwebsockets. It's still shipped
by browsers and more importantly still the only version supported by
server stuff like socket.io.
Signed-off-by: Andy Green <andy@warmcat.com>
This patch removes the relationship between position in the
pollfd[] array and any meaning about the type of socket.
It also refactors the service loop so there is a per-fd
function that detects the mode of the connection and services
it accordingly.
The context wsi * array is removed and a hashtable introduced
allowing fast wsi lookup from just the fd that it is
associated with
Signed-off-by: Andy Green <andy@warmcat.com>
