Andy Green | 9f99034 | 2011-02-12 11:57:45 +0000 | [diff] [blame] | 1 | <h2>libwebsocket_service_fd - Service polled socket with something waiting</h2> |
| 2 | <i>int</i> |
| 3 | <b>libwebsocket_service_fd</b> |
| 4 | (<i>struct libwebsocket_context *</i> <b>this</b>, |
| 5 | <i>struct pollfd *</i> <b>pollfd</b>) |
| 6 | <h3>Arguments</h3> |
| 7 | <dl> |
| 8 | <dt><b>this</b> |
| 9 | <dd>Websocket context |
| 10 | <dt><b>pollfd</b> |
| 11 | <dd>The pollfd entry describing the socket fd and which events |
| 12 | happened. |
| 13 | </dl> |
| 14 | <h3>Description</h3> |
| 15 | <blockquote> |
| 16 | This function closes any active connections and then frees the |
| 17 | context. After calling this, any further use of the context is |
| 18 | undefined. |
| 19 | </blockquote> |
| 20 | <hr> |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 21 | <h2>libwebsocket_context_destroy - Destroy the websocket context</h2> |
| 22 | <i>void</i> |
| 23 | <b>libwebsocket_context_destroy</b> |
| 24 | (<i>struct libwebsocket_context *</i> <b>this</b>) |
| 25 | <h3>Arguments</h3> |
| 26 | <dl> |
| 27 | <dt><b>this</b> |
| 28 | <dd>Websocket context |
| 29 | </dl> |
| 30 | <h3>Description</h3> |
| 31 | <blockquote> |
| 32 | This function closes any active connections and then frees the |
| 33 | context. After calling this, any further use of the context is |
| 34 | undefined. |
| 35 | </blockquote> |
| 36 | <hr> |
| 37 | <h2>libwebsocket_service - Service any pending websocket activity</h2> |
| 38 | <i>int</i> |
| 39 | <b>libwebsocket_service</b> |
| 40 | (<i>struct libwebsocket_context *</i> <b>this</b>, |
| 41 | <i>int</i> <b>timeout_ms</b>) |
| 42 | <h3>Arguments</h3> |
| 43 | <dl> |
| 44 | <dt><b>this</b> |
| 45 | <dd>Websocket context |
| 46 | <dt><b>timeout_ms</b> |
| 47 | <dd>Timeout for poll; 0 means return immediately if nothing needed |
| 48 | service otherwise block and service immediately, returning |
| 49 | after the timeout if nothing needed service. |
| 50 | </dl> |
| 51 | <h3>Description</h3> |
| 52 | <blockquote> |
| 53 | This function deals with any pending websocket traffic, for three |
| 54 | kinds of event. It handles these events on both server and client |
| 55 | types of connection the same. |
| 56 | <p> |
| 57 | 1) Accept new connections to our context's server |
| 58 | <p> |
| 59 | 2) Perform pending broadcast writes initiated from other forked |
| 60 | processes (effectively serializing asynchronous broadcasts) |
| 61 | <p> |
| 62 | 3) Call the receive callback for incoming frame data received by |
| 63 | server or client connections. |
| 64 | <p> |
| 65 | You need to call this service function periodically to all the above |
| 66 | functions to happen; if your application is single-threaded you can |
| 67 | just call it in your main event loop. |
| 68 | <p> |
| 69 | Alternatively you can fork a new process that asynchronously handles |
| 70 | calling this service in a loop. In that case you are happy if this |
| 71 | call blocks your thread until it needs to take care of something and |
| 72 | would call it with a large nonzero timeout. Your loop then takes no |
| 73 | CPU while there is nothing happening. |
| 74 | <p> |
| 75 | If you are calling it in a single-threaded app, you don't want it to |
| 76 | wait around blocking other things in your loop from happening, so you |
| 77 | would call it with a timeout_ms of 0, so it returns immediately if |
| 78 | nothing is pending, or as soon as it services whatever was pending. |
| 79 | </blockquote> |
| 80 | <hr> |
Andy Green | 3221f92 | 2011-02-12 13:14:11 +0000 | [diff] [blame] | 81 | <h2>libwebsocket_callback_on_writable - Request a callback when this socket becomes able to be written to without blocking *</h2> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 82 | <i>int</i> |
| 83 | <b>libwebsocket_callback_on_writable</b> |
| 84 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 85 | <h3>Arguments</h3> |
| 86 | <dl> |
| 87 | <dt><b>wsi</b> |
| 88 | <dd>Websocket connection instance to get callback for |
| 89 | </dl> |
| 90 | <hr> |
| 91 | <h2>libwebsocket_callback_on_writable_all_protocol - Request a callback for all connections using the given protocol when it becomes possible to write to each socket without blocking in turn.</h2> |
| 92 | <i>int</i> |
| 93 | <b>libwebsocket_callback_on_writable_all_protocol</b> |
| 94 | (<i>const struct libwebsocket_protocols *</i> <b>protocol</b>) |
| 95 | <h3>Arguments</h3> |
| 96 | <dl> |
| 97 | <dt><b>protocol</b> |
| 98 | <dd>Protocol whose connections will get callbacks |
| 99 | </dl> |
| 100 | <hr> |
Andy Green | a6cbece | 2011-01-27 20:06:03 +0000 | [diff] [blame] | 101 | <h2>libwebsocket_get_socket_fd - returns the socket file descriptor</h2> |
| 102 | <i>int</i> |
| 103 | <b>libwebsocket_get_socket_fd</b> |
| 104 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 105 | <h3>Arguments</h3> |
| 106 | <dl> |
| 107 | <dt><b>wsi</b> |
| 108 | <dd>Websocket connection instance |
| 109 | </dl> |
| 110 | <h3>Description</h3> |
| 111 | <blockquote> |
| 112 | <p> |
| 113 | You will not need this unless you are doing something special |
| 114 | </blockquote> |
| 115 | <hr> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 116 | <h2>libwebsocket_rx_flow_control - Enable and disable socket servicing for receieved packets.</h2> |
| 117 | <i>int</i> |
| 118 | <b>libwebsocket_rx_flow_control</b> |
| 119 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 120 | <i>int</i> <b>enable</b>) |
| 121 | <h3>Arguments</h3> |
| 122 | <dl> |
| 123 | <dt><b>wsi</b> |
| 124 | <dd>Websocket connection instance to get callback for |
| 125 | <dt><b>enable</b> |
| 126 | <dd>0 = disable read servicing for this connection, 1 = enable |
| 127 | </dl> |
| 128 | <h3>Description</h3> |
| 129 | <blockquote> |
| 130 | <p> |
| 131 | If the output side of a server process becomes choked, this allows flow |
| 132 | control for the input side. |
| 133 | </blockquote> |
| 134 | <hr> |
Andy Green | 2ac5a6f | 2011-01-28 10:00:18 +0000 | [diff] [blame] | 135 | <h2>libwebsocket_canonical_hostname - returns this host's hostname</h2> |
| 136 | <i>const char *</i> |
| 137 | <b>libwebsocket_canonical_hostname</b> |
| 138 | (<i>struct libwebsocket_context *</i> <b>this</b>) |
| 139 | <h3>Arguments</h3> |
| 140 | <dl> |
| 141 | <dt><b>this</b> |
| 142 | <dd>Websocket context |
| 143 | </dl> |
| 144 | <h3>Description</h3> |
| 145 | <blockquote> |
| 146 | <p> |
| 147 | This is typically used by client code to fill in the host parameter |
| 148 | when making a client connection. You can only call it after the context |
| 149 | has been created. |
| 150 | </blockquote> |
| 151 | <hr> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 152 | <h2>libwebsocket_create_context - Create the websocket handler</h2> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 153 | <i>struct libwebsocket_context *</i> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 154 | <b>libwebsocket_create_context</b> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 155 | (<i>int</i> <b>port</b>, |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 156 | <i>struct libwebsocket_protocols *</i> <b>protocols</b>, |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 157 | <i>const char *</i> <b>ssl_cert_filepath</b>, |
| 158 | <i>const char *</i> <b>ssl_private_key_filepath</b>, |
| 159 | <i>int</i> <b>gid</b>, |
Andy Green | 8014b29 | 2011-01-30 20:57:25 +0000 | [diff] [blame] | 160 | <i>int</i> <b>uid</b>, |
| 161 | <i>unsigned int</i> <b>options</b>) |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 162 | <h3>Arguments</h3> |
| 163 | <dl> |
| 164 | <dt><b>port</b> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 165 | <dd>Port to listen on... you can use 0 to suppress listening on |
| 166 | any port, that's what you want if you are not running a |
| 167 | websocket server at all but just using it as a client |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 168 | <dt><b>protocols</b> |
| 169 | <dd>Array of structures listing supported protocols and a protocol- |
| 170 | specific callback for each one. The list is ended with an |
| 171 | entry that has a NULL callback pointer. |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 172 | It's not const because we write the owning_server member |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 173 | <dt><b>ssl_cert_filepath</b> |
| 174 | <dd>If libwebsockets was compiled to use ssl, and you want |
| 175 | to listen using SSL, set to the filepath to fetch the |
| 176 | server cert from, otherwise NULL for unencrypted |
| 177 | <dt><b>ssl_private_key_filepath</b> |
| 178 | <dd>filepath to private key if wanting SSL mode, |
| 179 | else ignored |
| 180 | <dt><b>gid</b> |
| 181 | <dd>group id to change to after setting listen socket, or -1. |
| 182 | <dt><b>uid</b> |
| 183 | <dd>user id to change to after setting listen socket, or -1. |
Andy Green | bfb051f | 2011-02-09 08:49:14 +0000 | [diff] [blame] | 184 | <dt><b>options</b> |
| 185 | <dd>0, or LWS_SERVER_OPTION_DEFEAT_CLIENT_MASK |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 186 | </dl> |
| 187 | <h3>Description</h3> |
| 188 | <blockquote> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 189 | This function creates the listening socket and takes care |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 190 | of all initialization in one step. |
| 191 | <p> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 192 | After initialization, it returns a struct libwebsocket_context * that |
| 193 | represents this server. After calling, user code needs to take care |
| 194 | of calling <b>libwebsocket_service</b> with the context pointer to get the |
| 195 | server's sockets serviced. This can be done in the same process context |
| 196 | or a forked process, or another thread, |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 197 | <p> |
| 198 | The protocol callback functions are called for a handful of events |
| 199 | including http requests coming in, websocket connections becoming |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 200 | established, and data arriving; it's also called periodically to allow |
| 201 | async transmission. |
| 202 | <p> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 203 | HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since |
| 204 | at that time websocket protocol has not been negotiated. Other |
| 205 | protocols after the first one never see any HTTP callack activity. |
| 206 | <p> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 207 | The server created is a simple http server by default; part of the |
| 208 | websocket standard is upgrading this http connection to a websocket one. |
| 209 | <p> |
| 210 | This allows the same server to provide files like scripts and favicon / |
| 211 | images or whatever over http and dynamic data over websockets all in |
| 212 | one place; they're all handled in the user callback. |
| 213 | </blockquote> |
| 214 | <hr> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 215 | <h2>libwebsockets_fork_service_loop - Optional helper function forks off a process for the websocket server loop. You don't have to use this but if not, you have to make sure you are calling libwebsocket_service periodically to service the websocket traffic</h2> |
| 216 | <i>int</i> |
| 217 | <b>libwebsockets_fork_service_loop</b> |
| 218 | (<i>struct libwebsocket_context *</i> <b>this</b>) |
| 219 | <h3>Arguments</h3> |
| 220 | <dl> |
| 221 | <dt><b>this</b> |
| 222 | <dd>server context returned by creation function |
| 223 | </dl> |
| 224 | <hr> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 225 | <h2>libwebsockets_get_protocol - Returns a protocol pointer from a websocket connection.</h2> |
| 226 | <i>const struct libwebsocket_protocols *</i> |
| 227 | <b>libwebsockets_get_protocol</b> |
| 228 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 229 | <h3>Arguments</h3> |
| 230 | <dl> |
| 231 | <dt><b>wsi</b> |
| 232 | <dd>pointer to struct websocket you want to know the protocol of |
| 233 | </dl> |
| 234 | <h3>Description</h3> |
| 235 | <blockquote> |
| 236 | <p> |
| 237 | This is useful to get the protocol to broadcast back to from inside |
| 238 | the callback. |
| 239 | </blockquote> |
| 240 | <hr> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 241 | <h2>libwebsockets_broadcast - Sends a buffer to the callback for all active connections of the given protocol.</h2> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 242 | <i>int</i> |
| 243 | <b>libwebsockets_broadcast</b> |
| 244 | (<i>const struct libwebsocket_protocols *</i> <b>protocol</b>, |
| 245 | <i>unsigned char *</i> <b>buf</b>, |
| 246 | <i>size_t</i> <b>len</b>) |
| 247 | <h3>Arguments</h3> |
| 248 | <dl> |
| 249 | <dt><b>protocol</b> |
| 250 | <dd>pointer to the protocol you will broadcast to all members of |
| 251 | <dt><b>buf</b> |
| 252 | <dd>buffer containing the data to be broadcase. NOTE: this has to be |
| 253 | allocated with LWS_SEND_BUFFER_PRE_PADDING valid bytes before |
| 254 | the pointer and LWS_SEND_BUFFER_POST_PADDING afterwards in the |
| 255 | case you are calling this function from callback context. |
| 256 | <dt><b>len</b> |
| 257 | <dd>length of payload data in buf, starting from buf. |
| 258 | </dl> |
| 259 | <h3>Description</h3> |
| 260 | <blockquote> |
| 261 | This function allows bulk sending of a packet to every connection using |
| 262 | the given protocol. It does not send the data directly; instead it calls |
| 263 | the callback with a reason type of LWS_CALLBACK_BROADCAST. If the callback |
| 264 | wants to actually send the data for that connection, the callback itself |
| 265 | should call <b>libwebsocket_write</b>. |
| 266 | <p> |
| 267 | <b>libwebsockets_broadcast</b> can be called from another fork context without |
| 268 | having to take any care about data visibility between the processes, it'll |
| 269 | "just work". |
| 270 | </blockquote> |
| 271 | <hr> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 272 | <h2>libwebsocket_write - Apply protocol then write data to client</h2> |
| 273 | <i>int</i> |
| 274 | <b>libwebsocket_write</b> |
| 275 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 276 | <i>unsigned char *</i> <b>buf</b>, |
| 277 | <i>size_t</i> <b>len</b>, |
| 278 | <i>enum libwebsocket_write_protocol</i> <b>protocol</b>) |
| 279 | <h3>Arguments</h3> |
| 280 | <dl> |
| 281 | <dt><b>wsi</b> |
| 282 | <dd>Websocket instance (available from user callback) |
| 283 | <dt><b>buf</b> |
| 284 | <dd>The data to send. For data being sent on a websocket |
| 285 | connection (ie, not default http), this buffer MUST have |
| 286 | LWS_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer |
| 287 | and an additional LWS_SEND_BUFFER_POST_PADDING bytes valid |
| 288 | in the buffer after (buf + len). This is so the protocol |
| 289 | header and trailer data can be added in-situ. |
| 290 | <dt><b>len</b> |
| 291 | <dd>Count of the data bytes in the payload starting from buf |
| 292 | <dt><b>protocol</b> |
| 293 | <dd>Use LWS_WRITE_HTTP to reply to an http connection, and one |
| 294 | of LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate |
| 295 | data on a websockets connection. Remember to allow the extra |
| 296 | bytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT |
| 297 | are used. |
| 298 | </dl> |
| 299 | <h3>Description</h3> |
| 300 | <blockquote> |
| 301 | This function provides the way to issue data back to the client |
| 302 | for both http and websocket protocols. |
| 303 | <p> |
| 304 | In the case of sending using websocket protocol, be sure to allocate |
| 305 | valid storage before and after buf as explained above. This scheme |
| 306 | allows maximum efficiency of sending data and protocol in a single |
| 307 | packet while not burdening the user code with any protocol knowledge. |
| 308 | </blockquote> |
| 309 | <hr> |
| 310 | <h2>libwebsockets_serve_http_file - Send a file back to the client using http</h2> |
| 311 | <i>int</i> |
| 312 | <b>libwebsockets_serve_http_file</b> |
| 313 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 314 | <i>const char *</i> <b>file</b>, |
| 315 | <i>const char *</i> <b>content_type</b>) |
| 316 | <h3>Arguments</h3> |
| 317 | <dl> |
| 318 | <dt><b>wsi</b> |
| 319 | <dd>Websocket instance (available from user callback) |
| 320 | <dt><b>file</b> |
| 321 | <dd>The file to issue over http |
| 322 | <dt><b>content_type</b> |
| 323 | <dd>The http content type, eg, text/html |
| 324 | </dl> |
| 325 | <h3>Description</h3> |
| 326 | <blockquote> |
| 327 | This function is intended to be called from the callback in response |
| 328 | to http requests from the client. It allows the callback to issue |
| 329 | local files down the http link in a single step. |
| 330 | </blockquote> |
| 331 | <hr> |
Andy Green | 38e57bb | 2011-01-19 12:20:27 +0000 | [diff] [blame] | 332 | <h2>libwebsockets_remaining_packet_payload - Bytes to come before "overall" rx packet is complete</h2> |
| 333 | <i>size_t</i> |
| 334 | <b>libwebsockets_remaining_packet_payload</b> |
| 335 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 336 | <h3>Arguments</h3> |
| 337 | <dl> |
| 338 | <dt><b>wsi</b> |
| 339 | <dd>Websocket instance (available from user callback) |
| 340 | </dl> |
| 341 | <h3>Description</h3> |
| 342 | <blockquote> |
| 343 | This function is intended to be called from the callback if the |
| 344 | user code is interested in "complete packets" from the client. |
| 345 | libwebsockets just passes through payload as it comes and issues a buffer |
| 346 | additionally when it hits a built-in limit. The LWS_CALLBACK_RECEIVE |
| 347 | callback handler can use this API to find out if the buffer it has just |
| 348 | been given is the last piece of a "complete packet" from the client -- |
| 349 | when that is the case <b>libwebsockets_remaining_packet_payload</b> will return |
| 350 | 0. |
| 351 | <p> |
| 352 | Many protocols won't care becuse their packets are always small. |
| 353 | </blockquote> |
| 354 | <hr> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 355 | <h2>libwebsocket_client_connect - Connect to another websocket server</h2> |
| 356 | <i>struct libwebsocket *</i> |
| 357 | <b>libwebsocket_client_connect</b> |
| 358 | (<i>struct libwebsocket_context *</i> <b>this</b>, |
| 359 | <i>const char *</i> <b>address</b>, |
| 360 | <i>int</i> <b>port</b>, |
| 361 | <i>int</i> <b>ssl_connection</b>, |
| 362 | <i>const char *</i> <b>path</b>, |
| 363 | <i>const char *</i> <b>host</b>, |
| 364 | <i>const char *</i> <b>origin</b>, |
Andy Green | bfb051f | 2011-02-09 08:49:14 +0000 | [diff] [blame] | 365 | <i>const char *</i> <b>protocol</b>, |
| 366 | <i>int</i> <b>ietf_version_or_minus_one</b>) |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 367 | <h3>Arguments</h3> |
| 368 | <dl> |
| 369 | <dt><b>this</b> |
| 370 | <dd>Websocket context |
| 371 | <dt><b>address</b> |
| 372 | <dd>Remote server address, eg, "myserver.com" |
| 373 | <dt><b>port</b> |
| 374 | <dd>Port to connect to on the remote server, eg, 80 |
| 375 | <dt><b>ssl_connection</b> |
| 376 | <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self |
| 377 | signed certs |
| 378 | <dt><b>path</b> |
| 379 | <dd>Websocket path on server |
| 380 | <dt><b>host</b> |
| 381 | <dd>Hostname on server |
| 382 | <dt><b>origin</b> |
| 383 | <dd>Socket origin name |
| 384 | <dt><b>protocol</b> |
| 385 | <dd>Comma-separated list of protocols being asked for from |
| 386 | the server, or just one. The server will pick the one it |
| 387 | likes best. |
Andy Green | bfb051f | 2011-02-09 08:49:14 +0000 | [diff] [blame] | 388 | <dt><b>ietf_version_or_minus_one</b> |
| 389 | <dd>-1 to ask to connect using the default, latest |
| 390 | protocol supported, or the specific protocol ordinal |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 391 | </dl> |
| 392 | <h3>Description</h3> |
| 393 | <blockquote> |
| 394 | This function creates a connection to a remote server |
| 395 | </blockquote> |
| 396 | <hr> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 397 | <h2>callback - User server actions</h2> |
| 398 | <i>int</i> |
| 399 | <b>callback</b> |
| 400 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 401 | <i>enum libwebsocket_callback_reasons</i> <b>reason</b>, |
| 402 | <i>void *</i> <b>user</b>, |
| 403 | <i>void *</i> <b>in</b>, |
| 404 | <i>size_t</i> <b>len</b>) |
| 405 | <h3>Arguments</h3> |
| 406 | <dl> |
| 407 | <dt><b>wsi</b> |
| 408 | <dd>Opaque websocket instance pointer |
| 409 | <dt><b>reason</b> |
| 410 | <dd>The reason for the call |
| 411 | <dt><b>user</b> |
| 412 | <dd>Pointer to per-session user data allocated by library |
| 413 | <dt><b>in</b> |
| 414 | <dd>Pointer used for some callback reasons |
| 415 | <dt><b>len</b> |
| 416 | <dd>Length set for some callback reasons |
| 417 | </dl> |
| 418 | <h3>Description</h3> |
| 419 | <blockquote> |
| 420 | This callback is the way the user controls what is served. All the |
| 421 | protocol detail is hidden and handled by the library. |
| 422 | <p> |
| 423 | For each connection / session there is user data allocated that is |
| 424 | pointed to by "user". You set the size of this user data area when |
| 425 | the library is initialized with libwebsocket_create_server. |
| 426 | <p> |
| 427 | You get an opportunity to initialize user data when called back with |
| 428 | LWS_CALLBACK_ESTABLISHED reason. |
| 429 | </blockquote> |
| 430 | <h3>LWS_CALLBACK_ESTABLISHED</h3> |
| 431 | <blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 432 | after the server completes a handshake with |
| 433 | an incoming client |
| 434 | </blockquote> |
| 435 | <h3>LWS_CALLBACK_CLIENT_ESTABLISHED</h3> |
| 436 | <blockquote> |
| 437 | after your client connection completed |
| 438 | a handshake with the remote server |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 439 | </blockquote> |
| 440 | <h3>LWS_CALLBACK_CLOSED</h3> |
| 441 | <blockquote> |
| 442 | when the websocket session ends |
| 443 | </blockquote> |
| 444 | <h3>LWS_CALLBACK_BROADCAST</h3> |
| 445 | <blockquote> |
| 446 | signal to send to client (you would use |
| 447 | <b>libwebsocket_write</b> taking care about the |
| 448 | special buffer requirements |
| 449 | </blockquote> |
| 450 | <h3>LWS_CALLBACK_RECEIVE</h3> |
| 451 | <blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 452 | data has appeared for this server endpoint from a |
| 453 | remote client, it can be found at *in and is |
| 454 | len bytes long |
| 455 | </blockquote> |
Andy Green | a6cbece | 2011-01-27 20:06:03 +0000 | [diff] [blame] | 456 | <h3>LWS_CALLBACK_CLIENT_RECEIVE_PONG</h3> |
| 457 | <blockquote> |
| 458 | if you elected to see PONG packets, |
| 459 | they appear with this callback reason. PONG |
| 460 | packets only exist in 04+ protocol |
| 461 | </blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 462 | <h3>LWS_CALLBACK_CLIENT_RECEIVE</h3> |
| 463 | <blockquote> |
| 464 | data has appeared from the server for the |
| 465 | client connection, it can be found at *in and |
| 466 | is len bytes long |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 467 | </blockquote> |
| 468 | <h3>LWS_CALLBACK_HTTP</h3> |
| 469 | <blockquote> |
| 470 | an http request has come from a client that is not |
| 471 | asking to upgrade the connection to a websocket |
| 472 | one. This is a chance to serve http content, |
| 473 | for example, to send a script to the client |
| 474 | which will then open the websockets connection. |
Andy Green | 7619c47 | 2011-01-23 17:47:08 +0000 | [diff] [blame] | 475 | <tt><b>in</b></tt> points to the URI path requested and |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 476 | <b>libwebsockets_serve_http_file</b> makes it very |
| 477 | simple to send back a file to the client. |
| 478 | </blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 479 | <h3>LWS_CALLBACK_CLIENT_WRITEABLE</h3> |
| 480 | <blockquote> |
| 481 | if you call |
| 482 | <b>libwebsocket_callback_on_writable</b> on a connection, you will |
| 483 | get this callback coming when the connection socket is able to |
| 484 | accept another write packet without blocking. If it already |
| 485 | was able to take another packet without blocking, you'll get |
| 486 | this callback at the next call to the service loop function. |
| 487 | </blockquote> |
Andy Green | c85619d | 2011-02-13 08:25:26 +0000 | [diff] [blame^] | 488 | <h3>LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION</h3> |
| 489 | <blockquote> |
| 490 | called when the handshake has |
| 491 | been received and parsed from the client, but the response is |
| 492 | not sent yet. Return non-zero to disallow the connection. |
| 493 | <tt><b>user</b></tt> is a pointer to an array of |
| 494 | <p> |
| 495 | <p> |
| 496 | The next four reasons are optional and only need taking care of if you |
| 497 | will be integrating libwebsockets sockets into an external polling |
| 498 | array. |
| 499 | </blockquote> |
| 500 | <h3>LWS_CALLBACK_ADD_POLL_FD</h3> |
| 501 | <blockquote> |
| 502 | libwebsocket deals with its <b>poll</b> loop |
| 503 | internally, but in the case you are integrating with another |
| 504 | server you will need to have libwebsocket sockets share a |
| 505 | polling array with the other server. This and the other |
| 506 | POLL_FD related callbacks let you put your specialized |
| 507 | poll array interface code in the callback for protocol 0, the |
| 508 | first protocol you support, usually the HTTP protocol in the |
| 509 | serving case. This callback happens when a socket needs to be |
| 510 | </blockquote> |
| 511 | <h3>added to the polling loop</h3> |
| 512 | <blockquote> |
| 513 | <tt><b>user</b></tt> contains the fd, and |
| 514 | <tt><b>len</b></tt> is the events bitmap (like, POLLIN). If you are using the |
| 515 | internal polling loop (the "service" callback), you can just |
| 516 | ignore these callbacks. |
| 517 | </blockquote> |
| 518 | <h3>LWS_CALLBACK_DEL_POLL_FD</h3> |
| 519 | <blockquote> |
| 520 | This callback happens when a socket descriptor |
| 521 | needs to be removed from an external polling array. <tt><b>user</b></tt> is |
| 522 | the socket desricptor. If you are using the internal polling |
| 523 | loop, you can just ignore it. |
| 524 | </blockquote> |
| 525 | <h3>LWS_CALLBACK_SET_MODE_POLL_FD</h3> |
| 526 | <blockquote> |
| 527 | This callback happens when libwebsockets |
| 528 | wants to modify the events for the socket descriptor in <tt><b>user</b></tt>. |
| 529 | The handler should OR <tt><b>len</b></tt> on to the events member of the pollfd |
| 530 | struct for this socket descriptor. If you are using the |
| 531 | internal polling loop, you can just ignore it. |
| 532 | </blockquote> |
| 533 | <h3>LWS_CALLBACK_CLEAR_MODE_POLL_FD</h3> |
| 534 | <blockquote> |
| 535 | This callback occurs when libwebsockets |
| 536 | wants to modify the events for the socket descriptor in <tt><b>user</b></tt>. |
| 537 | The handler should AND ~<tt><b>len</b></tt> on to the events member of the |
| 538 | pollfd struct for this socket descriptor. If you are using the |
| 539 | internal polling loop, you can just ignore it. |
| 540 | </blockquote> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 541 | <hr> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 542 | <h2>struct libwebsocket_protocols - List of protocols and handlers server supports.</h2> |
| 543 | <b>struct libwebsocket_protocols</b> {<br> |
| 544 | <i>const char *</i> <b>name</b>;<br> |
Andy Green | e77ddd8 | 2010-11-13 10:03:47 +0000 | [diff] [blame] | 545 | <i>int (*</i><b>callback</b>) <i>(struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason, void *user,void *in, size_t len)</i>;<br> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 546 | <i>size_t</i> <b>per_session_data_size</b>;<br> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 547 | <i>struct libwebsocket_context *</i> <b>owning_server</b>;<br> |
| 548 | <i>int</i> <b>broadcast_socket_port</b>;<br> |
| 549 | <i>int</i> <b>broadcast_socket_user_fd</b>;<br> |
| 550 | <i>int</i> <b>protocol_index</b>;<br> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 551 | };<br> |
| 552 | <h3>Members</h3> |
| 553 | <dl> |
| 554 | <dt><b>name</b> |
| 555 | <dd>Protocol name that must match the one given in the client |
| 556 | Javascript new WebSocket(url, 'protocol') name |
| 557 | <dt><b>callback</b> |
| 558 | <dd>The service callback used for this protocol. It allows the |
| 559 | service action for an entire protocol to be encapsulated in |
| 560 | the protocol-specific callback |
| 561 | <dt><b>per_session_data_size</b> |
| 562 | <dd>Each new connection using this protocol gets |
| 563 | this much memory allocated on connection establishment and |
| 564 | freed on connection takedown. A pointer to this per-connection |
| 565 | allocation is passed into the callback in the 'user' parameter |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 566 | <dt><b>owning_server</b> |
| 567 | <dd>the server init call fills in this opaque pointer when |
| 568 | registering this protocol with the server. |
| 569 | <dt><b>broadcast_socket_port</b> |
| 570 | <dd>the server init call fills this in with the |
| 571 | localhost port number used to forward broadcasts for this |
| 572 | protocol |
| 573 | <dt><b>broadcast_socket_user_fd</b> |
| 574 | <dd>the server init call fills this in ... the <b>main</b> |
| 575 | process context can write to this socket to perform broadcasts |
| 576 | (use the <b>libwebsockets_broadcast</b> api to do this instead, |
| 577 | it works from any process context) |
| 578 | <dt><b>protocol_index</b> |
| 579 | <dd>which protocol we are starting from zero |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 580 | </dl> |
| 581 | <h3>Description</h3> |
| 582 | <blockquote> |
| 583 | This structure represents one protocol supported by the server. An |
| 584 | array of these structures is passed to <b>libwebsocket_create_server</b> |
| 585 | allows as many protocols as you like to be handled by one server. |
| 586 | </blockquote> |
| 587 | <hr> |