add new context arg to libwebsockets_serve_http_file
[profile/ivi/libwebsockets.git] / README-test-server
1 Using test-server as a quickstart
2 ---------------------------------
3
4 You need to regenerate the autotools and libtoolize stuff for your system
5
6 $ ./autogen.sh
7
8 Then for a Fedora x86_86 box, the following config line was
9 needed:
10
11  ./configure --prefix=/usr --libdir=/usr/lib64 --enable-openssl
12
13 For Apple systems, Christopher Baker reported that this is needed
14 (and I was told separately enabling openssl makes trouble somehow)
15
16 ./configure CC="gcc -arch i386 -arch x86_64" CXX="g++ -arch i386 -arch
17 x86_64" CPP="gcc -E" CXXCPP="g++ -E" --enable-nofork
18
19 For mingw build, I did the following to get working build, ping test is
20 disabled when building this way
21
22 1) install mingw64_w32 compiler packages from Fedora
23 2) additionally install mingw64-zlib package
24 3) ./configure --prefix=/usr --enable-mingw --host=x86_64-w64-mingw32
25 4) make
26
27 For uClibc, you will likely need --enable-builtin-getifaddrs
28
29 otherwise if /usr/local/... and /usr/local/lib are OK then...
30
31 $ ./configure
32 $ make clean
33 $ make
34 $ sudo make install
35 $ libwebsockets-test-server
36
37 should be enough to get a test server listening on port 7861.
38
39
40 Configure script options
41 ------------------------
42
43 There are several other possible configure options
44
45 --enable-nofork         disables the fork into the background API
46                         and removes all references to fork() and
47                         pr_ctl() from the sources.  Use it if your
48                         platform doesn't support forking.
49
50 --enable-libcrypto      by default libwebsockets uses its own
51                         built-in md5 and sha-1 implementation for
52                         simplicity.  However the libcrypto ones
53                         may be faster, and in a distro context it
54                         may be highly desirable to use a common
55                         library implementation for ease of security
56                         upgrades.  Give this configure option
57                         to disable the built-in ones and force use
58                         of the libcrypto (part of openssl) ones.
59
60 --with-client-cert-dir=dir   tells the client ssl support where to
61                              look for trust certificates to validate
62                              the remote certificate against.
63
64 --enable-noping         Don't try to build the ping test app
65                         It needs some unixy environment that
66                         may choke in other build contexts, this
67                         lets you cleanly stop it being built
68                         
69 --enable-x-google-mux   Enable experimental x-google-mux support
70                         in the build (see notes later in document)
71
72 --enable-builtin-getifaddrs  if your libc lacks getifaddrs, you can build an
73                         implementation into the library.  By default your libc
74                         one is used.
75
76 --without-testapps      Just build the library not the test apps
77
78
79 Externally configurable important constants
80 -------------------------------------------
81
82 You can control these from configure by just setting them as commandline
83 args throgh CFLAGS, eg
84
85 ./configure CFLAGS="-DLWS_MAX_ZLIB_CONN_BUFFER=8192"
86
87 They all have defaults so you only need to take care about them if you want
88 to tune them to the amount of memory available.
89
90
91  - FD_HASHTABLE_MODULUS default 32: size of the file descriptor hash map,
92 affects server performance with large numbers of connections, at the cost of
93 increased memory consumption
94
95  - MAX_CLIENTS default 100: total number of simultaneous connections
96 allowed... reserves some memory even when not in use, so reduce for embedded
97 applications that only expect one or two connections
98
99  - LWS_MAX_HEADER_NAME_LENGTH default 64: max characters in an HTTP header
100 name that libwebsockets can cope with
101
102  - LWS_MAX_HEADER_LEN default 4096: largest HTTP header value string length
103 libwebsockets can cope with
104
105  - LWS_INITIAL_HDR_ALLOC default 256: amount of memory to allocate initially,
106 tradeoff between taking too much and needless realloc
107
108  - LWS_ADDITIONAL_HDR_ALLOC default 64: how much to additionally realloc if
109 the header value string keeps coming
110
111  - MAX_USER_RX_BUFFER default 4096: max amount of user rx data to buffer at a
112 time and pass to user callback LWS_CALLBACK_RECEIVE or
113 LWS_CALLBACK_CLIENT_RECEIVE.  Large frames are passed to the user callback
114 in chunks of this size.  Tradeoff between per-connection static memory
115 allocation and if you expect to deal with large frames, how much you can
116 see at once which can affect efficiency.
117
118  - MAX_BROADCAST_PAYLOAD default 4096: largest amount of user tx data we can
119 broadcast at a time
120
121  - LWS_MAX_PROTOCOLS default 10: largest amount of different protocols the
122 server can serve
123
124  - LWS_MAX_EXTENSIONS_ACTIVE default 10: largest amount of extensions we can
125 choose to have active on one connection
126
127  - SPEC_LATEST_SUPPORTED default 13: only change if you want to remove support
128 for later protocol versions... unlikely
129
130  - AWAITING_TIMEOUT default 5: after this many seconds without a response, the
131 server will hang up on the client
132
133  - CIPHERS_LIST_STRING default "DEFAULT": SSL Cipher selection.  It's advisable
134 to tweak the ciphers allowed to be negotiated on secure connections for
135 performance reasons, otherwise a slow algorithm may be selected by the two
136 endpoints and the server could expend most of its time just encrypting and
137 decrypting data, severely limiting the amount of messages it will be able to
138 handle per second.  For example::
139
140     "RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL"
141
142  - SYSTEM_RANDOM_FILEPATH default "/dev/urandom": if your random device differs
143 you can set it here
144
145  - LWS_MAX_ZLIB_CONN_BUFFER  maximum size a compression buffer is allowed to
146 grow to before closing the connection.  Default is 64KBytes.
147
148  - LWS_SOMAXCONN  maximum number of pending connect requests the listening
149 socket can cope with.  Default is SOMAXCONN.  If you need to use synthetic
150 tests that just spam hundreds of connect requests at once without dropping
151 any, you can try setting this to MAX_CLIENTS and mess with your box's tcp
152 config like this (courtesy Edwin van der Oetelaar)
153
154 echo "2048 64512" > /proc/sys/net/ipv4/ip_local_port_range
155 echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
156 echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
157 echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout
158 echo "65536" > /proc/sys/net/core/somaxconn
159 echo "65536" > /proc/sys/net/ipv4/tcp_max_syn_backlog
160 echo "262144" > /proc/sys/net/netfilter/nf_conntrack_max
161
162
163 Testing server with a browser
164 -----------------------------
165
166 If you point your browser (eg, Chrome) to
167
168   http://127.0.0.1:7681
169
170 It will fetch a script in the form of test.html, and then run the
171 script in there on the browser to open a websocket connection.
172 Incrementing numbers should appear in the browser display.
173
174 Using SSL on the server side
175 ----------------------------
176
177 To test it using SSL/WSS, just run the test server with
178
179 $ libwebsockets-test-server --ssl
180
181 and use the URL
182
183   https://127.0.0.1:7681
184
185 The connection will be entirely encrypted using some generated
186 certificates that your browser will not accept, since they are
187 not signed by any real Certificate Authority.  Just accept the
188 certificates in the browser and the connection will proceed
189 in first https and then websocket wss, acting exactly the
190 same.
191
192 test-server.c is all that is needed to use libwebsockets for
193 serving both the script html over http and websockets.
194
195
196 Forkless operation
197 ------------------
198
199 If your target device does not offer fork(), you can use
200 libwebsockets from your own main loop instead.  Use the
201 configure option --nofork and simply call libwebsocket_service()
202 from your own main loop as shown in the test app sources.
203
204
205 Fragmented messages
206 -------------------
207
208 To support fragmented messages you need to check for the final
209 frame of a message with libwebsocket_is_final_fragment. This
210 check can be combined with libwebsockets_remaining_packet_payload
211 to gather the whole contents of a message, eg:
212
213     case LWS_CALLBACK_RECEIVE:
214     {
215         Client * const client = (Client *)user;
216         const size_t remaining = libwebsockets_remaining_packet_payload(wsi);
217
218         if (!remaining && libwebsocket_is_final_fragment(wsi)) {
219             if (client->HasFragments()) {
220                 client->AppendMessageFragment(in, len, 0);
221                 in = (void *)client->GetMessage();
222                 len = client->GetMessageLength();
223             }
224
225             client->ProcessMessage((char *)in, len, wsi);
226             client->ResetMessage();
227         } else
228             client->AppendMessageFragment(in, len, remaining);
229     }
230     break;
231
232 The test app llibwebsockets-test-fraggle sources also show how to
233 deal with fragmented messages.
234
235
236 Testing websocket client support
237 --------------------------------
238
239 If you run the test server as described above, you can also
240 connect to it using the test client as well as a browser.
241
242 $ libwebsockets-test-client localhost
243
244 will by default connect to the test server on localhost:7681
245 and print the dumb increment number from the server at the
246 same time as drawing random circles in the mirror protocol;
247 if you connect to the test server using a browser at the
248 same time you will be able to see the circles being drawn.
249
250
251 Testing SSL on the client side
252 ------------------------------
253
254 To test SSL/WSS client action, just run the client test with
255
256 $ libwebsockets-test-client localhost --ssl
257
258 By default the client test applet is set to accept selfsigned
259 certificates used by the test server, this is indicated by the
260 use_ssl var being set to 2.  Set it to 1 to reject any server
261 certificate that it doesn't have a trusted CA cert for.
262
263
264 Using the websocket ping utility
265 --------------------------------
266
267 libwebsockets-test-ping connects as a client to a remote
268 websocket server using 04 protocol and pings it like the
269 normal unix ping utility.
270
271 $ libwebsockets-test-ping localhost                
272 handshake OK for protocol lws-mirror-protocol
273 Websocket PING localhost.localdomain (127.0.0.1) 64 bytes of data.
274 64 bytes from localhost: req=1 time=0.1ms
275 64 bytes from localhost: req=2 time=0.1ms
276 64 bytes from localhost: req=3 time=0.1ms
277 64 bytes from localhost: req=4 time=0.2ms
278 64 bytes from localhost: req=5 time=0.1ms
279 64 bytes from localhost: req=6 time=0.2ms
280 64 bytes from localhost: req=7 time=0.2ms
281 64 bytes from localhost: req=8 time=0.1ms
282 ^C
283 --- localhost.localdomain websocket ping statistics ---
284 8 packets transmitted, 8 received, 0% packet loss, time 7458ms
285 rtt min/avg/max = 0.110/0.185/0.218 ms
286 $
287
288 By default it sends 64 byte payload packets using the 04
289 PING packet opcode type.  You can change the payload size
290 using the -s= flag, up to a maximum of 125 mandated by the
291 04 standard.
292
293 Using the lws-mirror protocol that is provided by the test
294 server, libwebsockets-test-ping can also use larger payload
295 sizes up to 4096 is BINARY packets; lws-mirror will copy
296 them back to the client and they appear as a PONG.  Use the
297 -m flag to select this operation.
298
299 The default interval between pings is 1s, you can use the -i=
300 flag to set this, including fractions like -i=0.01 for 10ms
301 interval.
302
303 Before you can even use the PING opcode that is part of the
304 standard, you must complete a handshake with a specified
305 protocol.  By default lws-mirror-protocol is used which is
306 supported by the test server.  But if you are using it on
307 another server, you can specify the protcol to handshake with
308 by --protocol=protocolname
309
310
311 Fraggle test app
312 ----------------
313
314 By default it runs in server mode
315
316 $ libwebsockets-test-fraggle
317 libwebsockets test fraggle
318 (C) Copyright 2010-2011 Andy Green <andy@warmcat.com> licensed under LGPL2.1
319  Compiled with SSL support, not using it
320  Listening on port 7681
321 server sees client connect
322 accepted v06 connection
323 Spamming 360 random fragments
324 Spamming session over, len = 371913. sum = 0x2D3C0AE
325 Spamming 895 random fragments
326 Spamming session over, len = 875970. sum = 0x6A74DA1
327 ...
328
329 You need to run a second session in client mode, you have to
330 give the -c switch and the server address at least:
331
332 $ libwebsockets-test-fraggle -c localhost 
333 libwebsockets test fraggle
334 (C) Copyright 2010-2011 Andy Green <andy@warmcat.com> licensed under LGPL2.1
335  Client mode
336 Connecting to localhost:7681
337 denied deflate-stream extension
338 handshake OK for protocol fraggle-protocol
339 client connects to server
340 EOM received 371913 correctly from 360 fragments
341 EOM received 875970 correctly from 895 fragments
342 EOM received 247140 correctly from 258 fragments
343 EOM received 695451 correctly from 692 fragments
344 ...
345
346 The fraggle test sends a random number up to 1024 fragmented websocket frames
347 each of a random size between 1 and 2001 bytes in a single message, then sends
348 a checksum and starts sending a new randomly sized and fragmented message.
349
350 The fraggle test client receives the same message fragments and computes the
351 same checksum using websocket framing to see when the message has ended.  It
352 then accepts the server checksum message and compares that to its checksum.
353
354
355 proxy support
356 -------------
357
358 The http_proxy environment variable is respected by the client
359 connection code for both ws:// and wss://.  It doesn't support
360 authentication yet.
361
362 You use it like this
363
364 export http_proxy=myproxy.com:3128
365 libwebsockets-test-client someserver.com
366
367
368 debug logging
369 -------------
370
371 By default logging of severity "warn" or "err" is enabled to stderr.
372
373 Again by default other logging is comiled in but disabled from printing.
374
375 If you want to eliminate the debug logging below warn in severity, use the
376 --disable-debug configure option to have it removed from the code by the
377 preprocesser.
378
379 If you want to see more detailed debug logs, you can control a bitfield to
380 select which logs types may print using the lws_set_log_level() api, in the
381 test apps you can use -d <number> to control this.  The types of logging
382 available are (OR together the numbers to select multiple)
383
384  1   ERR
385  2   WARN
386  4   INFO
387  8   DEBUG
388  16  PARSER
389  32  HEADER
390  64  EXTENSION
391  128 CLIENT
392
393 Also using lws_set_log_level api you may provide a custom callback to actually
394 emit the log string.  By default, this points to an internal emit function
395 that sends to stderr.  Setting it to NULL leaves it as it is instead.
396
397
398 Websocket version supported
399 ---------------------------
400
401 The final IETF standard is supported along with various older ones that will
402 be removed at some point, -76, -04 and -05.
403
404
405 External Polling Loop support
406 -----------------------------
407
408 libwebsockets maintains an internal poll() array for all of its
409 sockets, but you can instead integrate the sockets into an
410 external polling array.  That's needed if libwebsockets will
411 cooperate with an existing poll array maintained by another
412 server.
413
414 Four callbacks LWS_CALLBACK_ADD_POLL_FD, LWS_CALLBACK_DEL_POLL_FD,
415 LWS_CALLBACK_SET_MODE_POLL_FD and LWS_CALLBACK_CLEAR_MODE_POLL_FD
416 appear in the callback for protocol 0 and allow interface code to
417 manage socket descriptors in other poll loops.
418
419
420 x-google-mux support
421 --------------------
422
423 Experimental and super-preliminary x-google-mux support is available if
424 enabled in ./configure with --enable-x-google-mux.  Note that when changing
425 configurations, you will need to do a make distclean before, then the new
426 configure and then make ; make install.  Don't forget the necessary other
427 flags for your platform as described at the top of the readme.
428
429 It has the following notes:
430
431     1) To enable it, reconfigure with --enable-x-google-mux
432     
433     2) It deviates from the google standard by sending full
434        headers in the addchannel subcommand rather than just
435        changed ones from original connect
436     
437     3) Quota is not implemented yet
438     
439 However despite those caveats, in fact it can run the
440 test client reliably over one socket (both dumb-increment
441 and lws-mirror-protocol), you can open a browser on the
442 same test server too and see the circles, etc.
443
444 It also works compatibly with deflate-stream automatically.
445
446 2012-04-12  Andy Green <andy@warmcat.com>
447