![]() |
libwebsockets
Lightweight C library for HTML5 websockets
|
Enumerations | |
enum | lws_write_protocol { LWS_WRITE_TEXT = 0, LWS_WRITE_BINARY = 1, LWS_WRITE_CONTINUATION = 2, LWS_WRITE_HTTP = 3, LWS_WRITE_PING = 5, LWS_WRITE_PONG = 6, LWS_WRITE_HTTP_FINAL = 7, LWS_WRITE_HTTP_HEADERS = 8, LWS_WRITE_NO_FIN = 0x40, LWS_WRITE_CLIENT_IGNORE_XOR_MASK = 0x80 } |
Functions | |
LWS_VISIBLE LWS_EXTERN int | lws_write (struct lws *wsi, unsigned char *buf, size_t len, enum lws_write_protocol protocol) |
APIs related to writing data on a connection
enum lws_write_protocol |
#include <lib/libwebsockets.h>
LWS_VISIBLE LWS_EXTERN int lws_write | ( | struct lws * | wsi, |
unsigned char * | buf, | ||
size_t | len, | ||
enum lws_write_protocol | protocol | ||
) |
#include <lib/libwebsockets.h>
lws_write() - Apply protocol then write data to client
wsi | Websocket instance (available from user callback) |
buf | The data to send. For data being sent on a websocket connection (ie, not default http), this buffer MUST have LWS_PRE bytes valid BEFORE the pointer. This is so the protocol header data can be added in-situ. |
len | Count of the data bytes in the payload starting from buf |
protocol | Use LWS_WRITE_HTTP to reply to an http connection, and one of LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate data on a websockets connection. Remember to allow the extra bytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT are used. |
This function provides the way to issue data back to the client for both http and websocket protocols.
IMPORTANT NOTICE!
When sending with websocket protocol
LWS_WRITE_TEXT, LWS_WRITE_BINARY, LWS_WRITE_CONTINUATION, LWS_WRITE_PING, LWS_WRITE_PONG
the send buffer has to have LWS_PRE bytes valid BEFORE the buffer pointer you pass to lws_write().
This allows us to add protocol info before and after the data, and send as one packet on the network without payload copying, for maximum efficiency.
So for example you need this kind of code to use lws_write with a 128-byte payload
char buf[LWS_PRE + 128];
// fill your part of the buffer... for example here it's all zeros memset(&buf[LWS_PRE], 0, 128);
lws_write(wsi, &buf[LWS_PRE], 128, LWS_WRITE_TEXT);
When sending HTTP, with
LWS_WRITE_HTTP, LWS_WRITE_HTTP_HEADERS LWS_WRITE_HTTP_FINAL
there is no protocol data prepended, and don't need to take care about the LWS_PRE bytes valid before the buffer pointer.
LWS_PRE is at least the frame nonce + 2 header + 8 length LWS_SEND_BUFFER_POST_PADDING is deprecated, it's now 0 and can be left off. The example apps no longer use it.
Pad LWS_PRE to the CPU word size, so that word references to the address immediately after the padding won't cause an unaligned access error. Sometimes for performance reasons the recommended padding is even larger than sizeof(void *).
In the case of sending using websocket protocol, be sure to allocate valid storage before and after buf as explained above. This scheme allows maximum efficiency of sending data and protocol in a single packet while not burdening the user code with any protocol knowledge. Return may be -1 for a fatal error needing connection close, or the number of bytes sent.
The OS may not accept everything you asked to write on the connection.
Posix defines POLLOUT indication from poll() to show that the connection will accept more write data, but it doesn't specifiy how much. It may just accept one byte of whatever you wanted to send.
LWS will buffer the remainder automatically, and send it out autonomously.
During that time, WRITABLE callbacks will be suppressed.
This is to handle corner cases where unexpectedly the OS refuses what we usually expect it to accept. You should try to send in chunks that are almost always accepted in order to avoid the inefficiency of the buffering.