Up
Copied from google cache
Успел скопировать, уже недоступно ни в кэше, ни в оригинале

libwebsocket_create_server - Create the listening websockets server

int libwebsocket_create_server (int port, struct libwebsocket_protocols * protocols, const char * ssl_cert_filepath, const char * ssl_private_key_filepath, int gid, int uid)

Arguments

port
Port to listen on
protocols
Array of structures listing supported protocols and a protocol- specific callback for each one. The list is ended with an entry that has a NULL callback pointer. It's not const because we write the owning_server member
ssl_cert_filepath
If libwebsockets was compiled to use ssl, and you want to listen using SSL, set to the filepath to fetch the server cert from, otherwise NULL for unencrypted
ssl_private_key_filepath
filepath to private key if wanting SSL mode, else ignored
gid
group id to change to after setting listen socket, or -1.
uid
user id to change to after setting listen socket, or -1.

Description

This function creates the listening socket and takes care of all initialization in one step.

After initialization, it forks a thread that will sits in a service loop and returns to the caller. The actual service actions are performed by user code in a per-protocol callback from the appropriate one selected by the client from the list in protocols.

The protocol callback functions are called for a handful of events including http requests coming in, websocket connections becoming established, and data arriving; it's also called periodically to allow async transmission.

HTTP requests are sent always to the FIRST protocol in protocol, since at that time websocket protocol has not been negotiated. Other protocols after the first one never see any HTTP callack activity.

The server created is a simple http server by default; part of the websocket standard is upgrading this http connection to a websocket one.

This allows the same server to provide files like scripts and favicon / images or whatever over http and dynamic data over websockets all in one place; they're all handled in the user callback.

libwebsockets_get_protocol - Returns a protocol pointer from a websocket connection.

const struct libwebsocket_protocols * libwebsockets_get_protocol (struct libwebsocket * wsi)

Arguments

wsi
pointer to struct websocket you want to know the protocol of

Description

This is useful to get the protocol to broadcast back to from inside the callback.

libwebsockets_broadcast - Sends a buffer to rthe callback for all active connections of the given protocol.

int libwebsockets_broadcast (const struct libwebsocket_protocols * protocol, unsigned char * buf, size_t len)

Arguments

protocol
pointer to the protocol you will broadcast to all members of
buf
buffer containing the data to be broadcase. NOTE: this has to be allocated with LWS_SEND_BUFFER_PRE_PADDING valid bytes before the pointer and LWS_SEND_BUFFER_POST_PADDING afterwards in the case you are calling this function from callback context.
len
length of payload data in buf, starting from buf.

Description

This function allows bulk sending of a packet to every connection using the given protocol. It does not send the data directly; instead it calls the callback with a reason type of LWS_CALLBACK_BROADCAST. If the callback wants to actually send the data for that connection, the callback itself should call libwebsocket_write.

libwebsockets_broadcast can be called from another fork context without having to take any care about data visibility between the processes, it'll "just work".

libwebsocket_write - Apply protocol then write data to client

int libwebsocket_write (struct libwebsocket * wsi, unsigned char * buf, size_t len, enum libwebsocket_write_protocol protocol)

Arguments

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_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer and an additional LWS_SEND_BUFFER_POST_PADDING bytes valid in the buffer after (buf + len). This is so the protocol header and trailer 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.

Description

This function provides the way to issue data back to the client for both http and websocket protocols.

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.

libwebsockets_serve_http_file - Send a file back to the client using http

int libwebsockets_serve_http_file (struct libwebsocket * wsi, const char * file, const char * content_type)

Arguments

wsi
Websocket instance (available from user callback)
file
The file to issue over http
content_type
The http content type, eg, text/html

Description

This function is intended to be called from the callback in response to http requests from the client. It allows the callback to issue local files down the http link in a single step.

callback - User server actions

int callback (struct libwebsocket * wsi, enum libwebsocket_callback_reasons reason, void * user, void * in, size_t len)

Arguments

wsi
Opaque websocket instance pointer
reason
The reason for the call
user
Pointer to per-session user data allocated by library
in
Pointer used for some callback reasons
len
Length set for some callback reasons

Description

This callback is the way the user controls what is served. All the protocol detail is hidden and handled by the library.

For each connection / session there is user data allocated that is pointed to by "user". You set the size of this user data area when the library is initialized with libwebsocket_create_server.

You get an opportunity to initialize user data when called back with LWS_CALLBACK_ESTABLISHED reason.

LWS_CALLBACK_ESTABLISHED

after successful websocket handshake

LWS_CALLBACK_CLOSED

when the websocket session ends

LWS_CALLBACK_BROADCAST

signal to send to client (you would use libwebsocket_write taking care about the special buffer requirements

LWS_CALLBACK_RECEIVE

data has appeared for the server, it can be found at *in and is len bytes long

LWS_CALLBACK_HTTP

an http request has come from a client that is not asking to upgrade the connection to a websocket one. This is a chance to serve http content, for example, to send a script to the client which will then open the websockets connection. in points to the URI path requested and libwebsockets_serve_http_file makes it very simple to send back a file to the client.

struct libwebsocket_protocols - List of protocols and handlers server supports.

struct libwebsocket_protocols {
    const char * name;
    int (*callback) (struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason, void *user,void *in, size_t len);
    size_t per_session_data_size;
    struct libwebsocket_context * owning_server;
    int broadcast_socket_port;
    int broadcast_socket_user_fd;
    int protocol_index;
};

Members

name
Protocol name that must match the one given in the client Javascript new WebSocket(url, 'protocol') name
callback
The service callback used for this protocol. It allows the service action for an entire protocol to be encapsulated in the protocol-specific callback
per_session_data_size
Each new connection using this protocol gets this much memory allocated on connection establishment and freed on connection takedown. A pointer to this per-connection allocation is passed into the callback in the 'user' parameter
owning_server
the server init call fills in this opaque pointer when registering this protocol with the server.
broadcast_socket_port
the server init call fills this in with the localhost port number used to forward broadcasts for this protocol
broadcast_socket_user_fd
the server init call fills this in ... the main process context can write to this socket to perform broadcasts (use the libwebsockets_broadcast api to do this instead, it works from any process context)
protocol_index
which protocol we are starting from zero

Description

This structure represents one protocol supported by the server. An array of these structures is passed to libwebsocket_create_server allows as many protocols as you like to be handled by one server.