Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 1 | <h2>libwebsocket_create_server - Create the listening websockets server</h2> |
| 2 | <i>int</i> |
| 3 | <b>libwebsocket_create_server</b> |
| 4 | (<i>int</i> <b>port</b>, |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 5 | <i>struct libwebsocket_protocols *</i> <b>protocols</b>, |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 6 | <i>const char *</i> <b>ssl_cert_filepath</b>, |
| 7 | <i>const char *</i> <b>ssl_private_key_filepath</b>, |
| 8 | <i>int</i> <b>gid</b>, |
| 9 | <i>int</i> <b>uid</b>) |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 10 | <h3>Arguments</h3> |
| 11 | <dl> |
| 12 | <dt><b>port</b> |
| 13 | <dd>Port to listen on |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 14 | <dt><b>protocols</b> |
| 15 | <dd>Array of structures listing supported protocols and a protocol- |
| 16 | specific callback for each one. The list is ended with an |
| 17 | entry that has a NULL callback pointer. |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 18 | It's not const because we write the owning_server member |
Andy Green | 3faa9c7 | 2010-11-08 17:03:03 +0000 | [diff] [blame] | 19 | <dt><b>ssl_cert_filepath</b> |
| 20 | <dd>If libwebsockets was compiled to use ssl, and you want |
| 21 | to listen using SSL, set to the filepath to fetch the |
| 22 | server cert from, otherwise NULL for unencrypted |
| 23 | <dt><b>ssl_private_key_filepath</b> |
| 24 | <dd>filepath to private key if wanting SSL mode, |
| 25 | else ignored |
| 26 | <dt><b>gid</b> |
| 27 | <dd>group id to change to after setting listen socket, or -1. |
| 28 | <dt><b>uid</b> |
| 29 | <dd>user id to change to after setting listen socket, or -1. |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 30 | </dl> |
| 31 | <h3>Description</h3> |
| 32 | <blockquote> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 33 | This function creates the listening socket and takes care |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 34 | of all initialization in one step. |
| 35 | <p> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 36 | After initialization, it forks a thread that will sits in a service loop |
| 37 | and returns to the caller. The actual service actions are performed by |
| 38 | user code in a per-protocol callback from the appropriate one selected |
| 39 | by the client from the list in <tt><b>protocols</b></tt>. |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 40 | <p> |
| 41 | The protocol callback functions are called for a handful of events |
| 42 | including http requests coming in, websocket connections becoming |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 43 | established, and data arriving; it's also called periodically to allow |
| 44 | async transmission. |
| 45 | <p> |
Andy Green | 47943ae | 2010-11-12 11:15:49 +0000 | [diff] [blame] | 46 | HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since |
| 47 | at that time websocket protocol has not been negotiated. Other |
| 48 | protocols after the first one never see any HTTP callack activity. |
| 49 | <p> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 50 | The server created is a simple http server by default; part of the |
| 51 | websocket standard is upgrading this http connection to a websocket one. |
| 52 | <p> |
| 53 | This allows the same server to provide files like scripts and favicon / |
| 54 | images or whatever over http and dynamic data over websockets all in |
| 55 | one place; they're all handled in the user callback. |
| 56 | </blockquote> |
| 57 | <hr> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 58 | <h2>libwebsockets_get_protocol - Returns a protocol pointer from a websocket connection.</h2> |
| 59 | <i>const struct libwebsocket_protocols *</i> |
| 60 | <b>libwebsockets_get_protocol</b> |
| 61 | (<i>struct libwebsocket *</i> <b>wsi</b>) |
| 62 | <h3>Arguments</h3> |
| 63 | <dl> |
| 64 | <dt><b>wsi</b> |
| 65 | <dd>pointer to struct websocket you want to know the protocol of |
| 66 | </dl> |
| 67 | <h3>Description</h3> |
| 68 | <blockquote> |
| 69 | <p> |
| 70 | This is useful to get the protocol to broadcast back to from inside |
| 71 | the callback. |
| 72 | </blockquote> |
| 73 | <hr> |
| 74 | <h2>libwebsockets_broadcast - Sends a buffer to rthe callback for all active connections of the given protocol.</h2> |
| 75 | <i>int</i> |
| 76 | <b>libwebsockets_broadcast</b> |
| 77 | (<i>const struct libwebsocket_protocols *</i> <b>protocol</b>, |
| 78 | <i>unsigned char *</i> <b>buf</b>, |
| 79 | <i>size_t</i> <b>len</b>) |
| 80 | <h3>Arguments</h3> |
| 81 | <dl> |
| 82 | <dt><b>protocol</b> |
| 83 | <dd>pointer to the protocol you will broadcast to all members of |
| 84 | <dt><b>buf</b> |
| 85 | <dd>buffer containing the data to be broadcase. NOTE: this has to be |
| 86 | allocated with LWS_SEND_BUFFER_PRE_PADDING valid bytes before |
| 87 | the pointer and LWS_SEND_BUFFER_POST_PADDING afterwards in the |
| 88 | case you are calling this function from callback context. |
| 89 | <dt><b>len</b> |
| 90 | <dd>length of payload data in buf, starting from buf. |
| 91 | </dl> |
| 92 | <h3>Description</h3> |
| 93 | <blockquote> |
| 94 | This function allows bulk sending of a packet to every connection using |
| 95 | the given protocol. It does not send the data directly; instead it calls |
| 96 | the callback with a reason type of LWS_CALLBACK_BROADCAST. If the callback |
| 97 | wants to actually send the data for that connection, the callback itself |
| 98 | should call <b>libwebsocket_write</b>. |
| 99 | <p> |
| 100 | <b>libwebsockets_broadcast</b> can be called from another fork context without |
| 101 | having to take any care about data visibility between the processes, it'll |
| 102 | "just work". |
| 103 | </blockquote> |
| 104 | <hr> |
Andy Green | 62a1293 | 2010-11-03 11:19:23 +0000 | [diff] [blame] | 105 | <h2>libwebsocket_write - Apply protocol then write data to client</h2> |
| 106 | <i>int</i> |
| 107 | <b>libwebsocket_write</b> |
| 108 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 109 | <i>unsigned char *</i> <b>buf</b>, |
| 110 | <i>size_t</i> <b>len</b>, |
| 111 | <i>enum libwebsocket_write_protocol</i> <b>protocol</b>) |
| 112 | <h3>Arguments</h3> |
| 113 | <dl> |
| 114 | <dt><b>wsi</b> |
| 115 | <dd>Websocket instance (available from user callback) |
| 116 | <dt><b>buf</b> |
| 117 | <dd>The data to send. For data being sent on a websocket |
| 118 | connection (ie, not default http), this buffer MUST have |
| 119 | LWS_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer |
| 120 | and an additional LWS_SEND_BUFFER_POST_PADDING bytes valid |
| 121 | in the buffer after (buf + len). This is so the protocol |
| 122 | header and trailer data can be added in-situ. |
| 123 | <dt><b>len</b> |
| 124 | <dd>Count of the data bytes in the payload starting from buf |
| 125 | <dt><b>protocol</b> |
| 126 | <dd>Use LWS_WRITE_HTTP to reply to an http connection, and one |
| 127 | of LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate |
| 128 | data on a websockets connection. Remember to allow the extra |
| 129 | bytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT |
| 130 | are used. |
| 131 | </dl> |
| 132 | <h3>Description</h3> |
| 133 | <blockquote> |
| 134 | This function provides the way to issue data back to the client |
| 135 | for both http and websocket protocols. |
| 136 | <p> |
| 137 | In the case of sending using websocket protocol, be sure to allocate |
| 138 | valid storage before and after buf as explained above. This scheme |
| 139 | allows maximum efficiency of sending data and protocol in a single |
| 140 | packet while not burdening the user code with any protocol knowledge. |
| 141 | </blockquote> |
| 142 | <hr> |
| 143 | <h2>libwebsockets_serve_http_file - Send a file back to the client using http</h2> |
| 144 | <i>int</i> |
| 145 | <b>libwebsockets_serve_http_file</b> |
| 146 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 147 | <i>const char *</i> <b>file</b>, |
| 148 | <i>const char *</i> <b>content_type</b>) |
| 149 | <h3>Arguments</h3> |
| 150 | <dl> |
| 151 | <dt><b>wsi</b> |
| 152 | <dd>Websocket instance (available from user callback) |
| 153 | <dt><b>file</b> |
| 154 | <dd>The file to issue over http |
| 155 | <dt><b>content_type</b> |
| 156 | <dd>The http content type, eg, text/html |
| 157 | </dl> |
| 158 | <h3>Description</h3> |
| 159 | <blockquote> |
| 160 | This function is intended to be called from the callback in response |
| 161 | to http requests from the client. It allows the callback to issue |
| 162 | local files down the http link in a single step. |
| 163 | </blockquote> |
| 164 | <hr> |
Andy Green | 8f037e4 | 2010-12-19 22:13:26 +0000 | [diff] [blame^] | 165 | <h2>callback - User server actions</h2> |
| 166 | <i>int</i> |
| 167 | <b>callback</b> |
| 168 | (<i>struct libwebsocket *</i> <b>wsi</b>, |
| 169 | <i>enum libwebsocket_callback_reasons</i> <b>reason</b>, |
| 170 | <i>void *</i> <b>user</b>, |
| 171 | <i>void *</i> <b>in</b>, |
| 172 | <i>size_t</i> <b>len</b>) |
| 173 | <h3>Arguments</h3> |
| 174 | <dl> |
| 175 | <dt><b>wsi</b> |
| 176 | <dd>Opaque websocket instance pointer |
| 177 | <dt><b>reason</b> |
| 178 | <dd>The reason for the call |
| 179 | <dt><b>user</b> |
| 180 | <dd>Pointer to per-session user data allocated by library |
| 181 | <dt><b>in</b> |
| 182 | <dd>Pointer used for some callback reasons |
| 183 | <dt><b>len</b> |
| 184 | <dd>Length set for some callback reasons |
| 185 | </dl> |
| 186 | <h3>Description</h3> |
| 187 | <blockquote> |
| 188 | This callback is the way the user controls what is served. All the |
| 189 | protocol detail is hidden and handled by the library. |
| 190 | <p> |
| 191 | For each connection / session there is user data allocated that is |
| 192 | pointed to by "user". You set the size of this user data area when |
| 193 | the library is initialized with libwebsocket_create_server. |
| 194 | <p> |
| 195 | You get an opportunity to initialize user data when called back with |
| 196 | LWS_CALLBACK_ESTABLISHED reason. |
| 197 | </blockquote> |
| 198 | <h3>LWS_CALLBACK_ESTABLISHED</h3> |
| 199 | <blockquote> |
| 200 | after successful websocket handshake |
| 201 | </blockquote> |
| 202 | <h3>LWS_CALLBACK_CLOSED</h3> |
| 203 | <blockquote> |
| 204 | when the websocket session ends |
| 205 | </blockquote> |
| 206 | <h3>LWS_CALLBACK_BROADCAST</h3> |
| 207 | <blockquote> |
| 208 | signal to send to client (you would use |
| 209 | <b>libwebsocket_write</b> taking care about the |
| 210 | special buffer requirements |
| 211 | </blockquote> |
| 212 | <h3>LWS_CALLBACK_RECEIVE</h3> |
| 213 | <blockquote> |
| 214 | data has appeared for the server, it can be |
| 215 | found at *in and is len bytes long |
| 216 | </blockquote> |
| 217 | <h3>LWS_CALLBACK_HTTP</h3> |
| 218 | <blockquote> |
| 219 | an http request has come from a client that is not |
| 220 | asking to upgrade the connection to a websocket |
| 221 | one. This is a chance to serve http content, |
| 222 | for example, to send a script to the client |
| 223 | which will then open the websockets connection. |
| 224 | <tt><b>in</b></tt> points to the URI path requested and |
| 225 | <b>libwebsockets_serve_http_file</b> makes it very |
| 226 | simple to send back a file to the client. |
| 227 | </blockquote> |
| 228 | <hr> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 229 | <h2>struct libwebsocket_protocols - List of protocols and handlers server supports.</h2> |
| 230 | <b>struct libwebsocket_protocols</b> {<br> |
| 231 | <i>const char *</i> <b>name</b>;<br> |
Andy Green | e77ddd8 | 2010-11-13 10:03:47 +0000 | [diff] [blame] | 232 | <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] | 233 | <i>size_t</i> <b>per_session_data_size</b>;<br> |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 234 | <i>struct libwebsocket_context *</i> <b>owning_server</b>;<br> |
| 235 | <i>int</i> <b>broadcast_socket_port</b>;<br> |
| 236 | <i>int</i> <b>broadcast_socket_user_fd</b>;<br> |
| 237 | <i>int</i> <b>protocol_index</b>;<br> |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 238 | };<br> |
| 239 | <h3>Members</h3> |
| 240 | <dl> |
| 241 | <dt><b>name</b> |
| 242 | <dd>Protocol name that must match the one given in the client |
| 243 | Javascript new WebSocket(url, 'protocol') name |
| 244 | <dt><b>callback</b> |
| 245 | <dd>The service callback used for this protocol. It allows the |
| 246 | service action for an entire protocol to be encapsulated in |
| 247 | the protocol-specific callback |
| 248 | <dt><b>per_session_data_size</b> |
| 249 | <dd>Each new connection using this protocol gets |
| 250 | this much memory allocated on connection establishment and |
| 251 | freed on connection takedown. A pointer to this per-connection |
| 252 | allocation is passed into the callback in the 'user' parameter |
Andy Green | b45993c | 2010-12-18 15:13:50 +0000 | [diff] [blame] | 253 | <dt><b>owning_server</b> |
| 254 | <dd>the server init call fills in this opaque pointer when |
| 255 | registering this protocol with the server. |
| 256 | <dt><b>broadcast_socket_port</b> |
| 257 | <dd>the server init call fills this in with the |
| 258 | localhost port number used to forward broadcasts for this |
| 259 | protocol |
| 260 | <dt><b>broadcast_socket_user_fd</b> |
| 261 | <dd>the server init call fills this in ... the <b>main</b> |
| 262 | process context can write to this socket to perform broadcasts |
| 263 | (use the <b>libwebsockets_broadcast</b> api to do this instead, |
| 264 | it works from any process context) |
| 265 | <dt><b>protocol_index</b> |
| 266 | <dd>which protocol we are starting from zero |
Andy Green | 4f3943a | 2010-11-12 10:44:16 +0000 | [diff] [blame] | 267 | </dl> |
| 268 | <h3>Description</h3> |
| 269 | <blockquote> |
| 270 | This structure represents one protocol supported by the server. An |
| 271 | array of these structures is passed to <b>libwebsocket_create_server</b> |
| 272 | allows as many protocols as you like to be handled by one server. |
| 273 | </blockquote> |
| 274 | <hr> |