Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 1 | Daemonization |
| 2 | ------------- |
| 3 | |
| 4 | There's a helper api lws_daemonize built by default that does everything you |
| 5 | need to daemonize well, including creating a lock file. If you're making |
| 6 | what's basically a daemon, just call this early in your init to fork to a |
| 7 | headless background process and exit the starting process. |
| 8 | |
| 9 | Notice stdout, stderr, stdin are all redirected to /dev/null to enforce your |
| 10 | daemon is headless, so you'll need to sort out alternative logging, by, eg, |
| 11 | syslog. |
| 12 | |
| 13 | |
| 14 | Maximum number of connections |
| 15 | ----------------------------- |
| 16 | |
| 17 | The maximum number of connections the library can deal with is decided when |
| 18 | it starts by querying the OS to find out how many file descriptors it is |
| 19 | allowed to open (1024 on Fedora for example). It then allocates arrays that |
| 20 | allow up to that many connections, minus whatever other file descriptors are |
| 21 | in use by the user code. |
| 22 | |
| 23 | If you want to restrict that allocation, or increase it, you can use ulimit or |
| 24 | similar to change the avaiable number of file descriptors, and when restarted |
| 25 | libwebsockets will adapt accordingly. |
| 26 | |
| 27 | |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame] | 28 | Libwebsockets is singlethreaded |
| 29 | ------------------------------- |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 30 | |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame] | 31 | Directly performing websocket actions from other threads is not allowed. |
| 32 | Aside from the internal data being inconsistent in forked() processes, |
| 33 | the scope of a wsi (struct websocket) can end at any time during service |
| 34 | with the socket closing and the wsi freed. |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 35 | |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame] | 36 | Websocket write activities should only take place in the |
| 37 | "LWS_CALLBACK_SERVER_WRITEABLE" callback as described below. |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 38 | |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame] | 39 | Only live connections appear in the user callbacks, so this removes any |
| 40 | possibility of trying to used closed and freed wsis. |
| 41 | |
| 42 | If you need to service other socket or file descriptors as well as the |
| 43 | websocket ones, you can combine them together with the websocket ones |
| 44 | in one poll loop, see "External Polling Loop support" below, and |
| 45 | still do it all in one thread / process context. |
| 46 | |
| 47 | |
| 48 | Only send data when socket writeable |
| 49 | ------------------------------------ |
| 50 | |
| 51 | You should only send data on a websocket connection from the user callback |
| 52 | "LWS_CALLBACK_SERVER_WRITEABLE" (or "LWS_CALLBACK_CLIENT_WRITEABLE" for |
| 53 | clients). |
| 54 | |
| 55 | If you want to send something, do not just send it but request a callback |
| 56 | when the socket is writeable using |
| 57 | |
| 58 | - libwebsocket_callback_on_writable(context, wsi) for a specific wsi, or |
| 59 | - libwebsocket_callback_on_writable_all_protocol(protocol) for all connections |
| 60 | using that protocol to get a callback when next writeable. |
| 61 | |
| 62 | Usually you will get called back immediately next time around the service |
| 63 | loop, but if your peer is slow or temporarily inactive the callback will be |
| 64 | delayed accordingly. Generating what to write and sending it should be done |
| 65 | in the ...WRITEABLE callback. |
| 66 | |
| 67 | See the test server code for an example of how to do this. |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 68 | |
| 69 | |
Andy Green | 15d56dd | 2014-04-10 11:23:18 +0800 | [diff] [blame] | 70 | Do not rely on only your own WRITEABLE requests appearing |
| 71 | --------------------------------------------------------- |
| 72 | |
| 73 | Libwebsockets may generate additional LWS_CALLBACK_CLIENT_WRITEABLE events |
| 74 | if it met network conditions where it had to buffer your send data internally. |
| 75 | |
| 76 | So your code for LWS_CALLBACK_CLIENT_WRITEABLE needs to own the decision |
| 77 | about what to send, it can't assume that just because the writeable callback |
| 78 | came it really is time to send something. |
| 79 | |
| 80 | It's quite possible you get an 'extra' writeable callback at any time and |
| 81 | just need to return 0 and wait for the expected callback later. |
| 82 | |
| 83 | |
Andy Green | 099f789 | 2013-02-15 10:25:58 +0800 | [diff] [blame] | 84 | Closing connections from the user side |
| 85 | -------------------------------------- |
| 86 | |
| 87 | When you want to close a connection, you do it by returning -1 from a |
| 88 | callback for that connection. |
| 89 | |
| 90 | You can provoke a callback by calling libwebsocket_callback_on_writable on |
| 91 | the wsi, then notice in the callback you want to close it and just return -1. |
| 92 | But usually, the decision to close is made in a callback already and returning |
| 93 | -1 is simple. |
| 94 | |
| 95 | If the socket knows the connection is dead, because the peer closed or there |
| 96 | was an affirmitive network error like a FIN coming, then libwebsockets will |
| 97 | take care of closing the connection automatically. |
| 98 | |
| 99 | If you have a silently dead connection, it's possible to enter a state where |
| 100 | the send pipe on the connection is choked but no ack will ever come, so the |
| 101 | dead connection will never become writeable. To cover that, you can use TCP |
| 102 | keepalives (see later in this document) |
| 103 | |
| 104 | |
Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 105 | Fragmented messages |
| 106 | ------------------- |
| 107 | |
| 108 | To support fragmented messages you need to check for the final |
| 109 | frame of a message with libwebsocket_is_final_fragment. This |
| 110 | check can be combined with libwebsockets_remaining_packet_payload |
| 111 | to gather the whole contents of a message, eg: |
| 112 | |
| 113 | case LWS_CALLBACK_RECEIVE: |
| 114 | { |
| 115 | Client * const client = (Client *)user; |
| 116 | const size_t remaining = libwebsockets_remaining_packet_payload(wsi); |
| 117 | |
| 118 | if (!remaining && libwebsocket_is_final_fragment(wsi)) { |
| 119 | if (client->HasFragments()) { |
| 120 | client->AppendMessageFragment(in, len, 0); |
| 121 | in = (void *)client->GetMessage(); |
| 122 | len = client->GetMessageLength(); |
| 123 | } |
| 124 | |
| 125 | client->ProcessMessage((char *)in, len, wsi); |
| 126 | client->ResetMessage(); |
| 127 | } else |
| 128 | client->AppendMessageFragment(in, len, remaining); |
| 129 | } |
| 130 | break; |
| 131 | |
| 132 | The test app llibwebsockets-test-fraggle sources also show how to |
| 133 | deal with fragmented messages. |
| 134 | |
Andy Green | 52f28ce | 2013-01-25 17:34:15 +0800 | [diff] [blame] | 135 | |
Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 136 | Debug Logging |
| 137 | ------------- |
| 138 | |
| 139 | Also using lws_set_log_level api you may provide a custom callback to actually |
| 140 | emit the log string. By default, this points to an internal emit function |
| 141 | that sends to stderr. Setting it to NULL leaves it as it is instead. |
| 142 | |
| 143 | A helper function lwsl_emit_syslog() is exported from the library to simplify |
| 144 | logging to syslog. You still need to use setlogmask, openlog and closelog |
| 145 | in your user code. |
| 146 | |
| 147 | The logging apis are made available for user code. |
| 148 | |
| 149 | lwsl_err(...) |
| 150 | lwsl_warn(...) |
| 151 | lwsl_notice(...) |
| 152 | lwsl_info(...) |
| 153 | lwsl_debug(...) |
| 154 | |
| 155 | The difference between notice and info is that notice will be logged by default |
| 156 | whereas info is ignored by default. |
| 157 | |
| 158 | |
| 159 | External Polling Loop support |
| 160 | ----------------------------- |
| 161 | |
| 162 | libwebsockets maintains an internal poll() array for all of its |
| 163 | sockets, but you can instead integrate the sockets into an |
| 164 | external polling array. That's needed if libwebsockets will |
| 165 | cooperate with an existing poll array maintained by another |
| 166 | server. |
| 167 | |
| 168 | Four callbacks LWS_CALLBACK_ADD_POLL_FD, LWS_CALLBACK_DEL_POLL_FD, |
| 169 | LWS_CALLBACK_SET_MODE_POLL_FD and LWS_CALLBACK_CLEAR_MODE_POLL_FD |
| 170 | appear in the callback for protocol 0 and allow interface code to |
| 171 | manage socket descriptors in other poll loops. |
| 172 | |
Andy Green | 58f214e | 2013-03-09 13:03:53 +0800 | [diff] [blame] | 173 | You can pass all pollfds that need service to libwebsocket_service_fd(), even |
| 174 | if the socket or file does not belong to libwebsockets it is safe. |
| 175 | |
| 176 | If libwebsocket handled it, it zeros the pollfd revents field before returning. |
| 177 | So you can let libwebsockets try and if pollfd->revents is nonzero on return, |
| 178 | you know it needs handling by your code. |
| 179 | |
Andy Green | 6c1f64e | 2013-01-20 11:28:06 +0800 | [diff] [blame] | 180 | |
Andy Green | 36eb70d | 2013-02-01 08:42:15 +0800 | [diff] [blame] | 181 | Using with in c++ apps |
| 182 | ---------------------- |
| 183 | |
| 184 | The library is ready for use by C++ apps. You can get started quickly by |
| 185 | copying the test server |
| 186 | |
| 187 | $ cp test-server/test-server.c test.cpp |
| 188 | |
| 189 | and building it in C++ like this |
| 190 | |
| 191 | $ g++ -DINSTALL_DATADIR=\"/usr/share\" -ocpptest test.cpp -lwebsockets |
| 192 | |
| 193 | INSTALL_DATADIR is only needed because the test server uses it as shipped, if |
| 194 | you remove the references to it in your app you don't need to define it on |
| 195 | the g++ line either. |
Andy Green | a2b3a36 | 2013-02-06 20:13:03 +0900 | [diff] [blame] | 196 | |
| 197 | |
| 198 | Availability of header information |
| 199 | ---------------------------------- |
| 200 | |
| 201 | From v1.2 of the library onwards, the HTTP header content is free()d as soon |
| 202 | as the websocket connection is established. For websocket servers, you can |
| 203 | copy interesting headers by handling LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION |
| 204 | callback, for clients there's a new callback just for this purpose |
| 205 | LWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH. |
| 206 | |
Andy Green | a690cd0 | 2013-02-09 12:25:31 +0800 | [diff] [blame] | 207 | |
| 208 | TCP Keepalive |
| 209 | ------------- |
| 210 | |
| 211 | It is possible for a connection which is not being used to send to die |
| 212 | silently somewhere between the peer and the side not sending. In this case |
| 213 | by default TCP will just not report anything and you will never get any more |
| 214 | incoming data or sign the link is dead until you try to send. |
| 215 | |
| 216 | To deal with getting a notification of that situation, you can choose to |
| 217 | enable TCP keepalives on all libwebsockets sockets, when you create the |
| 218 | context. |
| 219 | |
| 220 | To enable keepalive, set the ka_time member of the context creation parameter |
| 221 | struct to a nonzero value (in seconds) at context creation time. You should |
| 222 | also fill ka_probes and ka_interval in that case. |
| 223 | |
| 224 | With keepalive enabled, the TCP layer will send control packets that should |
| 225 | stimulate a response from the peer without affecting link traffic. If the |
| 226 | response is not coming, the socket will announce an error at poll() forcing |
| 227 | a close. |
| 228 | |
Andy Green | a47865f | 2013-02-10 09:39:47 +0800 | [diff] [blame] | 229 | Note that BSDs don't support keepalive time / probes / inteveral per-socket |
| 230 | like Linux does. On those systems you can enable keepalive by a nonzero |
| 231 | value in ka_time, but the systemwide kernel settings for the time / probes/ |
| 232 | interval are used, regardless of what nonzero value is in ka_time. |
Andy Green | 2672fb2 | 2013-02-22 09:54:35 +0800 | [diff] [blame] | 233 | |
| 234 | Optimizing SSL connections |
| 235 | -------------------------- |
| 236 | |
| 237 | There's a member ssl_cipher_list in the lws_context_creation_info struct |
| 238 | which allows the user code to restrict the possible cipher selection at |
| 239 | context-creation time. |
| 240 | |
| 241 | You might want to look into that to stop the ssl peers selecting a ciher which |
| 242 | is too computationally expensive. To use it, point it to a string like |
| 243 | |
| 244 | "RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL" |
| 245 | |
| 246 | if left NULL, then the "DEFAULT" set of ciphers are all possible to select. |
| 247 | |
Andy Green | 5dc62ea | 2013-09-20 20:26:12 +0800 | [diff] [blame] | 248 | |
| 249 | Async nature of client connections |
| 250 | ---------------------------------- |
| 251 | |
| 252 | When you call libwebsocket_client_connect(..) and get a wsi back, it does not |
| 253 | mean your connection is active. It just mean it started trying to connect. |
| 254 | |
| 255 | Your client connection is actually active only when you receive |
| 256 | LWS_CALLBACK_CLIENT_ESTABLISHED for it. |
| 257 | |
| 258 | There's a 5 second timeout for the connection, and it may give up or die for |
| 259 | other reasons, if any of that happens you'll get a |
| 260 | LWS_CALLBACK_CLIENT_CONNECTION_ERROR callback on protocol 0 instead for the |
| 261 | wsi. |
| 262 | |
| 263 | After attempting the connection and getting back a non-NULL wsi you should |
| 264 | loop calling libwebsocket_service() until one of the above callbacks occurs. |
| 265 | |
| 266 | As usual, see test-client.c for example code. |
| 267 | |