Andy Green | d88146d | 2013-01-22 12:40:35 +0800 | [diff] [blame] | 1 | <h2>libwebsocket_client_connect - Connect to another websocket server</h2> |
| 2 | <i>struct libwebsocket *</i> |
| 3 | <b>libwebsocket_client_connect</b> |
| 4 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
| 5 | <i>const char *</i> <b>address</b>, |
| 6 | <i>int</i> <b>port</b>, |
| 7 | <i>int</i> <b>ssl_connection</b>, |
| 8 | <i>const char *</i> <b>path</b>, |
| 9 | <i>const char *</i> <b>host</b>, |
| 10 | <i>const char *</i> <b>origin</b>, |
| 11 | <i>const char *</i> <b>protocol</b>, |
| 12 | <i>int</i> <b>ietf_version_or_minus_one</b>) |
| 13 | <h3>Arguments</h3> |
| 14 | <dl> |
| 15 | <dt><b>context</b> |
| 16 | <dd>Websocket context |
| 17 | <dt><b>address</b> |
| 18 | <dd>Remote server address, eg, "myserver.com" |
| 19 | <dt><b>port</b> |
| 20 | <dd>Port to connect to on the remote server, eg, 80 |
| 21 | <dt><b>ssl_connection</b> |
| 22 | <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self |
| 23 | signed certs |
| 24 | <dt><b>path</b> |
| 25 | <dd>Websocket path on server |
| 26 | <dt><b>host</b> |
| 27 | <dd>Hostname on server |
| 28 | <dt><b>origin</b> |
| 29 | <dd>Socket origin name |
| 30 | <dt><b>protocol</b> |
| 31 | <dd>Comma-separated list of protocols being asked for from |
| 32 | the server, or just one. The server will pick the one it |
| 33 | likes best. |
| 34 | <dt><b>ietf_version_or_minus_one</b> |
| 35 | <dd>-1 to ask to connect using the default, latest |
| 36 | protocol supported, or the specific protocol ordinal |
| 37 | </dl> |
| 38 | <h3>Description</h3> |
| 39 | <blockquote> |
| 40 | This function creates a connection to a remote server |
| 41 | </blockquote> |
| 42 | <hr> |
| 43 | <h2>libwebsocket_client_connect_extended - Connect to another websocket server</h2> |
| 44 | <i>struct libwebsocket *</i> |
| 45 | <b>libwebsocket_client_connect_extended</b> |
| 46 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
| 47 | <i>const char *</i> <b>address</b>, |
| 48 | <i>int</i> <b>port</b>, |
| 49 | <i>int</i> <b>ssl_connection</b>, |
| 50 | <i>const char *</i> <b>path</b>, |
| 51 | <i>const char *</i> <b>host</b>, |
| 52 | <i>const char *</i> <b>origin</b>, |
| 53 | <i>const char *</i> <b>protocol</b>, |
| 54 | <i>int</i> <b>ietf_version_or_minus_one</b>, |
| 55 | <i>void *</i> <b>userdata</b>) |
| 56 | <h3>Arguments</h3> |
| 57 | <dl> |
| 58 | <dt><b>context</b> |
| 59 | <dd>Websocket context |
| 60 | <dt><b>address</b> |
| 61 | <dd>Remote server address, eg, "myserver.com" |
| 62 | <dt><b>port</b> |
| 63 | <dd>Port to connect to on the remote server, eg, 80 |
| 64 | <dt><b>ssl_connection</b> |
| 65 | <dd>0 = ws://, 1 = wss:// encrypted, 2 = wss:// allow self |
| 66 | signed certs |
| 67 | <dt><b>path</b> |
| 68 | <dd>Websocket path on server |
| 69 | <dt><b>host</b> |
| 70 | <dd>Hostname on server |
| 71 | <dt><b>origin</b> |
| 72 | <dd>Socket origin name |
| 73 | <dt><b>protocol</b> |
| 74 | <dd>Comma-separated list of protocols being asked for from |
| 75 | the server, or just one. The server will pick the one it |
| 76 | likes best. |
| 77 | <dt><b>ietf_version_or_minus_one</b> |
| 78 | <dd>-1 to ask to connect using the default, latest |
| 79 | protocol supported, or the specific protocol ordinal |
| 80 | <dt><b>userdata</b> |
| 81 | <dd>Pre-allocated user data |
| 82 | </dl> |
| 83 | <h3>Description</h3> |
| 84 | <blockquote> |
| 85 | This function creates a connection to a remote server |
| 86 | </blockquote> |
| 87 | <hr> |
Andy Green | f7ee549 | 2011-02-13 09:04:21 +0000 | [diff] [blame] | 88 | <h2>libwebsockets_hangup_on_client - Server calls to terminate client connection</h2> |
| 89 | <i>void</i> |
| 90 | <b>libwebsockets_hangup_on_client</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 91 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | f7ee549 | 2011-02-13 09:04:21 +0000 | [diff] [blame] | 92 | <i>int</i> <b>fd</b>) |
| 93 | <h3>Arguments</h3> |
| 94 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 95 | <dt><b>context</b> |
Andy Green | f7ee549 | 2011-02-13 09:04:21 +0000 | [diff] [blame] | 96 | <dd>libwebsockets context |
| 97 | <dt><b>fd</b> |
| 98 | <dd>Connection socket descriptor |
| 99 | </dl> |
| 100 | <hr> |
Andy Green | 0703409 | 2011-02-13 08:37:12 +0000 | [diff] [blame] | 101 | <h2>libwebsockets_get_peer_addresses - Get client address information</h2> |
| 102 | <i>void</i> |
| 103 | <b>libwebsockets_get_peer_addresses</b> |
| 104 | (<i>int</i> <b>fd</b>, |
| 105 | <i>char *</i> <b>name</b>, |
| 106 | <i>int</i> <b>name_len</b>, |
| 107 | <i>char *</i> <b>rip</b>, |
| 108 | <i>int</i> <b>rip_len</b>) |
| 109 | <h3>Arguments</h3> |
| 110 | <dl> |
| 111 | <dt><b>fd</b> |
| 112 | <dd>Connection socket descriptor |
| 113 | <dt><b>name</b> |
| 114 | <dd>Buffer to take client address name |
| 115 | <dt><b>name_len</b> |
| 116 | <dd>Length of client address name buffer |
| 117 | <dt><b>rip</b> |
| 118 | <dd>Buffer to take client address IP qotted quad |
| 119 | <dt><b>rip_len</b> |
| 120 | <dd>Length of client address IP buffer |
| 121 | </dl> |
| 122 | <h3>Description</h3> |
| 123 | <blockquote> |
| 124 | This function fills in <tt><b>name</b></tt> and <tt><b>rip</b></tt> with the name and IP of |
| 125 | the client connected with socket descriptor <tt><b>fd</b></tt>. Names may be |
| 126 | truncated if there is not enough room. If either cannot be |
| 127 | determined, they will be returned as valid zero-length strings. |
| 128 | </blockquote> |
| 129 | <hr> |
Andy Green | 9f99034 | 2011-02-12 11:57:45 +0000 | [diff] [blame] | 130 | <h2>libwebsocket_service_fd - Service polled socket with something waiting</h2> |
| 131 | <i>int</i> |
| 132 | <b>libwebsocket_service_fd</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 133 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | 9f99034 | 2011-02-12 11:57:45 +0000 | [diff] [blame] | 134 | <i>struct pollfd *</i> <b>pollfd</b>) |
| 135 | <h3>Arguments</h3> |
| 136 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 137 | <dt><b>context</b> |
Andy Green | 9f99034 | 2011-02-12 11:57:45 +0000 | [diff] [blame] | 138 | <dd>Websocket context |
| 139 | <dt><b>pollfd</b> |
| 140 | <dd>The pollfd entry describing the socket fd and which events |
| 141 | happened. |
| 142 | </dl> |
| 143 | <h3>Description</h3> |
| 144 | <blockquote> |
Andy Green | 7500617 | 2013-01-22 12:32:11 +0800 | [diff] [blame] | 145 | This function takes a pollfd that has POLLIN or POLLOUT activity and |
| 146 | services it according to the state of the associated struct libwebsocket. |
| 147 | <p> |
| 148 | The one call deals with all "service" that might happen on a socket |
| 149 | including listen accepts, http files as well as websocket protocol. |
Andy Green | 9f99034 | 2011-02-12 11:57:45 +0000 | [diff] [blame] | 150 | </blockquote> |
| 151 | <hr> |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 152 | <h2>libwebsocket_context_destroy - Destroy the websocket context</h2> |
| 153 | <i>void</i> |
| 154 | <b>libwebsocket_context_destroy</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 155 | (<i>struct libwebsocket_context *</i> <b>context</b>) |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 156 | <h3>Arguments</h3> |
| 157 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 158 | <dt><b>context</b> |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 159 | <dd>Websocket context |
| 160 | </dl> |
| 161 | <h3>Description</h3> |
| 162 | <blockquote> |
| 163 | This function closes any active connections and then frees the |
| 164 | context. After calling this, any further use of the context is |
| 165 | undefined. |
| 166 | </blockquote> |
| 167 | <hr> |
Andy Green | d88146d | 2013-01-22 12:40:35 +0800 | [diff] [blame] | 168 | <h2>libwebsocket_context_user - get the user data associated with the whole context</h2> |
| 169 | <i>LWS_EXTERN void *</i> |
| 170 | <b>libwebsocket_context_user</b> |
| 171 | (<i>struct libwebsocket_context *</i> <b>context</b>) |
| 172 | <h3>Arguments</h3> |
| 173 | <dl> |
| 174 | <dt><b>context</b> |
| 175 | <dd>Websocket context |
| 176 | </dl> |
| 177 | <h3>Description</h3> |
| 178 | <blockquote> |
| 179 | This returns the optional user allocation that can be attached to |
| 180 | the context the sockets live in at context_create time. It's a way |
| 181 | to let all sockets serviced in the same context share data without |
| 182 | using globals statics in the user code. |
| 183 | </blockquote> |
| 184 | <hr> |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 185 | <h2>libwebsocket_service - Service any pending websocket activity</h2> |
| 186 | <i>int</i> |
| 187 | <b>libwebsocket_service</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 188 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 189 | <i>int</i> <b>timeout_ms</b>) |
| 190 | <h3>Arguments</h3> |
| 191 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 192 | <dt><b>context</b> |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 193 | <dd>Websocket context |
| 194 | <dt><b>timeout_ms</b> |
| 195 | <dd>Timeout for poll; 0 means return immediately if nothing needed |
| 196 | service otherwise block and service immediately, returning |
| 197 | after the timeout if nothing needed service. |
| 198 | </dl> |
| 199 | <h3>Description</h3> |
| 200 | <blockquote> |
| 201 | This function deals with any pending websocket traffic, for three |
| 202 | kinds of event. It handles these events on both server and client |
| 203 | types of connection the same. |
| 204 | <p> |
| 205 | 1) Accept new connections to our context's server |
| 206 | <p> |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame^] | 207 | 2) Call the receive callback for incoming frame data received by |
Andy Green | 6964bb5 | 2011-01-23 16:50:33 +0000 | [diff] [blame] | 208 | server or client connections. |
| 209 | <p> |
| 210 | You need to call this service function periodically to all the above |
| 211 | functions to happen; if your application is single-threaded you can |
| 212 | just call it in your main event loop. |
| 213 | <p> |
| 214 | Alternatively you can fork a new process that asynchronously handles |
| 215 | calling this service in a loop. In that case you are happy if this |
| 216 | call blocks your thread until it needs to take care of something and |
| 217 | would call it with a large nonzero timeout. Your loop then takes no |
| 218 | CPU while there is nothing happening. |
| 219 | <p> |
| 220 | If you are calling it in a single-threaded app, you don't want it to |
| 221 | wait around blocking other things in your loop from happening, so you |
| 222 | would call it with a timeout_ms of 0, so it returns immediately if |
| 223 | nothing is pending, or as soon as it services whatever was pending. |
| 224 | </blockquote> |
| 225 | <hr> |
Andy Green | 32375b7 | 2011-02-19 08:32:53 +0000 | [diff] [blame] | 226 | <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] | 227 | <i>int</i> |
| 228 | <b>libwebsocket_callback_on_writable</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 229 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | 62c54d2 | 2011-02-14 09:14:25 +0000 | [diff] [blame] | 230 | <i>struct libwebsocket *</i> <b>wsi</b>) |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 231 | <h3>Arguments</h3> |
| 232 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 233 | <dt><b>context</b> |
Andy Green | 32375b7 | 2011-02-19 08:32:53 +0000 | [diff] [blame] | 234 | <dd>libwebsockets context |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 235 | <dt><b>wsi</b> |
| 236 | <dd>Websocket connection instance to get callback for |
| 237 | </dl> |
| 238 | <hr> |
| 239 | <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> |
| 240 | <i>int</i> |
| 241 | <b>libwebsocket_callback_on_writable_all_protocol</b> |
| 242 | (<i>const struct libwebsocket_protocols *</i> <b>protocol</b>) |
| 243 | <h3>Arguments</h3> |
| 244 | <dl> |
| 245 | <dt><b>protocol</b> |
| 246 | <dd>Protocol whose connections will get callbacks |
| 247 | </dl> |
| 248 | <hr> |
Andy Green | be93fef | 2011-02-14 20:25:43 +0000 | [diff] [blame] | 249 | <h2>libwebsocket_set_timeout - marks the wsi as subject to a timeout</h2> |
| 250 | <i>void</i> |
| 251 | <b>libwebsocket_set_timeout</b> |
| 252 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 253 | <i>enum pending_timeout</i> <b>reason</b>, |
| 254 | <i>int</i> <b>secs</b>) |
| 255 | <h3>Arguments</h3> |
| 256 | <dl> |
| 257 | <dt><b>wsi</b> |
| 258 | <dd>Websocket connection instance |
| 259 | <dt><b>reason</b> |
| 260 | <dd>timeout reason |
| 261 | <dt><b>secs</b> |
| 262 | <dd>how many seconds |
| 263 | </dl> |
| 264 | <h3>Description</h3> |
| 265 | <blockquote> |
| 266 | <p> |
| 267 | You will not need this unless you are doing something special |
| 268 | </blockquote> |
| 269 | <hr> |
Andy Green | a6cbece | 2011-01-27 20:06:03 +0000 | [diff] [blame] | 270 | <h2>libwebsocket_get_socket_fd - returns the socket file descriptor</h2> |
| 271 | <i>int</i> |
| 272 | <b>libwebsocket_get_socket_fd</b> |
| 273 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 274 | <h3>Arguments</h3> |
| 275 | <dl> |
| 276 | <dt><b>wsi</b> |
| 277 | <dd>Websocket connection instance |
| 278 | </dl> |
| 279 | <h3>Description</h3> |
| 280 | <blockquote> |
| 281 | <p> |
| 282 | You will not need this unless you are doing something special |
| 283 | </blockquote> |
| 284 | <hr> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 285 | <h2>libwebsocket_rx_flow_control - Enable and disable socket servicing for receieved packets.</h2> |
| 286 | <i>int</i> |
| 287 | <b>libwebsocket_rx_flow_control</b> |
| 288 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 289 | <i>int</i> <b>enable</b>) |
| 290 | <h3>Arguments</h3> |
| 291 | <dl> |
| 292 | <dt><b>wsi</b> |
| 293 | <dd>Websocket connection instance to get callback for |
| 294 | <dt><b>enable</b> |
| 295 | <dd>0 = disable read servicing for this connection, 1 = enable |
| 296 | </dl> |
| 297 | <h3>Description</h3> |
| 298 | <blockquote> |
| 299 | <p> |
| 300 | If the output side of a server process becomes choked, this allows flow |
| 301 | control for the input side. |
| 302 | </blockquote> |
| 303 | <hr> |
Andy Green | 2ac5a6f | 2011-01-28 10:00:18 +0000 | [diff] [blame] | 304 | <h2>libwebsocket_canonical_hostname - returns this host's hostname</h2> |
| 305 | <i>const char *</i> |
| 306 | <b>libwebsocket_canonical_hostname</b> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 307 | (<i>struct libwebsocket_context *</i> <b>context</b>) |
Andy Green | 2ac5a6f | 2011-01-28 10:00:18 +0000 | [diff] [blame] | 308 | <h3>Arguments</h3> |
| 309 | <dl> |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 310 | <dt><b>context</b> |
Andy Green | 2ac5a6f | 2011-01-28 10:00:18 +0000 | [diff] [blame] | 311 | <dd>Websocket context |
| 312 | </dl> |
| 313 | <h3>Description</h3> |
| 314 | <blockquote> |
| 315 | <p> |
| 316 | This is typically used by client code to fill in the host parameter |
| 317 | when making a client connection. You can only call it after the context |
| 318 | has been created. |
| 319 | </blockquote> |
| 320 | <hr> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 321 | <h2>libwebsocket_create_context - Create the websocket handler</h2> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 322 | <i>struct libwebsocket_context *</i> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 323 | <b>libwebsocket_create_context</b> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 324 | (<i>int</i> <b>port</b>, |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 325 | <i>const char *</i> <b>interf</b>, |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 326 | <i>struct libwebsocket_protocols *</i> <b>protocols</b>, |
Andy Green | d6e0911 | 2011-03-05 16:12:15 +0000 | [diff] [blame] | 327 | <i>struct libwebsocket_extension *</i> <b>extensions</b>, |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 328 | <i>const char *</i> <b>ssl_cert_filepath</b>, |
| 329 | <i>const char *</i> <b>ssl_private_key_filepath</b>, |
David Galeano | 2f82be8 | 2013-01-09 16:25:54 +0800 | [diff] [blame] | 330 | <i>const char *</i> <b>ssl_ca_filepath</b>, |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 331 | <i>int</i> <b>gid</b>, |
Andy Green | 8014b29 | 2011-01-30 20:57:25 +0000 | [diff] [blame] | 332 | <i>int</i> <b>uid</b>, |
Alon Levy | 0291eb3 | 2012-10-19 11:21:56 +0200 | [diff] [blame] | 333 | <i>unsigned int</i> <b>options</b>, |
| 334 | <i>void *</i> <b>user</b>) |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 335 | <h3>Arguments</h3> |
| 336 | <dl> |
| 337 | <dt><b>port</b> |
Andy Green | 4739e5c | 2011-01-22 12:51:57 +0000 | [diff] [blame] | 338 | <dd>Port to listen on... you can use 0 to suppress listening on |
| 339 | any port, that's what you want if you are not running a |
| 340 | websocket server at all but just using it as a client |
Peter Hinz | 56885f3 | 2011-03-02 22:03:47 +0000 | [diff] [blame] | 341 | <dt><b>interf</b> |
Andy Green | 32375b7 | 2011-02-19 08:32:53 +0000 | [diff] [blame] | 342 | <dd>NULL to bind the listen socket to all interfaces, or the |
| 343 | interface name, eg, "eth2" |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 344 | <dt><b>protocols</b> |
| 345 | <dd>Array of structures listing supported protocols and a protocol- |
| 346 | specific callback for each one. The list is ended with an |
| 347 | entry that has a NULL callback pointer. |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 348 | It's not const because we write the owning_server member |
Andy Green | c511482 | 2011-03-06 10:29:35 +0000 | [diff] [blame] | 349 | <dt><b>extensions</b> |
| 350 | <dd>NULL or array of libwebsocket_extension structs listing the |
Andy Green | 3182ece | 2013-01-20 17:08:31 +0800 | [diff] [blame] | 351 | extensions this context supports. If you configured with |
| 352 | --without-extensions, you should give NULL here. |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 353 | <dt><b>ssl_cert_filepath</b> |
| 354 | <dd>If libwebsockets was compiled to use ssl, and you want |
| 355 | to listen using SSL, set to the filepath to fetch the |
| 356 | server cert from, otherwise NULL for unencrypted |
| 357 | <dt><b>ssl_private_key_filepath</b> |
| 358 | <dd>filepath to private key if wanting SSL mode, |
| 359 | else ignored |
David Galeano | 2f82be8 | 2013-01-09 16:25:54 +0800 | [diff] [blame] | 360 | <dt><b>ssl_ca_filepath</b> |
Andy Green | 988bd98 | 2013-01-10 12:26:13 +0800 | [diff] [blame] | 361 | <dd>CA certificate filepath or NULL |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 362 | <dt><b>gid</b> |
| 363 | <dd>group id to change to after setting listen socket, or -1. |
| 364 | <dt><b>uid</b> |
| 365 | <dd>user id to change to after setting listen socket, or -1. |
Andy Green | bfb051f | 2011-02-09 08:49:14 +0000 | [diff] [blame] | 366 | <dt><b>options</b> |
| 367 | <dd>0, or LWS_SERVER_OPTION_DEFEAT_CLIENT_MASK |
Andy Green | 788c4a8 | 2012-10-22 12:29:57 +0100 | [diff] [blame] | 368 | <dt><b>user</b> |
| 369 | <dd>optional user pointer that can be recovered via the context |
| 370 | pointer using libwebsocket_context_user |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 371 | </dl> |
| 372 | <h3>Description</h3> |
| 373 | <blockquote> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 374 | This function creates the listening socket and takes care |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 375 | of all initialization in one step. |
| 376 | <p> |
Andy Green | e92cd17 | 2011-01-19 13:11:55 +0000 | [diff] [blame] | 377 | After initialization, it returns a struct libwebsocket_context * that |
| 378 | represents this server. After calling, user code needs to take care |
| 379 | of calling <b>libwebsocket_service</b> with the context pointer to get the |
| 380 | server's sockets serviced. This can be done in the same process context |
| 381 | or a forked process, or another thread, |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 382 | <p> |
| 383 | The protocol callback functions are called for a handful of events |
| 384 | including http requests coming in, websocket connections becoming |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 385 | established, and data arriving; it's also called periodically to allow |
| 386 | async transmission. |
| 387 | <p> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 388 | HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since |
| 389 | at that time websocket protocol has not been negotiated. Other |
| 390 | protocols after the first one never see any HTTP callack activity. |
| 391 | <p> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 392 | The server created is a simple http server by default; part of the |
| 393 | websocket standard is upgrading this http connection to a websocket one. |
| 394 | <p> |
| 395 | This allows the same server to provide files like scripts and favicon / |
| 396 | images or whatever over http and dynamic data over websockets all in |
| 397 | one place; they're all handled in the user callback. |
| 398 | </blockquote> |
| 399 | <hr> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 400 | <h2>libwebsockets_get_protocol - Returns a protocol pointer from a websocket connection.</h2> |
| 401 | <i>const struct libwebsocket_protocols *</i> |
| 402 | <b>libwebsockets_get_protocol</b> |
| 403 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 404 | <h3>Arguments</h3> |
| 405 | <dl> |
| 406 | <dt><b>wsi</b> |
| 407 | <dd>pointer to struct websocket you want to know the protocol of |
| 408 | </dl> |
| 409 | <h3>Description</h3> |
| 410 | <blockquote> |
| 411 | <p> |
Andy Green | 6f520a5 | 2013-01-29 17:57:39 +0800 | [diff] [blame^] | 412 | Some apis can act on all live connections of a given protocol, |
| 413 | this is how you can get a pointer to the active protocol if needed. |
Andy Green | acbaee6 | 2013-01-18 22:00:22 +0800 | [diff] [blame] | 414 | </blockquote> |
| 415 | <hr> |
Andy Green | 43db045 | 2013-01-10 19:50:35 +0800 | [diff] [blame] | 416 | <h2>lws_set_log_level - Set the logging bitfield</h2> |
| 417 | <i>void</i> |
| 418 | <b>lws_set_log_level</b> |
Andy Green | de8f27a | 2013-01-12 09:17:42 +0800 | [diff] [blame] | 419 | (<i>int</i> <b>level</b>, |
Andy Green | 058ba81 | 2013-01-19 11:32:18 +0800 | [diff] [blame] | 420 | <i>void (*</i><b>log_emit_function</b>) <i>(int level, const char *line)</i>) |
Andy Green | 43db045 | 2013-01-10 19:50:35 +0800 | [diff] [blame] | 421 | <h3>Arguments</h3> |
| 422 | <dl> |
| 423 | <dt><b>level</b> |
| 424 | <dd>OR together the LLL_ debug contexts you want output from |
Andy Green | de8f27a | 2013-01-12 09:17:42 +0800 | [diff] [blame] | 425 | <dt><b>log_emit_function</b> |
| 426 | <dd>NULL to leave it as it is, or a user-supplied |
| 427 | function to perform log string emission instead of |
| 428 | the default stderr one. |
Andy Green | 43db045 | 2013-01-10 19:50:35 +0800 | [diff] [blame] | 429 | </dl> |
| 430 | <h3>Description</h3> |
| 431 | <blockquote> |
Andy Green | de8f27a | 2013-01-12 09:17:42 +0800 | [diff] [blame] | 432 | log level defaults to "err" and "warn" contexts enabled only and |
| 433 | emission on stderr. |
Andy Green | 43db045 | 2013-01-10 19:50:35 +0800 | [diff] [blame] | 434 | </blockquote> |
| 435 | <hr> |
Andy Green | d88146d | 2013-01-22 12:40:35 +0800 | [diff] [blame] | 436 | <h2>libwebsocket_write - Apply protocol then write data to client</h2> |
| 437 | <i>int</i> |
| 438 | <b>libwebsocket_write</b> |
| 439 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 440 | <i>unsigned char *</i> <b>buf</b>, |
| 441 | <i>size_t</i> <b>len</b>, |
| 442 | <i>enum libwebsocket_write_protocol</i> <b>protocol</b>) |
| 443 | <h3>Arguments</h3> |
| 444 | <dl> |
| 445 | <dt><b>wsi</b> |
| 446 | <dd>Websocket instance (available from user callback) |
| 447 | <dt><b>buf</b> |
| 448 | <dd>The data to send. For data being sent on a websocket |
| 449 | connection (ie, not default http), this buffer MUST have |
| 450 | LWS_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer |
| 451 | and an additional LWS_SEND_BUFFER_POST_PADDING bytes valid |
| 452 | in the buffer after (buf + len). This is so the protocol |
| 453 | header and trailer data can be added in-situ. |
| 454 | <dt><b>len</b> |
| 455 | <dd>Count of the data bytes in the payload starting from buf |
| 456 | <dt><b>protocol</b> |
| 457 | <dd>Use LWS_WRITE_HTTP to reply to an http connection, and one |
| 458 | of LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate |
| 459 | data on a websockets connection. Remember to allow the extra |
| 460 | bytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT |
| 461 | are used. |
| 462 | </dl> |
| 463 | <h3>Description</h3> |
| 464 | <blockquote> |
| 465 | This function provides the way to issue data back to the client |
| 466 | for both http and websocket protocols. |
| 467 | <p> |
| 468 | In the case of sending using websocket protocol, be sure to allocate |
| 469 | valid storage before and after buf as explained above. This scheme |
| 470 | allows maximum efficiency of sending data and protocol in a single |
| 471 | packet while not burdening the user code with any protocol knowledge. |
| 472 | </blockquote> |
| 473 | <hr> |
| 474 | <h2>libwebsockets_serve_http_file - Send a file back to the client using http</h2> |
| 475 | <i>int</i> |
| 476 | <b>libwebsockets_serve_http_file</b> |
| 477 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
| 478 | <i>struct libwebsocket *</i> <b>wsi</b>, |
| 479 | <i>const char *</i> <b>file</b>, |
| 480 | <i>const char *</i> <b>content_type</b>) |
| 481 | <h3>Arguments</h3> |
| 482 | <dl> |
| 483 | <dt><b>context</b> |
| 484 | <dd>libwebsockets context |
| 485 | <dt><b>wsi</b> |
| 486 | <dd>Websocket instance (available from user callback) |
| 487 | <dt><b>file</b> |
| 488 | <dd>The file to issue over http |
| 489 | <dt><b>content_type</b> |
| 490 | <dd>The http content type, eg, text/html |
| 491 | </dl> |
| 492 | <h3>Description</h3> |
| 493 | <blockquote> |
| 494 | This function is intended to be called from the callback in response |
| 495 | to http requests from the client. It allows the callback to issue |
| 496 | local files down the http link in a single step. |
| 497 | </blockquote> |
| 498 | <hr> |
Andy Green | 2fd3f2f | 2013-01-18 09:49:20 +0800 | [diff] [blame] | 499 | <h2>lws_frame_is_binary - </h2> |
| 500 | <i>int</i> |
| 501 | <b>lws_frame_is_binary</b> |
| 502 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 503 | <h3>Arguments</h3> |
| 504 | <dl> |
| 505 | <dt><b>wsi</b> |
| 506 | <dd>the connection we are inquiring about |
| 507 | </dl> |
| 508 | <h3>Description</h3> |
| 509 | <blockquote> |
| 510 | This is intended to be called from the LWS_CALLBACK_RECEIVE callback if |
| 511 | it's interested to see if the frame it's dealing with was sent in binary |
| 512 | mode. |
| 513 | </blockquote> |
| 514 | <hr> |
Andy Green | 38e57bb | 2011-01-19 12:20:27 +0000 | [diff] [blame] | 515 | <h2>libwebsockets_remaining_packet_payload - Bytes to come before "overall" rx packet is complete</h2> |
| 516 | <i>size_t</i> |
| 517 | <b>libwebsockets_remaining_packet_payload</b> |
| 518 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 519 | <h3>Arguments</h3> |
| 520 | <dl> |
| 521 | <dt><b>wsi</b> |
| 522 | <dd>Websocket instance (available from user callback) |
| 523 | </dl> |
| 524 | <h3>Description</h3> |
| 525 | <blockquote> |
| 526 | This function is intended to be called from the callback if the |
| 527 | user code is interested in "complete packets" from the client. |
| 528 | libwebsockets just passes through payload as it comes and issues a buffer |
| 529 | additionally when it hits a built-in limit. The LWS_CALLBACK_RECEIVE |
| 530 | callback handler can use this API to find out if the buffer it has just |
| 531 | been given is the last piece of a "complete packet" from the client -- |
| 532 | when that is the case <b>libwebsockets_remaining_packet_payload</b> will return |
| 533 | 0. |
| 534 | <p> |
| 535 | Many protocols won't care becuse their packets are always small. |
| 536 | </blockquote> |
| 537 | <hr> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 538 | <h2>callback - User server actions</h2> |
Andy Green | 07b56e6 | 2011-10-03 19:30:22 +0800 | [diff] [blame] | 539 | <i>LWS_EXTERN int</i> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 540 | <b>callback</b> |
Darin Willits | c19456f | 2011-02-14 17:52:39 +0000 | [diff] [blame] | 541 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | 62c54d2 | 2011-02-14 09:14:25 +0000 | [diff] [blame] | 542 | <i>struct libwebsocket *</i> <b>wsi</b>, |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 543 | <i>enum libwebsocket_callback_reasons</i> <b>reason</b>, |
| 544 | <i>void *</i> <b>user</b>, |
| 545 | <i>void *</i> <b>in</b>, |
| 546 | <i>size_t</i> <b>len</b>) |
| 547 | <h3>Arguments</h3> |
| 548 | <dl> |
Andy Green | 32375b7 | 2011-02-19 08:32:53 +0000 | [diff] [blame] | 549 | <dt><b>context</b> |
| 550 | <dd>Websockets context |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 551 | <dt><b>wsi</b> |
| 552 | <dd>Opaque websocket instance pointer |
| 553 | <dt><b>reason</b> |
| 554 | <dd>The reason for the call |
| 555 | <dt><b>user</b> |
| 556 | <dd>Pointer to per-session user data allocated by library |
| 557 | <dt><b>in</b> |
| 558 | <dd>Pointer used for some callback reasons |
| 559 | <dt><b>len</b> |
| 560 | <dd>Length set for some callback reasons |
| 561 | </dl> |
| 562 | <h3>Description</h3> |
| 563 | <blockquote> |
| 564 | This callback is the way the user controls what is served. All the |
| 565 | protocol detail is hidden and handled by the library. |
| 566 | <p> |
| 567 | For each connection / session there is user data allocated that is |
| 568 | pointed to by "user". You set the size of this user data area when |
| 569 | the library is initialized with libwebsocket_create_server. |
| 570 | <p> |
| 571 | You get an opportunity to initialize user data when called back with |
| 572 | LWS_CALLBACK_ESTABLISHED reason. |
| 573 | </blockquote> |
| 574 | <h3>LWS_CALLBACK_ESTABLISHED</h3> |
| 575 | <blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 576 | after the server completes a handshake with |
| 577 | an incoming client |
| 578 | </blockquote> |
David Brooks | 2c60d95 | 2012-04-20 12:19:01 +0800 | [diff] [blame] | 579 | <h3>LWS_CALLBACK_CLIENT_CONNECTION_ERROR</h3> |
| 580 | <blockquote> |
| 581 | the request client connection has |
| 582 | been unable to complete a handshake with the remote server |
| 583 | </blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 584 | <h3>LWS_CALLBACK_CLIENT_ESTABLISHED</h3> |
| 585 | <blockquote> |
| 586 | after your client connection completed |
| 587 | a handshake with the remote server |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 588 | </blockquote> |
| 589 | <h3>LWS_CALLBACK_CLOSED</h3> |
| 590 | <blockquote> |
| 591 | when the websocket session ends |
| 592 | </blockquote> |
| 593 | <h3>LWS_CALLBACK_BROADCAST</h3> |
| 594 | <blockquote> |
| 595 | signal to send to client (you would use |
| 596 | <b>libwebsocket_write</b> taking care about the |
| 597 | special buffer requirements |
| 598 | </blockquote> |
| 599 | <h3>LWS_CALLBACK_RECEIVE</h3> |
| 600 | <blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 601 | data has appeared for this server endpoint from a |
| 602 | remote client, it can be found at *in and is |
| 603 | len bytes long |
| 604 | </blockquote> |
Andy Green | a6cbece | 2011-01-27 20:06:03 +0000 | [diff] [blame] | 605 | <h3>LWS_CALLBACK_CLIENT_RECEIVE_PONG</h3> |
| 606 | <blockquote> |
| 607 | if you elected to see PONG packets, |
| 608 | they appear with this callback reason. PONG |
| 609 | packets only exist in 04+ protocol |
| 610 | </blockquote> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 611 | <h3>LWS_CALLBACK_CLIENT_RECEIVE</h3> |
| 612 | <blockquote> |
| 613 | data has appeared from the server for the |
| 614 | client connection, it can be found at *in and |
| 615 | is len bytes long |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 616 | </blockquote> |
| 617 | <h3>LWS_CALLBACK_HTTP</h3> |
| 618 | <blockquote> |
| 619 | an http request has come from a client that is not |
| 620 | asking to upgrade the connection to a websocket |
| 621 | one. This is a chance to serve http content, |
| 622 | for example, to send a script to the client |
| 623 | which will then open the websockets connection. |
Andy Green | 7619c47 | 2011-01-23 17:47:08 +0000 | [diff] [blame] | 624 | <tt><b>in</b></tt> points to the URI path requested and |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 625 | <b>libwebsockets_serve_http_file</b> makes it very |
| 626 | simple to send back a file to the client. |
Andy Green | 24b588b | 2013-01-13 09:53:18 +0800 | [diff] [blame] | 627 | Normally after sending the file you are done |
| 628 | with the http connection, since the rest of the |
| 629 | activity will come by websockets from the script |
| 630 | that was delivered by http, so you will want to |
| 631 | return 1; to close and free up the connection. |
| 632 | That's important because it uses a slot in the |
| 633 | total number of client connections allowed set |
| 634 | by MAX_CLIENTS. |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 635 | </blockquote> |
Andy Green | d280b6e | 2013-01-15 13:40:23 +0800 | [diff] [blame] | 636 | <h3>LWS_CALLBACK_HTTP_FILE_COMPLETION</h3> |
| 637 | <blockquote> |
| 638 | a file requested to be send down |
| 639 | http link has completed. |
| 640 | </blockquote> |
Andy Green | e9739ed | 2011-03-07 21:40:59 +0000 | [diff] [blame] | 641 | <h3>LWS_CALLBACK_SERVER_WRITEABLE</h3> |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 642 | <blockquote> |
Andy Green | e9739ed | 2011-03-07 21:40:59 +0000 | [diff] [blame] | 643 | If you call |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 644 | <b>libwebsocket_callback_on_writable</b> on a connection, you will |
Andy Green | e9739ed | 2011-03-07 21:40:59 +0000 | [diff] [blame] | 645 | get one of these callbacks coming when the connection socket |
| 646 | is able to accept another write packet without blocking. |
| 647 | If it already was able to take another packet without blocking, |
| 648 | you'll get this callback at the next call to the service loop |
| 649 | function. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE |
| 650 | and servers get LWS_CALLBACK_SERVER_WRITEABLE. |
Andy Green | 90c7cbc | 2011-01-27 06:26:52 +0000 | [diff] [blame] | 651 | </blockquote> |
Andy Green | 0703409 | 2011-02-13 08:37:12 +0000 | [diff] [blame] | 652 | <h3>LWS_CALLBACK_FILTER_NETWORK_CONNECTION</h3> |
| 653 | <blockquote> |
| 654 | called when a client connects to |
| 655 | the server at network level; the connection is accepted but then |
| 656 | passed to this callback to decide whether to hang up immediately |
| 657 | or not, based on the client IP. <tt><b>user</b></tt> contains the connection |
| 658 | socket's descriptor. Return non-zero to terminate |
| 659 | the connection before sending or receiving anything. |
| 660 | Because this happens immediately after the network connection |
| 661 | from the client, there's no websocket protocol selected yet so |
| 662 | this callback is issued only to protocol 0. |
| 663 | </blockquote> |
Andy Green | c85619d | 2011-02-13 08:25:26 +0000 | [diff] [blame] | 664 | <h3>LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION</h3> |
| 665 | <blockquote> |
| 666 | called when the handshake has |
| 667 | been received and parsed from the client, but the response is |
| 668 | not sent yet. Return non-zero to disallow the connection. |
Andy Green | 0703409 | 2011-02-13 08:37:12 +0000 | [diff] [blame] | 669 | <tt><b>user</b></tt> is a pointer to an array of struct lws_tokens, you can |
| 670 | use the header enums lws_token_indexes from libwebsockets.h |
| 671 | to check for and read the supported header presence and |
| 672 | content before deciding to allow the handshake to proceed or |
| 673 | to kill the connection. |
Andy Green | 0894bda | 2011-02-19 09:09:11 +0000 | [diff] [blame] | 674 | </blockquote> |
| 675 | <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS</h3> |
| 676 | <blockquote> |
Andy Green | 6901cb3 | 2011-02-21 08:06:47 +0000 | [diff] [blame] | 677 | if configured for |
Andy Green | 0894bda | 2011-02-19 09:09:11 +0000 | [diff] [blame] | 678 | including OpenSSL support, this callback allows your user code |
| 679 | to perform extra <b>SSL_CTX_load_verify_locations</b> or similar |
| 680 | calls to direct OpenSSL where to find certificates the client |
| 681 | can use to confirm the remote server identity. <tt><b>user</b></tt> is the |
| 682 | OpenSSL SSL_CTX* |
Andy Green | 6901cb3 | 2011-02-21 08:06:47 +0000 | [diff] [blame] | 683 | </blockquote> |
| 684 | <h3>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS</h3> |
| 685 | <blockquote> |
| 686 | if configured for |
| 687 | including OpenSSL support, this callback allows your user code |
| 688 | to load extra certifcates into the server which allow it to |
| 689 | verify the validity of certificates returned by clients. <tt><b>user</b></tt> |
| 690 | is the server's OpenSSL SSL_CTX* |
| 691 | </blockquote> |
| 692 | <h3>LWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION</h3> |
| 693 | <blockquote> |
| 694 | if the |
| 695 | libwebsockets context was created with the option |
| 696 | LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this |
| 697 | callback is generated during OpenSSL verification of the cert |
| 698 | sent from the client. It is sent to protocol[0] callback as |
| 699 | no protocol has been negotiated on the connection yet. |
| 700 | Notice that the libwebsockets context and wsi are both NULL |
| 701 | during this callback. See |
| 702 | </blockquote> |
| 703 | <h3>http</h3> |
| 704 | <blockquote> |
| 705 | //www.openssl.org/docs/ssl/SSL_CTX_set_verify.html |
| 706 | to understand more detail about the OpenSSL callback that |
| 707 | generates this libwebsockets callback and the meanings of the |
| 708 | arguments passed. In this callback, <tt><b>user</b></tt> is the x509_ctx, |
| 709 | <tt><b>in</b></tt> is the ssl pointer and <tt><b>len</b></tt> is preverify_ok |
| 710 | Notice that this callback maintains libwebsocket return |
| 711 | conventions, return 0 to mean the cert is OK or 1 to fail it. |
| 712 | This also means that if you don't handle this callback then |
| 713 | the default callback action of returning 0 allows the client |
| 714 | certificates. |
Andy Green | 385e7ad | 2011-03-01 21:06:02 +0000 | [diff] [blame] | 715 | </blockquote> |
| 716 | <h3>LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER</h3> |
| 717 | <blockquote> |
| 718 | this callback happens |
| 719 | when a client handshake is being compiled. <tt><b>user</b></tt> is NULL, |
| 720 | <tt><b>in</b></tt> is a char **, it's pointing to a char * which holds the |
| 721 | next location in the header buffer where you can add |
| 722 | headers, and <tt><b>len</b></tt> is the remaining space in the header buffer, |
| 723 | which is typically some hundreds of bytes. So, to add a canned |
| 724 | cookie, your handler code might look similar to: |
| 725 | <p> |
| 726 | char **p = (char **)in; |
| 727 | <p> |
| 728 | if (len < 100) |
| 729 | return 1; |
| 730 | <p> |
| 731 | *p += sprintf(*p, "Cookie: a=b\x0d\x0a"); |
| 732 | <p> |
| 733 | return 0; |
| 734 | <p> |
| 735 | Notice if you add anything, you just have to take care about |
| 736 | the CRLF on the line you added. Obviously this callback is |
| 737 | optional, if you don't handle it everything is fine. |
| 738 | <p> |
| 739 | Notice the callback is coming to protocols[0] all the time, |
| 740 | because there is no specific protocol handshook yet. |
Andy Green | c511482 | 2011-03-06 10:29:35 +0000 | [diff] [blame] | 741 | </blockquote> |
| 742 | <h3>LWS_CALLBACK_CONFIRM_EXTENSION_OKAY</h3> |
| 743 | <blockquote> |
| 744 | When the server handshake code |
| 745 | sees that it does support a requested extension, before |
| 746 | accepting the extension by additing to the list sent back to |
| 747 | the client it gives this callback just to check that it's okay |
| 748 | to use that extension. It calls back to the requested protocol |
| 749 | and with <tt><b>in</b></tt> being the extension name, <tt><b>len</b></tt> is 0 and <tt><b>user</b></tt> is |
| 750 | valid. Note though at this time the ESTABLISHED callback hasn't |
| 751 | happened yet so if you initialize <tt><b>user</b></tt> content there, <tt><b>user</b></tt> |
| 752 | content during this callback might not be useful for anything. |
| 753 | Notice this callback comes to protocols[0]. |
Andy Green | c6517fa | 2011-03-06 13:15:29 +0000 | [diff] [blame] | 754 | </blockquote> |
| 755 | <h3>LWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED</h3> |
| 756 | <blockquote> |
| 757 | When a client |
| 758 | connection is being prepared to start a handshake to a server, |
| 759 | each supported extension is checked with protocols[0] callback |
| 760 | with this reason, giving the user code a chance to suppress the |
| 761 | claim to support that extension by returning non-zero. If |
| 762 | unhandled, by default 0 will be returned and the extension |
| 763 | support included in the header to the server. Notice this |
| 764 | callback comes to protocols[0]. |
Andy Green | c85619d | 2011-02-13 08:25:26 +0000 | [diff] [blame] | 765 | <p> |
| 766 | The next four reasons are optional and only need taking care of if you |
| 767 | will be integrating libwebsockets sockets into an external polling |
| 768 | array. |
| 769 | </blockquote> |
| 770 | <h3>LWS_CALLBACK_ADD_POLL_FD</h3> |
| 771 | <blockquote> |
| 772 | libwebsocket deals with its <b>poll</b> loop |
| 773 | internally, but in the case you are integrating with another |
| 774 | server you will need to have libwebsocket sockets share a |
| 775 | polling array with the other server. This and the other |
| 776 | POLL_FD related callbacks let you put your specialized |
| 777 | poll array interface code in the callback for protocol 0, the |
| 778 | first protocol you support, usually the HTTP protocol in the |
| 779 | serving case. This callback happens when a socket needs to be |
| 780 | </blockquote> |
| 781 | <h3>added to the polling loop</h3> |
| 782 | <blockquote> |
| 783 | <tt><b>user</b></tt> contains the fd, and |
| 784 | <tt><b>len</b></tt> is the events bitmap (like, POLLIN). If you are using the |
| 785 | internal polling loop (the "service" callback), you can just |
| 786 | ignore these callbacks. |
| 787 | </blockquote> |
| 788 | <h3>LWS_CALLBACK_DEL_POLL_FD</h3> |
| 789 | <blockquote> |
| 790 | This callback happens when a socket descriptor |
| 791 | needs to be removed from an external polling array. <tt><b>user</b></tt> is |
| 792 | the socket desricptor. If you are using the internal polling |
| 793 | loop, you can just ignore it. |
| 794 | </blockquote> |
| 795 | <h3>LWS_CALLBACK_SET_MODE_POLL_FD</h3> |
| 796 | <blockquote> |
| 797 | This callback happens when libwebsockets |
| 798 | wants to modify the events for the socket descriptor in <tt><b>user</b></tt>. |
| 799 | The handler should OR <tt><b>len</b></tt> on to the events member of the pollfd |
| 800 | struct for this socket descriptor. If you are using the |
| 801 | internal polling loop, you can just ignore it. |
| 802 | </blockquote> |
| 803 | <h3>LWS_CALLBACK_CLEAR_MODE_POLL_FD</h3> |
| 804 | <blockquote> |
| 805 | This callback occurs when libwebsockets |
| 806 | wants to modify the events for the socket descriptor in <tt><b>user</b></tt>. |
| 807 | The handler should AND ~<tt><b>len</b></tt> on to the events member of the |
| 808 | pollfd struct for this socket descriptor. If you are using the |
| 809 | internal polling loop, you can just ignore it. |
| 810 | </blockquote> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame] | 811 | <hr> |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 812 | <h2>extension_callback - Hooks to allow extensions to operate</h2> |
Andy Green | 07b56e6 | 2011-10-03 19:30:22 +0800 | [diff] [blame] | 813 | <i>LWS_EXTERN int</i> |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 814 | <b>extension_callback</b> |
| 815 | (<i>struct libwebsocket_context *</i> <b>context</b>, |
Andy Green | 46c2ea0 | 2011-03-22 09:04:01 +0000 | [diff] [blame] | 816 | <i>struct libwebsocket_extension *</i> <b>ext</b>, |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 817 | <i>struct libwebsocket *</i> <b>wsi</b>, |
David Brooks | 2c60d95 | 2012-04-20 12:19:01 +0800 | [diff] [blame] | 818 | <i>enum libwebsocket_extension_callback_reasons</i> <b>reason</b>, |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 819 | <i>void *</i> <b>user</b>, |
| 820 | <i>void *</i> <b>in</b>, |
| 821 | <i>size_t</i> <b>len</b>) |
| 822 | <h3>Arguments</h3> |
| 823 | <dl> |
| 824 | <dt><b>context</b> |
| 825 | <dd>Websockets context |
Andy Green | 46c2ea0 | 2011-03-22 09:04:01 +0000 | [diff] [blame] | 826 | <dt><b>ext</b> |
| 827 | <dd>This extension |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 828 | <dt><b>wsi</b> |
| 829 | <dd>Opaque websocket instance pointer |
| 830 | <dt><b>reason</b> |
| 831 | <dd>The reason for the call |
| 832 | <dt><b>user</b> |
| 833 | <dd>Pointer to per-session user data allocated by library |
| 834 | <dt><b>in</b> |
| 835 | <dd>Pointer used for some callback reasons |
| 836 | <dt><b>len</b> |
| 837 | <dd>Length set for some callback reasons |
| 838 | </dl> |
| 839 | <h3>Description</h3> |
| 840 | <blockquote> |
| 841 | Each extension that is active on a particular connection receives |
| 842 | callbacks during the connection lifetime to allow the extension to |
| 843 | operate on websocket data and manage itself. |
| 844 | <p> |
| 845 | Libwebsockets takes care of allocating and freeing "user" memory for |
| 846 | each active extension on each connection. That is what is pointed to |
| 847 | by the <tt><b>user</b></tt> parameter. |
| 848 | </blockquote> |
| 849 | <h3>LWS_EXT_CALLBACK_CONSTRUCT</h3> |
| 850 | <blockquote> |
| 851 | called when the server has decided to |
| 852 | select this extension from the list provided by the client, |
| 853 | just before the server will send back the handshake accepting |
| 854 | the connection with this extension active. This gives the |
| 855 | extension a chance to initialize its connection context found |
| 856 | in <tt><b>user</b></tt>. |
| 857 | </blockquote> |
Andy Green | 2366b1c | 2011-03-06 13:15:31 +0000 | [diff] [blame] | 858 | <h3>LWS_EXT_CALLBACK_CLIENT_CONSTRUCT</h3> |
| 859 | <blockquote> |
| 860 | same as LWS_EXT_CALLBACK_CONSTRUCT |
| 861 | but called when client is instantiating this extension. Some |
| 862 | extensions will work the same on client and server side and then |
| 863 | you can just merge handlers for both CONSTRUCTS. |
| 864 | </blockquote> |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 865 | <h3>LWS_EXT_CALLBACK_DESTROY</h3> |
| 866 | <blockquote> |
| 867 | called when the connection the extension was |
| 868 | being used on is about to be closed and deallocated. It's the |
| 869 | last chance for the extension to deallocate anything it has |
| 870 | allocated in the user data (pointed to by <tt><b>user</b></tt>) before the |
Andy Green | 2366b1c | 2011-03-06 13:15:31 +0000 | [diff] [blame] | 871 | user data is deleted. This same callback is used whether you |
| 872 | are in client or server instantiation context. |
Andy Green | 57b4e9a | 2011-03-06 13:14:46 +0000 | [diff] [blame] | 873 | </blockquote> |
| 874 | <h3>LWS_EXT_CALLBACK_PACKET_RX_PREPARSE</h3> |
| 875 | <blockquote> |
| 876 | when this extension was active on |
| 877 | a connection, and a packet of data arrived at the connection, |
| 878 | it is passed to this callback to give the extension a chance to |
| 879 | change the data, eg, decompress it. <tt><b>user</b></tt> is pointing to the |
| 880 | extension's private connection context data, <tt><b>in</b></tt> is pointing |
| 881 | to an lws_tokens struct, it consists of a char * pointer called |
| 882 | token, and an int called token_len. At entry, these are |
| 883 | set to point to the received buffer and set to the content |
| 884 | length. If the extension will grow the content, it should use |
| 885 | a new buffer allocated in its private user context data and |
| 886 | set the pointed-to lws_tokens members to point to its buffer. |
| 887 | </blockquote> |
| 888 | <h3>LWS_EXT_CALLBACK_PACKET_TX_PRESEND</h3> |
| 889 | <blockquote> |
| 890 | this works the same way as |
| 891 | LWS_EXT_CALLBACK_PACKET_RX_PREPARSE above, except it gives the |
| 892 | extension a chance to change websocket data just before it will |
| 893 | be sent out. Using the same lws_token pointer scheme in <tt><b>in</b></tt>, |
| 894 | the extension can change the buffer and the length to be |
| 895 | transmitted how it likes. Again if it wants to grow the |
| 896 | buffer safely, it should copy the data into its own buffer and |
| 897 | set the lws_tokens token pointer to it. |
| 898 | </blockquote> |
| 899 | <hr> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 900 | <h2>struct libwebsocket_protocols - List of protocols and handlers server supports.</h2> |
| 901 | <b>struct libwebsocket_protocols</b> {<br> |
| 902 | <i>const char *</i> <b>name</b>;<br> |
David Brooks | 2c60d95 | 2012-04-20 12:19:01 +0800 | [diff] [blame] | 903 | <i>callback_function *</i> <b>callback</b>;<br> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 904 | <i>size_t</i> <b>per_session_data_size</b>;<br> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 905 | <i>struct libwebsocket_context *</i> <b>owning_server</b>;<br> |
| 906 | <i>int</i> <b>broadcast_socket_port</b>;<br> |
| 907 | <i>int</i> <b>broadcast_socket_user_fd</b>;<br> |
| 908 | <i>int</i> <b>protocol_index</b>;<br> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 909 | };<br> |
| 910 | <h3>Members</h3> |
| 911 | <dl> |
| 912 | <dt><b>name</b> |
| 913 | <dd>Protocol name that must match the one given in the client |
| 914 | Javascript new WebSocket(url, 'protocol') name |
| 915 | <dt><b>callback</b> |
| 916 | <dd>The service callback used for this protocol. It allows the |
| 917 | service action for an entire protocol to be encapsulated in |
| 918 | the protocol-specific callback |
| 919 | <dt><b>per_session_data_size</b> |
| 920 | <dd>Each new connection using this protocol gets |
| 921 | this much memory allocated on connection establishment and |
| 922 | freed on connection takedown. A pointer to this per-connection |
| 923 | allocation is passed into the callback in the 'user' parameter |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 924 | <dt><b>owning_server</b> |
| 925 | <dd>the server init call fills in this opaque pointer when |
| 926 | registering this protocol with the server. |
| 927 | <dt><b>broadcast_socket_port</b> |
| 928 | <dd>the server init call fills this in with the |
| 929 | localhost port number used to forward broadcasts for this |
| 930 | protocol |
| 931 | <dt><b>broadcast_socket_user_fd</b> |
| 932 | <dd>the server init call fills this in ... the <b>main</b> |
| 933 | process context can write to this socket to perform broadcasts |
| 934 | (use the <b>libwebsockets_broadcast</b> api to do this instead, |
| 935 | it works from any process context) |
| 936 | <dt><b>protocol_index</b> |
| 937 | <dd>which protocol we are starting from zero |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 938 | </dl> |
| 939 | <h3>Description</h3> |
| 940 | <blockquote> |
| 941 | This structure represents one protocol supported by the server. An |
| 942 | array of these structures is passed to <b>libwebsocket_create_server</b> |
| 943 | allows as many protocols as you like to be handled by one server. |
| 944 | </blockquote> |
| 945 | <hr> |
Andy Green | d6e0911 | 2011-03-05 16:12:15 +0000 | [diff] [blame] | 946 | <h2>struct libwebsocket_extension - An extension we know how to cope with</h2> |
| 947 | <b>struct libwebsocket_extension</b> {<br> |
| 948 | <i>const char *</i> <b>name</b>;<br> |
David Brooks | 2c60d95 | 2012-04-20 12:19:01 +0800 | [diff] [blame] | 949 | <i>extension_callback_function *</i> <b>callback</b>;<br> |
Andy Green | d6e0911 | 2011-03-05 16:12:15 +0000 | [diff] [blame] | 950 | <i>size_t</i> <b>per_session_data_size</b>;<br> |
Andy Green | aa6fc44 | 2012-04-12 13:26:49 +0800 | [diff] [blame] | 951 | <i>void *</i> <b>per_context_private_data</b>;<br> |
Andy Green | d6e0911 | 2011-03-05 16:12:15 +0000 | [diff] [blame] | 952 | };<br> |
| 953 | <h3>Members</h3> |
| 954 | <dl> |
| 955 | <dt><b>name</b> |
| 956 | <dd>Formal extension name, eg, "deflate-stream" |
| 957 | <dt><b>callback</b> |
| 958 | <dd>Service callback |
| 959 | <dt><b>per_session_data_size</b> |
| 960 | <dd>Libwebsockets will auto-malloc this much |
| 961 | memory for the use of the extension, a pointer |
| 962 | to it comes in the <tt><b>user</b></tt> callback parameter |
Andy Green | aa6fc44 | 2012-04-12 13:26:49 +0800 | [diff] [blame] | 963 | <dt><b>per_context_private_data</b> |
| 964 | <dd>Optional storage for this externsion that |
| 965 | is per-context, so it can track stuff across |
| 966 | all sessions, etc, if it wants |
Andy Green | d6e0911 | 2011-03-05 16:12:15 +0000 | [diff] [blame] | 967 | </dl> |
| 968 | <hr> |