fix-user-pointer-bug.patch
[platform/upstream/libwebsockets.git] / libwebsockets-api-doc.html
1 <h2>callback - User server actions</h2>
2 <i>int</i>
3 <b>callback</b>
4 (<i>struct libwebsocket *</i> <b>wsi</b>,
5 <i>enum libwebsocket_callback_reasons</i> <b>reason</b>,
6 <i>void *</i> <b>user</b>,
7 <i>void *</i> <b>in</b>,
8 <i>size_t</i> <b>len</b>)
9 <h3>Arguments</h3>
10 <dl>
11 <dt><b>wsi</b>
12 <dd>Opaque websocket instance pointer
13 <dt><b>reason</b>
14 <dd>The reason for the call
15 <dt><b>user</b>
16 <dd>Pointer to per-session user data allocated by library
17 <dt><b>in</b>
18 <dd>Pointer used for some callback reasons
19 <dt><b>len</b>
20 <dd>Length set for some callback reasons
21 </dl>
22 <h3>Description</h3>
23 <blockquote>
24 This callback is the way the user controls what is served.  All the
25 protocol detail is hidden and handled by the library.
26 <p>
27 For each connection / session there is user data allocated that is
28 pointed to by "user".  You set the size of this user data area when
29 the library is initialized with libwebsocket_create_server.
30 <p>
31 You get an opportunity to initialize user data when called back with
32 LWS_CALLBACK_ESTABLISHED reason.
33 </blockquote>
34 <h3>LWS_CALLBACK_ESTABLISHED</h3>
35 <blockquote>
36 after successful websocket handshake
37 </blockquote>
38 <h3>LWS_CALLBACK_CLOSED</h3>
39 <blockquote>
40 when the websocket session ends
41 </blockquote>
42 <h3>LWS_CALLBACK_SEND</h3>
43 <blockquote>
44 opportunity to send to client (you would use
45 <b>libwebsocket_write</b> taking care about the
46 special buffer requirements
47 </blockquote>
48 <h3>LWS_CALLBACK_RECEIVE</h3>
49 <blockquote>
50 data has appeared for the server, it can be
51 found at *in and is len bytes long
52 </blockquote>
53 <h3>LWS_CALLBACK_HTTP</h3>
54 <blockquote>
55 an http request has come from a client that is not
56 asking to upgrade the connection to a websocket
57 one.  This is a chance to serve http content,
58 for example, to send a script to the client
59 which will then open the websockets connection.
60 <tt><b>in</b></tt> points to the URI path requested and 
61 <b>libwebsockets_serve_http_file</b> makes it very
62 simple to send back a file to the client.
63 </blockquote>
64 <hr>
65 <h2>libwebsocket_create_server - Create the listening websockets server</h2>
66 <i>int</i>
67 <b>libwebsocket_create_server</b>
68 (<i>int</i> <b>port</b>,
69 <i>const struct libwebsocket_protocols *</i> <b>protocols</b>,
70 <i>const char *</i> <b>ssl_cert_filepath</b>,
71 <i>const char *</i> <b>ssl_private_key_filepath</b>,
72 <i>int</i> <b>gid</b>,
73 <i>int</i> <b>uid</b>)
74 <h3>Arguments</h3>
75 <dl>
76 <dt><b>port</b>
77 <dd>Port to listen on
78 <dt><b>protocols</b>
79 <dd>Array of structures listing supported protocols and a protocol-
80 specific callback for each one.  The list is ended with an
81 entry that has a NULL callback pointer.
82 <dt><b>ssl_cert_filepath</b>
83 <dd>If libwebsockets was compiled to use ssl, and you want
84 to listen using SSL, set to the filepath to fetch the
85 server cert from, otherwise NULL for unencrypted
86 <dt><b>ssl_private_key_filepath</b>
87 <dd>filepath to private key if wanting SSL mode,
88 else ignored
89 <dt><b>gid</b>
90 <dd>group id to change to after setting listen socket, or -1.
91 <dt><b>uid</b>
92 <dd>user id to change to after setting listen socket, or -1.
93 </dl>
94 <h3>Description</h3>
95 <blockquote>
96 This function creates the listening socket and takes care
97 of all initialization in one step.
98 <p>
99 It does not return since it sits in a service loop and operates via the
100 callbacks given in <tt><b>protocol</b></tt>.  User code should fork before calling
101 <b>libwebsocket_create_server</b> if it wants to do other things in
102 parallel other than serve websockets.
103 <p>
104 The protocol callback functions are called for a handful of events
105 including http requests coming in, websocket connections becoming
106 established, and data arriving; it's also called periodically to allow
107 async transmission.
108 <p>
109 HTTP requests are sent always to the FIRST protocol in <tt><b>protocol</b></tt>, since
110 at that time websocket protocol has not been negotiated.  Other
111 protocols after the first one never see any HTTP callack activity.
112 <p>
113 The server created is a simple http server by default; part of the
114 websocket standard is upgrading this http connection to a websocket one.
115 <p>
116 This allows the same server to provide files like scripts and favicon /
117 images or whatever over http and dynamic data over websockets all in
118 one place; they're all handled in the user callback.
119 </blockquote>
120 <hr>
121 <h2>libwebsocket_write - Apply protocol then write data to client</h2>
122 <i>int</i>
123 <b>libwebsocket_write</b>
124 (<i>struct libwebsocket *</i> <b>wsi</b>,
125 <i>unsigned char *</i> <b>buf</b>,
126 <i>size_t</i> <b>len</b>,
127 <i>enum libwebsocket_write_protocol</i> <b>protocol</b>)
128 <h3>Arguments</h3>
129 <dl>
130 <dt><b>wsi</b>
131 <dd>Websocket instance (available from user callback)
132 <dt><b>buf</b>
133 <dd>The data to send.  For data being sent on a websocket
134 connection (ie, not default http), this buffer MUST have
135 LWS_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer
136 and an additional LWS_SEND_BUFFER_POST_PADDING bytes valid
137 in the buffer after (buf + len).  This is so the protocol
138 header and trailer data can be added in-situ.
139 <dt><b>len</b>
140 <dd>Count of the data bytes in the payload starting from buf
141 <dt><b>protocol</b>
142 <dd>Use LWS_WRITE_HTTP to reply to an http connection, and one
143 of LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate
144 data on a websockets connection.  Remember to allow the extra
145 bytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT
146 are used.
147 </dl>
148 <h3>Description</h3>
149 <blockquote>
150 This function provides the way to issue data back to the client
151 for both http and websocket protocols.
152 <p>
153 In the case of sending using websocket protocol, be sure to allocate
154 valid storage before and after buf as explained above.  This scheme
155 allows maximum efficiency of sending data and protocol in a single
156 packet while not burdening the user code with any protocol knowledge.
157 </blockquote>
158 <hr>
159 <h2>libwebsockets_serve_http_file - Send a file back to the client using http</h2>
160 <i>int</i>
161 <b>libwebsockets_serve_http_file</b>
162 (<i>struct libwebsocket *</i> <b>wsi</b>,
163 <i>const char *</i> <b>file</b>,
164 <i>const char *</i> <b>content_type</b>)
165 <h3>Arguments</h3>
166 <dl>
167 <dt><b>wsi</b>
168 <dd>Websocket instance (available from user callback)
169 <dt><b>file</b>
170 <dd>The file to issue over http
171 <dt><b>content_type</b>
172 <dd>The http content type, eg, text/html
173 </dl>
174 <h3>Description</h3>
175 <blockquote>
176 This function is intended to be called from the callback in response
177 to http requests from the client.  It allows the callback to issue
178 local files down the http link in a single step.
179 </blockquote>
180 <hr>
181 <h2>struct libwebsocket_protocols - List of protocols and handlers server supports.</h2>
182 <b>struct libwebsocket_protocols</b> {<br>
183 &nbsp; &nbsp; <i>const char *</i> <b>name</b>;<br>
184 &nbsp; &nbsp; <i>int (*</i><b>callback</b>) <i>(struct libwebsocket * wsi,enum libwebsocket_callback_reasons reason, void * user,void *in, size_t len)</i>;<br>
185 &nbsp; &nbsp; <i>size_t</i> <b>per_session_data_size</b>;<br>
186 };<br>
187 <h3>Members</h3>
188 <dl>
189 <dt><b>name</b>
190 <dd>Protocol name that must match the one given in the client
191 Javascript new WebSocket(url, 'protocol') name
192 <dt><b>callback</b>
193 <dd>The service callback used for this protocol.  It allows the
194 service action for an entire protocol to be encapsulated in
195 the protocol-specific callback
196 <dt><b>per_session_data_size</b>
197 <dd>Each new connection using this protocol gets
198 this much memory allocated on connection establishment and
199 freed on connection takedown.  A pointer to this per-connection
200 allocation is passed into the callback in the 'user' parameter
201 </dl>
202 <h3>Description</h3>
203 <blockquote>
204 This structure represents one protocol supported by the server.  An
205 array of these structures is passed to <b>libwebsocket_create_server</b>
206 allows as many protocols as you like to be handled by one server.
207 </blockquote>
208 <hr>