Project homepage Mailing List  Warmcat.com  API Docs  Github Mirror 
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1752653891, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ {"schema":"libjg2-1", "cid":"b325e8adf1ad9c42c973ccb20a620b8d", "oid":{ "oid": "1a308e4176cae2995e7f41b08d09660cde1370b7", "alias": []},"blobname": "libwebsockets-api-doc.html", "blob": "\u003ch2\u003elws_frame_is_binary - \u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elws_frame_is_binary\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003ethe connection we are inquiring about\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis is intended to be called from the LWS_CALLBACK_RECEIVE callback if\nit's interested to see if the frame it's dealing with was sent in binary\nmode.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsockets_remaining_packet_payload - Bytes to come before \u0022overall\u0022 rx packet is complete\u003c/h2\u003e\n\u003ci\u003esize_t\u003c/i\u003e\n\u003cb\u003elibwebsockets_remaining_packet_payload\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket instance (available from user callback)\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function is intended to be called from the callback if the\nuser code is interested in \u0022complete packets\u0022 from the client.\nlibwebsockets just passes through payload as it comes and issues a buffer\nadditionally when it hits a built-in limit. The LWS_CALLBACK_RECEIVE\ncallback handler can use this API to find out if the buffer it has just\nbeen given is the last piece of a \u0022complete packet\u0022 from the client --\nwhen that is the case \u003cb\u003elibwebsockets_remaining_packet_payload\u003c/b\u003e will return\n0.\n\u003cp\u003e\nMany protocols won't care becuse their packets are always small.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elws_get_library_version - \u003c/h2\u003e\n\u003ci\u003econst char *\u003c/i\u003e\n\u003cb\u003elws_get_library_version\u003c/b\u003e\n(\u003ci\u003e\u003c/i\u003e \u003cb\u003evoid\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003evoid\u003c/b\u003e\n\u003cdd\u003eno arguments\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nreturns a const char * to a string like \u00221.1 178d78c\u0022\nrepresenting the library version followed by the git head hash it\nwas built from\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsockets_get_peer_addresses - Get client address information\u003c/h2\u003e\n\u003ci\u003evoid\u003c/i\u003e\n\u003cb\u003elibwebsockets_get_peer_addresses\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003efd\u003c/b\u003e,\n\u003ci\u003echar *\u003c/i\u003e \u003cb\u003ename\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003ename_len\u003c/b\u003e,\n\u003ci\u003echar *\u003c/i\u003e \u003cb\u003erip\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003erip_len\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eLibwebsockets context\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eLocal struct libwebsocket associated with\n\u003cdt\u003e\u003cb\u003efd\u003c/b\u003e\n\u003cdd\u003eConnection socket descriptor\n\u003cdt\u003e\u003cb\u003ename\u003c/b\u003e\n\u003cdd\u003eBuffer to take client address name\n\u003cdt\u003e\u003cb\u003ename_len\u003c/b\u003e\n\u003cdd\u003eLength of client address name buffer\n\u003cdt\u003e\u003cb\u003erip\u003c/b\u003e\n\u003cdd\u003eBuffer to take client address IP qotted quad\n\u003cdt\u003e\u003cb\u003erip_len\u003c/b\u003e\n\u003cdd\u003eLength of client address IP buffer\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function fills in \u003ctt\u003e\u003cb\u003ename\u003c/b\u003e\u003c/tt\u003e and \u003ctt\u003e\u003cb\u003erip\u003c/b\u003e\u003c/tt\u003e with the name and IP of\nthe client connected with socket descriptor \u003ctt\u003e\u003cb\u003efd\u003c/b\u003e\u003c/tt\u003e. Names may be\ntruncated if there is not enough room. If either cannot be\ndetermined, they will be returned as valid zero-length strings.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_service_fd - Service polled socket with something waiting\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_service_fd\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct pollfd *\u003c/i\u003e \u003cb\u003epollfd\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003cdt\u003e\u003cb\u003epollfd\u003c/b\u003e\n\u003cdd\u003eThe pollfd entry describing the socket fd and which events\nhappened.\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function takes a pollfd that has POLLIN or POLLOUT activity and\nservices it according to the state of the associated\nstruct libwebsocket.\n\u003cp\u003e\nThe one call deals with all \u0022service\u0022 that might happen on a socket\nincluding listen accepts, http files as well as websocket protocol.\n\u003cp\u003e\nIf a pollfd says it has something, you can just pass it to\n\u003cb\u003elibwebsocket_serice_fd\u003c/b\u003e whether it is a socket handled by lws or not.\nIf it sees it is a lws socket, the traffic will be handled and\npollfd-\u0026gt;revents will be zeroed now.\n\u003cp\u003e\nIf the socket is foreign to lws, it leaves revents alone. So you can\nsee if you should service yourself by checking the pollfd revents\nafter letting lws try to service it.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_context_destroy - Destroy the websocket context\u003c/h2\u003e\n\u003ci\u003evoid\u003c/i\u003e\n\u003cb\u003elibwebsocket_context_destroy\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function closes any active connections and then frees the\ncontext. After calling this, any further use of the context is\nundefined.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_context_user - get the user data associated with the context\u003c/h2\u003e\n\u003ci\u003eLWS_EXTERN void *\u003c/i\u003e\n\u003cb\u003elibwebsocket_context_user\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis returns the optional user allocation that can be attached to\nthe context the sockets live in at context_create time. It's a way\nto let all sockets serviced in the same context share data without\nusing globals statics in the user code.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_service - Service any pending websocket activity\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_service\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003etimeout_ms\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003cdt\u003e\u003cb\u003etimeout_ms\u003c/b\u003e\n\u003cdd\u003eTimeout for poll; 0 means return immediately if nothing needed\nservice otherwise block and service immediately, returning\nafter the timeout if nothing needed service.\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function deals with any pending websocket traffic, for three\nkinds of event. It handles these events on both server and client\ntypes of connection the same.\n\u003cp\u003e\n1) Accept new connections to our context's server\n\u003cp\u003e\n2) Call the receive callback for incoming frame data received by\nserver or client connections.\n\u003cp\u003e\nYou need to call this service function periodically to all the above\nfunctions to happen; if your application is single-threaded you can\njust call it in your main event loop.\n\u003cp\u003e\nAlternatively you can fork a new process that asynchronously handles\ncalling this service in a loop. In that case you are happy if this\ncall blocks your thread until it needs to take care of something and\nwould call it with a large nonzero timeout. Your loop then takes no\nCPU while there is nothing happening.\n\u003cp\u003e\nIf you are calling it in a single-threaded app, you don't want it to\nwait around blocking other things in your loop from happening, so you\nwould call it with a timeout_ms of 0, so it returns immediately if\nnothing is pending, or as soon as it services whatever was pending.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_callback_on_writable - Request a callback when this socket becomes able to be written to without blocking\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_callback_on_writable\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003elibwebsockets context\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket connection instance to get callback for\n\u003c/dl\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_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.\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_callback_on_writable_all_protocol\u003c/b\u003e\n(\u003ci\u003econst struct libwebsocket_protocols *\u003c/i\u003e \u003cb\u003eprotocol\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003eprotocol\u003c/b\u003e\n\u003cdd\u003eProtocol whose connections will get callbacks\n\u003c/dl\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_set_timeout - marks the wsi as subject to a timeout\u003c/h2\u003e\n\u003ci\u003evoid\u003c/i\u003e\n\u003cb\u003elibwebsocket_set_timeout\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eenum pending_timeout\u003c/i\u003e \u003cb\u003ereason\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003esecs\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket connection instance\n\u003cdt\u003e\u003cb\u003ereason\u003c/b\u003e\n\u003cdd\u003etimeout reason\n\u003cdt\u003e\u003cb\u003esecs\u003c/b\u003e\n\u003cdd\u003ehow many seconds\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nYou will not need this unless you are doing something special\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_get_socket_fd - returns the socket file descriptor\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_get_socket_fd\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket connection instance\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nYou will not need this unless you are doing something special\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_rx_flow_control - Enable and disable socket servicing for receieved packets.\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_rx_flow_control\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003eenable\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket connection instance to get callback for\n\u003cdt\u003e\u003cb\u003eenable\u003c/b\u003e\n\u003cdd\u003e0 \u003d disable read servicing for this connection, 1 \u003d enable\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nIf the output side of a server process becomes choked, this allows flow\ncontrol for the input side.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_rx_flow_allow_all_protocol - Allow all connections with this protocol to receive\u003c/h2\u003e\n\u003ci\u003evoid\u003c/i\u003e\n\u003cb\u003elibwebsocket_rx_flow_allow_all_protocol\u003c/b\u003e\n(\u003ci\u003econst struct libwebsocket_protocols *\u003c/i\u003e \u003cb\u003eprotocol\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003eprotocol\u003c/b\u003e\n\u003cdd\u003eall connections using this protocol will be allowed to receive\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nWhen the user server code realizes it can accept more input, it can\ncall this to have the RX flow restriction removed from all connections using\nthe given protocol.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_canonical_hostname - returns this host's hostname\u003c/h2\u003e\n\u003ci\u003econst char *\u003c/i\u003e\n\u003cb\u003elibwebsocket_canonical_hostname\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nThis is typically used by client code to fill in the host parameter\nwhen making a client connection. You can only call it after the context\nhas been created.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_create_context - Create the websocket handler\u003c/h2\u003e\n\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e\n\u003cb\u003elibwebsocket_create_context\u003c/b\u003e\n(\u003ci\u003estruct lws_context_creation_info *\u003c/i\u003e \u003cb\u003einfo\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003einfo\u003c/b\u003e\n\u003cdd\u003epointer to struct with parameters\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function creates the listening socket (if serving) and takes care\nof all initialization in one step.\n\u003cp\u003e\nAfter initialization, it returns a struct libwebsocket_context * that\nrepresents this server. After calling, user code needs to take care\nof calling \u003cb\u003elibwebsocket_service\u003c/b\u003e with the context pointer to get the\nserver's sockets serviced. This can be done in the same process context\nor a forked process, or another thread,\n\u003cp\u003e\nThe protocol callback functions are called for a handful of events\nincluding http requests coming in, websocket connections becoming\nestablished, and data arriving; it's also called periodically to allow\nasync transmission.\n\u003cp\u003e\nHTTP requests are sent always to the FIRST protocol in \u003ctt\u003e\u003cb\u003eprotocol\u003c/b\u003e\u003c/tt\u003e, since\nat that time websocket protocol has not been negotiated. Other\nprotocols after the first one never see any HTTP callack activity.\n\u003cp\u003e\nThe server created is a simple http server by default; part of the\nwebsocket standard is upgrading this http connection to a websocket one.\n\u003cp\u003e\nThis allows the same server to provide files like scripts and favicon /\nimages or whatever over http and dynamic data over websockets all in\none place; they're all handled in the user callback.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsockets_get_protocol - Returns a protocol pointer from a websocket connection.\u003c/h2\u003e\n\u003ci\u003econst struct libwebsocket_protocols *\u003c/i\u003e\n\u003cb\u003elibwebsockets_get_protocol\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003epointer to struct websocket you want to know the protocol of\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\nSome apis can act on all live connections of a given protocol,\nthis is how you can get a pointer to the active protocol if needed.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elws_set_log_level - Set the logging bitfield\u003c/h2\u003e\n\u003ci\u003evoid\u003c/i\u003e\n\u003cb\u003elws_set_log_level\u003c/b\u003e\n(\u003ci\u003eint\u003c/i\u003e \u003cb\u003elevel\u003c/b\u003e,\n\u003ci\u003evoid (*\u003c/i\u003e\u003cb\u003elog_emit_function\u003c/b\u003e) \u003ci\u003e(int level, \t\t\t\t\t\t\t const char *line)\u003c/i\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003elevel\u003c/b\u003e\n\u003cdd\u003eOR together the LLL_ debug contexts you want output from\n\u003cdt\u003e\u003cb\u003elog_emit_function\u003c/b\u003e\n\u003cdd\u003eNULL to leave it as it is, or a user-supplied\nfunction to perform log string emission instead of\nthe default stderr one.\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nlog level defaults to \u0022err\u0022, \u0022warn\u0022 and \u0022notice\u0022 contexts enabled and\nemission on stderr.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_write - Apply protocol then write data to client\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsocket_write\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eunsigned char *\u003c/i\u003e \u003cb\u003ebuf\u003c/b\u003e,\n\u003ci\u003esize_t\u003c/i\u003e \u003cb\u003elen\u003c/b\u003e,\n\u003ci\u003eenum libwebsocket_write_protocol\u003c/i\u003e \u003cb\u003eprotocol\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket instance (available from user callback)\n\u003cdt\u003e\u003cb\u003ebuf\u003c/b\u003e\n\u003cdd\u003eThe data to send. For data being sent on a websocket\nconnection (ie, not default http), this buffer MUST have\nLWS_SEND_BUFFER_PRE_PADDING bytes valid BEFORE the pointer\nand an additional LWS_SEND_BUFFER_POST_PADDING bytes valid\nin the buffer after (buf + len). This is so the protocol\nheader and trailer data can be added in-situ.\n\u003cdt\u003e\u003cb\u003elen\u003c/b\u003e\n\u003cdd\u003eCount of the data bytes in the payload starting from buf\n\u003cdt\u003e\u003cb\u003eprotocol\u003c/b\u003e\n\u003cdd\u003eUse LWS_WRITE_HTTP to reply to an http connection, and one\nof LWS_WRITE_BINARY or LWS_WRITE_TEXT to send appropriate\ndata on a websockets connection. Remember to allow the extra\nbytes before and after buf if LWS_WRITE_BINARY or LWS_WRITE_TEXT\nare used.\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function provides the way to issue data back to the client\nfor both http and websocket protocols.\n\u003cp\u003e\nIn the case of sending using websocket protocol, be sure to allocate\nvalid storage before and after buf as explained above. This scheme\nallows maximum efficiency of sending data and protocol in a single\npacket while not burdening the user code with any protocol knowledge.\n\u003cp\u003e\nReturn may be -1 for a fatal error needing connection close, or a\npositive number reflecting the amount of bytes actually sent. This\ncan be less than the requested number of bytes due to OS memory\npressure at any given time.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsockets_serve_http_file - Send a file back to the client using http\u003c/h2\u003e\n\u003ci\u003eint\u003c/i\u003e\n\u003cb\u003elibwebsockets_serve_http_file\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003efile\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003econtent_type\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003elibwebsockets context\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eWebsocket instance (available from user callback)\n\u003cdt\u003e\u003cb\u003efile\u003c/b\u003e\n\u003cdd\u003eThe file to issue over http\n\u003cdt\u003e\u003cb\u003econtent_type\u003c/b\u003e\n\u003cdd\u003eThe http content type, eg, text/html\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function is intended to be called from the callback in response\nto http requests from the client. It allows the callback to issue\nlocal files down the http link in a single step.\n\u003cp\u003e\nReturning \u0026lt;0 indicates error and the wsi should be closed. Returning\n\u0026gt;0 indicates the file was completely sent and the wsi should be closed.\n\u003d\u003d0 indicates the file transfer is started and needs more service later,\nthe wsi should be left alone.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_client_connect - Connect to another websocket server\u003c/h2\u003e\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e\n\u003cb\u003elibwebsocket_client_connect\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eaddress\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003eport\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003essl_connection\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003epath\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003ehost\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eorigin\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eprotocol\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003eietf_version_or_minus_one\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003cdt\u003e\u003cb\u003eaddress\u003c/b\u003e\n\u003cdd\u003eRemote server address, eg, \u0022myserver.com\u0022\n\u003cdt\u003e\u003cb\u003eport\u003c/b\u003e\n\u003cdd\u003ePort to connect to on the remote server, eg, 80\n\u003cdt\u003e\u003cb\u003essl_connection\u003c/b\u003e\n\u003cdd\u003e0 \u003d ws://, 1 \u003d wss:// encrypted, 2 \u003d wss:// allow self\nsigned certs\n\u003cdt\u003e\u003cb\u003epath\u003c/b\u003e\n\u003cdd\u003eWebsocket path on server\n\u003cdt\u003e\u003cb\u003ehost\u003c/b\u003e\n\u003cdd\u003eHostname on server\n\u003cdt\u003e\u003cb\u003eorigin\u003c/b\u003e\n\u003cdd\u003eSocket origin name\n\u003cdt\u003e\u003cb\u003eprotocol\u003c/b\u003e\n\u003cdd\u003eComma-separated list of protocols being asked for from\nthe server, or just one. The server will pick the one it\nlikes best.\n\u003cdt\u003e\u003cb\u003eietf_version_or_minus_one\u003c/b\u003e\n\u003cdd\u003e-1 to ask to connect using the default, latest\nprotocol supported, or the specific protocol ordinal\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function creates a connection to a remote server\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003elibwebsocket_client_connect_extended - Connect to another websocket server\u003c/h2\u003e\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e\n\u003cb\u003elibwebsocket_client_connect_extended\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eaddress\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003eport\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003essl_connection\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003epath\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003ehost\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eorigin\u003c/b\u003e,\n\u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eprotocol\u003c/b\u003e,\n\u003ci\u003eint\u003c/i\u003e \u003cb\u003eietf_version_or_minus_one\u003c/b\u003e,\n\u003ci\u003evoid *\u003c/i\u003e \u003cb\u003euserdata\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsocket context\n\u003cdt\u003e\u003cb\u003eaddress\u003c/b\u003e\n\u003cdd\u003eRemote server address, eg, \u0022myserver.com\u0022\n\u003cdt\u003e\u003cb\u003eport\u003c/b\u003e\n\u003cdd\u003ePort to connect to on the remote server, eg, 80\n\u003cdt\u003e\u003cb\u003essl_connection\u003c/b\u003e\n\u003cdd\u003e0 \u003d ws://, 1 \u003d wss:// encrypted, 2 \u003d wss:// allow self\nsigned certs\n\u003cdt\u003e\u003cb\u003epath\u003c/b\u003e\n\u003cdd\u003eWebsocket path on server\n\u003cdt\u003e\u003cb\u003ehost\u003c/b\u003e\n\u003cdd\u003eHostname on server\n\u003cdt\u003e\u003cb\u003eorigin\u003c/b\u003e\n\u003cdd\u003eSocket origin name\n\u003cdt\u003e\u003cb\u003eprotocol\u003c/b\u003e\n\u003cdd\u003eComma-separated list of protocols being asked for from\nthe server, or just one. The server will pick the one it\nlikes best.\n\u003cdt\u003e\u003cb\u003eietf_version_or_minus_one\u003c/b\u003e\n\u003cdd\u003e-1 to ask to connect using the default, latest\nprotocol supported, or the specific protocol ordinal\n\u003cdt\u003e\u003cb\u003euserdata\u003c/b\u003e\n\u003cdd\u003ePre-allocated user data\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis function creates a connection to a remote server\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003ecallback - User server actions\u003c/h2\u003e\n\u003ci\u003eLWS_EXTERN int\u003c/i\u003e\n\u003cb\u003ecallback\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eenum libwebsocket_callback_reasons\u003c/i\u003e \u003cb\u003ereason\u003c/b\u003e,\n\u003ci\u003evoid *\u003c/i\u003e \u003cb\u003euser\u003c/b\u003e,\n\u003ci\u003evoid *\u003c/i\u003e \u003cb\u003ein\u003c/b\u003e,\n\u003ci\u003esize_t\u003c/i\u003e \u003cb\u003elen\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsockets context\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eOpaque websocket instance pointer\n\u003cdt\u003e\u003cb\u003ereason\u003c/b\u003e\n\u003cdd\u003eThe reason for the call\n\u003cdt\u003e\u003cb\u003euser\u003c/b\u003e\n\u003cdd\u003ePointer to per-session user data allocated by library\n\u003cdt\u003e\u003cb\u003ein\u003c/b\u003e\n\u003cdd\u003ePointer used for some callback reasons\n\u003cdt\u003e\u003cb\u003elen\u003c/b\u003e\n\u003cdd\u003eLength set for some callback reasons\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis callback is the way the user controls what is served. All the\nprotocol detail is hidden and handled by the library.\n\u003cp\u003e\nFor each connection / session there is user data allocated that is\npointed to by \u0022user\u0022. You set the size of this user data area when\nthe library is initialized with libwebsocket_create_server.\n\u003cp\u003e\nYou get an opportunity to initialize user data when called back with\nLWS_CALLBACK_ESTABLISHED reason.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_ESTABLISHED\u003c/h3\u003e\n\u003cblockquote\u003e\nafter the server completes a handshake with\nan incoming client\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_CONNECTION_ERROR\u003c/h3\u003e\n\u003cblockquote\u003e\nthe request client connection has\nbeen unable to complete a handshake with the remote server\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_FILTER_PRE_ESTABLISH\u003c/h3\u003e\n\u003cblockquote\u003e\nthis is the last chance for the\nclient user code to examine the http headers\nand decide to reject the connection. If the\ncontent in the headers is interesting to the\nclient (url, etc) it needs to copy it out at\nthis point since it will be destroyed before\nthe CLIENT_ESTABLISHED call\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_ESTABLISHED\u003c/h3\u003e\n\u003cblockquote\u003e\nafter your client connection completed\na handshake with the remote server\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLOSED\u003c/h3\u003e\n\u003cblockquote\u003e\nwhen the websocket session ends\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_RECEIVE\u003c/h3\u003e\n\u003cblockquote\u003e\ndata has appeared for this server endpoint from a\nremote client, it can be found at *in and is\nlen bytes long\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_RECEIVE_PONG\u003c/h3\u003e\n\u003cblockquote\u003e\nif you elected to see PONG packets,\nthey appear with this callback reason. PONG\npackets only exist in 04+ protocol\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_RECEIVE\u003c/h3\u003e\n\u003cblockquote\u003e\ndata has appeared from the server for the\nclient connection, it can be found at *in and\nis len bytes long\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_HTTP\u003c/h3\u003e\n\u003cblockquote\u003e\nan http request has come from a client that is not\nasking to upgrade the connection to a websocket\none. This is a chance to serve http content,\nfor example, to send a script to the client\nwhich will then open the websockets connection.\n\u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e points to the URI path requested and\n\u003cb\u003elibwebsockets_serve_http_file\u003c/b\u003e makes it very\nsimple to send back a file to the client.\nNormally after sending the file you are done\nwith the http connection, since the rest of the\nactivity will come by websockets from the script\nthat was delivered by http, so you will want to\nreturn 1; to close and free up the connection.\nThat's important because it uses a slot in the\ntotal number of client connections allowed set\nby MAX_CLIENTS.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_HTTP_WRITEABLE\u003c/h3\u003e\n\u003cblockquote\u003e\nyou can write more down the http protocol\nlink now.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_HTTP_FILE_COMPLETION\u003c/h3\u003e\n\u003cblockquote\u003e\na file requested to be send down\nhttp link has completed.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_SERVER_WRITEABLE\u003c/h3\u003e\n\u003cblockquote\u003e\nIf you call\n\u003cb\u003elibwebsocket_callback_on_writable\u003c/b\u003e on a connection, you will\nget one of these callbacks coming when the connection socket\nis able to accept another write packet without blocking.\nIf it already was able to take another packet without blocking,\nyou'll get this callback at the next call to the service loop\nfunction. Notice that CLIENTs get LWS_CALLBACK_CLIENT_WRITEABLE\nand servers get LWS_CALLBACK_SERVER_WRITEABLE.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_FILTER_NETWORK_CONNECTION\u003c/h3\u003e\n\u003cblockquote\u003e\ncalled when a client connects to\nthe server at network level; the connection is accepted but then\npassed to this callback to decide whether to hang up immediately\nor not, based on the client IP. \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e contains the connection\nsocket's descriptor. Return non-zero to terminate\nthe connection before sending or receiving anything.\nBecause this happens immediately after the network connection\nfrom the client, there's no websocket protocol selected yet so\nthis callback is issued only to protocol 0.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_FILTER_PROTOCOL_CONNECTION\u003c/h3\u003e\n\u003cblockquote\u003e\ncalled when the handshake has\nbeen received and parsed from the client, but the response is\nnot sent yet. Return non-zero to disallow the connection.\n\u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is a pointer to an array of struct lws_tokens, you can\nuse the header enums lws_token_indexes from libwebsockets.h\nto check for and read the supported header presence and\ncontent before deciding to allow the handshake to proceed or\nto kill the connection.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS\u003c/h3\u003e\n\u003cblockquote\u003e\nif configured for\nincluding OpenSSL support, this callback allows your user code\nto perform extra \u003cb\u003eSSL_CTX_load_verify_locations\u003c/b\u003e or similar\ncalls to direct OpenSSL where to find certificates the client\ncan use to confirm the remote server identity. \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is the\nOpenSSL SSL_CTX*\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS\u003c/h3\u003e\n\u003cblockquote\u003e\nif configured for\nincluding OpenSSL support, this callback allows your user code\nto load extra certifcates into the server which allow it to\nverify the validity of certificates returned by clients. \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e\nis the server's OpenSSL SSL_CTX*\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_OPENSSL_PERFORM_CLIENT_CERT_VERIFICATION\u003c/h3\u003e\n\u003cblockquote\u003e\nif the\nlibwebsockets context was created with the option\nLWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT, then this\ncallback is generated during OpenSSL verification of the cert\nsent from the client. It is sent to protocol[0] callback as\nno protocol has been negotiated on the connection yet.\nNotice that the libwebsockets context and wsi are both NULL\nduring this callback. See\n\u003c/blockquote\u003e\n\u003ch3\u003ehttp\u003c/h3\u003e\n\u003cblockquote\u003e\n//www.openssl.org/docs/ssl/SSL_CTX_set_verify.html\nto understand more detail about the OpenSSL callback that\ngenerates this libwebsockets callback and the meanings of the\narguments passed. In this callback, \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is the x509_ctx,\n\u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e is the ssl pointer and \u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e is preverify_ok\nNotice that this callback maintains libwebsocket return\nconventions, return 0 to mean the cert is OK or 1 to fail it.\nThis also means that if you don't handle this callback then\nthe default callback action of returning 0 allows the client\ncertificates.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER\u003c/h3\u003e\n\u003cblockquote\u003e\nthis callback happens\nwhen a client handshake is being compiled. \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is NULL,\n\u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e is a char **, it's pointing to a char * which holds the\nnext location in the header buffer where you can add\nheaders, and \u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e is the remaining space in the header buffer,\nwhich is typically some hundreds of bytes. So, to add a canned\ncookie, your handler code might look similar to:\n\u003cp\u003e\nchar **p \u003d (char **)in;\n\u003cp\u003e\nif (len \u0026lt; 100)\nreturn 1;\n\u003cp\u003e\n*p +\u003d sprintf(*p, \u0022Cookie: a\u003db\u005cx0d\u005cx0a\u0022);\n\u003cp\u003e\nreturn 0;\n\u003cp\u003e\nNotice if you add anything, you just have to take care about\nthe CRLF on the line you added. Obviously this callback is\noptional, if you don't handle it everything is fine.\n\u003cp\u003e\nNotice the callback is coming to protocols[0] all the time,\nbecause there is no specific protocol handshook yet.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CONFIRM_EXTENSION_OKAY\u003c/h3\u003e\n\u003cblockquote\u003e\nWhen the server handshake code\nsees that it does support a requested extension, before\naccepting the extension by additing to the list sent back to\nthe client it gives this callback just to check that it's okay\nto use that extension. It calls back to the requested protocol\nand with \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e being the extension name, \u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e is 0 and \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is\nvalid. Note though at this time the ESTABLISHED callback hasn't\nhappened yet so if you initialize \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e content there, \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e\ncontent during this callback might not be useful for anything.\nNotice this callback comes to protocols[0].\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLIENT_CONFIRM_EXTENSION_SUPPORTED\u003c/h3\u003e\n\u003cblockquote\u003e\nWhen a client\nconnection is being prepared to start a handshake to a server,\neach supported extension is checked with protocols[0] callback\nwith this reason, giving the user code a chance to suppress the\nclaim to support that extension by returning non-zero. If\nunhandled, by default 0 will be returned and the extension\nsupport included in the header to the server. Notice this\ncallback comes to protocols[0].\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_PROTOCOL_INIT\u003c/h3\u003e\n\u003cblockquote\u003e\nOne-time call per protocol so it can\ndo initial setup / allocations etc\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_PROTOCOL_DESTROY\u003c/h3\u003e\n\u003cblockquote\u003e\nOne-time call per protocol indicating\nthis protocol won't get used at all after this callback, the\ncontext is getting destroyed. Take the opportunity to\ndeallocate everything that was allocated by the protocol.\n\u003cp\u003e\nThe next four reasons are optional and only need taking care of if you\nwill be integrating libwebsockets sockets into an external polling\narray.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_ADD_POLL_FD\u003c/h3\u003e\n\u003cblockquote\u003e\nlibwebsocket deals with its \u003cb\u003epoll\u003c/b\u003e loop\ninternally, but in the case you are integrating with another\nserver you will need to have libwebsocket sockets share a\npolling array with the other server. This and the other\nPOLL_FD related callbacks let you put your specialized\npoll array interface code in the callback for protocol 0, the\nfirst protocol you support, usually the HTTP protocol in the\nserving case. This callback happens when a socket needs to be\n\u003c/blockquote\u003e\n\u003ch3\u003eadded to the polling loop\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e contains the fd, and\n\u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e is the events bitmap (like, POLLIN). If you are using the\ninternal polling loop (the \u0022service\u0022 callback), you can just\nignore these callbacks.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_DEL_POLL_FD\u003c/h3\u003e\n\u003cblockquote\u003e\nThis callback happens when a socket descriptor\nneeds to be removed from an external polling array. \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e is\nthe socket desricptor. If you are using the internal polling\nloop, you can just ignore it.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_SET_MODE_POLL_FD\u003c/h3\u003e\n\u003cblockquote\u003e\nThis callback happens when libwebsockets\nwants to modify the events for the socket descriptor in \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e.\nThe handler should OR \u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e on to the events member of the pollfd\nstruct for this socket descriptor. If you are using the\ninternal polling loop, you can just ignore it.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_CALLBACK_CLEAR_MODE_POLL_FD\u003c/h3\u003e\n\u003cblockquote\u003e\nThis callback occurs when libwebsockets\nwants to modify the events for the socket descriptor in \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e.\nThe handler should AND ~\u003ctt\u003e\u003cb\u003elen\u003c/b\u003e\u003c/tt\u003e on to the events member of the\npollfd struct for this socket descriptor. If you are using the\ninternal polling loop, you can just ignore it.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003eextension_callback - Hooks to allow extensions to operate\u003c/h2\u003e\n\u003ci\u003eLWS_EXTERN int\u003c/i\u003e\n\u003cb\u003eextension_callback\u003c/b\u003e\n(\u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003econtext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket_extension *\u003c/i\u003e \u003cb\u003eext\u003c/b\u003e,\n\u003ci\u003estruct libwebsocket *\u003c/i\u003e \u003cb\u003ewsi\u003c/b\u003e,\n\u003ci\u003eenum libwebsocket_extension_callback_reasons\u003c/i\u003e \u003cb\u003ereason\u003c/b\u003e,\n\u003ci\u003evoid *\u003c/i\u003e \u003cb\u003euser\u003c/b\u003e,\n\u003ci\u003evoid *\u003c/i\u003e \u003cb\u003ein\u003c/b\u003e,\n\u003ci\u003esize_t\u003c/i\u003e \u003cb\u003elen\u003c/b\u003e)\n\u003ch3\u003eArguments\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003econtext\u003c/b\u003e\n\u003cdd\u003eWebsockets context\n\u003cdt\u003e\u003cb\u003eext\u003c/b\u003e\n\u003cdd\u003eThis extension\n\u003cdt\u003e\u003cb\u003ewsi\u003c/b\u003e\n\u003cdd\u003eOpaque websocket instance pointer\n\u003cdt\u003e\u003cb\u003ereason\u003c/b\u003e\n\u003cdd\u003eThe reason for the call\n\u003cdt\u003e\u003cb\u003euser\u003c/b\u003e\n\u003cdd\u003ePointer to per-session user data allocated by library\n\u003cdt\u003e\u003cb\u003ein\u003c/b\u003e\n\u003cdd\u003ePointer used for some callback reasons\n\u003cdt\u003e\u003cb\u003elen\u003c/b\u003e\n\u003cdd\u003eLength set for some callback reasons\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nEach extension that is active on a particular connection receives\ncallbacks during the connection lifetime to allow the extension to\noperate on websocket data and manage itself.\n\u003cp\u003e\nLibwebsockets takes care of allocating and freeing \u0022user\u0022 memory for\neach active extension on each connection. That is what is pointed to\nby the \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e parameter.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_EXT_CALLBACK_CONSTRUCT\u003c/h3\u003e\n\u003cblockquote\u003e\ncalled when the server has decided to\nselect this extension from the list provided by the client,\njust before the server will send back the handshake accepting\nthe connection with this extension active. This gives the\nextension a chance to initialize its connection context found\nin \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_EXT_CALLBACK_CLIENT_CONSTRUCT\u003c/h3\u003e\n\u003cblockquote\u003e\nsame as LWS_EXT_CALLBACK_CONSTRUCT\nbut called when client is instantiating this extension. Some\nextensions will work the same on client and server side and then\nyou can just merge handlers for both CONSTRUCTS.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_EXT_CALLBACK_DESTROY\u003c/h3\u003e\n\u003cblockquote\u003e\ncalled when the connection the extension was\nbeing used on is about to be closed and deallocated. It's the\nlast chance for the extension to deallocate anything it has\nallocated in the user data (pointed to by \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e) before the\nuser data is deleted. This same callback is used whether you\nare in client or server instantiation context.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_EXT_CALLBACK_PACKET_RX_PREPARSE\u003c/h3\u003e\n\u003cblockquote\u003e\nwhen this extension was active on\na connection, and a packet of data arrived at the connection,\nit is passed to this callback to give the extension a chance to\nchange the data, eg, decompress it. \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e is pointing to the\nextension's private connection context data, \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e is pointing\nto an lws_tokens struct, it consists of a char * pointer called\ntoken, and an int called token_len. At entry, these are\nset to point to the received buffer and set to the content\nlength. If the extension will grow the content, it should use\na new buffer allocated in its private user context data and\nset the pointed-to lws_tokens members to point to its buffer.\n\u003c/blockquote\u003e\n\u003ch3\u003eLWS_EXT_CALLBACK_PACKET_TX_PRESEND\u003c/h3\u003e\n\u003cblockquote\u003e\nthis works the same way as\nLWS_EXT_CALLBACK_PACKET_RX_PREPARSE above, except it gives the\nextension a chance to change websocket data just before it will\nbe sent out. Using the same lws_token pointer scheme in \u003ctt\u003e\u003cb\u003ein\u003c/b\u003e\u003c/tt\u003e,\nthe extension can change the buffer and the length to be\ntransmitted how it likes. Again if it wants to grow the\nbuffer safely, it should copy the data into its own buffer and\nset the lws_tokens token pointer to it.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003estruct libwebsocket_protocols - List of protocols and handlers server supports.\u003c/h2\u003e\n\u003cb\u003estruct libwebsocket_protocols\u003c/b\u003e {\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003ename\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003ecallback_function *\u003c/i\u003e \u003cb\u003ecallback\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003esize_t\u003c/i\u003e \u003cb\u003eper_session_data_size\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003esize_t\u003c/i\u003e \u003cb\u003erx_buffer_size\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003estruct libwebsocket_context *\u003c/i\u003e \u003cb\u003eowning_server\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003eprotocol_index\u003c/b\u003e;\u003cbr\u003e\n};\u003cbr\u003e\n\u003ch3\u003eMembers\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ename\u003c/b\u003e\n\u003cdd\u003eProtocol name that must match the one given in the client\nJavascript new WebSocket(url, 'protocol') name\n\u003cdt\u003e\u003cb\u003ecallback\u003c/b\u003e\n\u003cdd\u003eThe service callback used for this protocol. It allows the\nservice action for an entire protocol to be encapsulated in\nthe protocol-specific callback\n\u003cdt\u003e\u003cb\u003eper_session_data_size\u003c/b\u003e\n\u003cdd\u003eEach new connection using this protocol gets\nthis much memory allocated on connection establishment and\nfreed on connection takedown. A pointer to this per-connection\nallocation is passed into the callback in the 'user' parameter\n\u003cdt\u003e\u003cb\u003erx_buffer_size\u003c/b\u003e\n\u003cdd\u003eif you want atomic frames delivered to the callback, you\nshould set this to the size of the biggest legal frame that\nyou support. If the frame size is exceeded, there is no\nerror, but the buffer will spill to the user callback when\nfull, which you can detect by using\n\u003cb\u003elibwebsockets_remaining_packet_payload\u003c/b\u003e. Notice that you\njust talk about frame size here, the LWS_SEND_BUFFER_PRE_PADDING\nand post-padding are automatically also allocated on top.\n\u003cdt\u003e\u003cb\u003eowning_server\u003c/b\u003e\n\u003cdd\u003ethe server init call fills in this opaque pointer when\nregistering this protocol with the server.\n\u003cdt\u003e\u003cb\u003eprotocol_index\u003c/b\u003e\n\u003cdd\u003ewhich protocol we are starting from zero\n\u003c/dl\u003e\n\u003ch3\u003eDescription\u003c/h3\u003e\n\u003cblockquote\u003e\nThis structure represents one protocol supported by the server. An\narray of these structures is passed to \u003cb\u003elibwebsocket_create_server\u003c/b\u003e\nallows as many protocols as you like to be handled by one server.\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2\u003estruct libwebsocket_extension - An extension we know how to cope with\u003c/h2\u003e\n\u003cb\u003estruct libwebsocket_extension\u003c/b\u003e {\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003ename\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eextension_callback_function *\u003c/i\u003e \u003cb\u003ecallback\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003esize_t\u003c/i\u003e \u003cb\u003eper_session_data_size\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003evoid *\u003c/i\u003e \u003cb\u003eper_context_private_data\u003c/b\u003e;\u003cbr\u003e\n};\u003cbr\u003e\n\u003ch3\u003eMembers\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003ename\u003c/b\u003e\n\u003cdd\u003eFormal extension name, eg, \u0022deflate-stream\u0022\n\u003cdt\u003e\u003cb\u003ecallback\u003c/b\u003e\n\u003cdd\u003eService callback\n\u003cdt\u003e\u003cb\u003eper_session_data_size\u003c/b\u003e\n\u003cdd\u003eLibwebsockets will auto-malloc this much\nmemory for the use of the extension, a pointer\nto it comes in the \u003ctt\u003e\u003cb\u003euser\u003c/b\u003e\u003c/tt\u003e callback parameter\n\u003cdt\u003e\u003cb\u003eper_context_private_data\u003c/b\u003e\n\u003cdd\u003eOptional storage for this extension that\nis per-context, so it can track stuff across\nall sessions, etc, if it wants\n\u003c/dl\u003e\n\u003chr\u003e\n\u003ch2\u003estruct lws_context_creation_info - \u003c/h2\u003e\n\u003cb\u003estruct lws_context_creation_info\u003c/b\u003e {\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003eport\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003eiface\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003estruct libwebsocket_protocols *\u003c/i\u003e \u003cb\u003eprotocols\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003estruct libwebsocket_extension *\u003c/i\u003e \u003cb\u003eextensions\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003essl_cert_filepath\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003essl_private_key_filepath\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003essl_ca_filepath\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003econst char *\u003c/i\u003e \u003cb\u003essl_cipher_list\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003egid\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003euid\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eunsigned int\u003c/i\u003e \u003cb\u003eoptions\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003evoid *\u003c/i\u003e \u003cb\u003euser\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003eka_time\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003eka_probes\u003c/b\u003e;\u003cbr\u003e\n\u0026nbsp; \u0026nbsp; \u003ci\u003eint\u003c/i\u003e \u003cb\u003eka_interval\u003c/b\u003e;\u003cbr\u003e\n};\u003cbr\u003e\n\u003ch3\u003eMembers\u003c/h3\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cb\u003eport\u003c/b\u003e\n\u003cdd\u003ePort to listen on... you can use 0 to suppress listening on\nany port, that's what you want if you are not running a\nwebsocket server at all but just using it as a client\n\u003cdt\u003e\u003cb\u003eiface\u003c/b\u003e\n\u003cdd\u003eNULL to bind the listen socket to all interfaces, or the\ninterface name, eg, \u0022eth2\u0022\n\u003cdt\u003e\u003cb\u003eprotocols\u003c/b\u003e\n\u003cdd\u003eArray of structures listing supported protocols and a protocol-\nspecific callback for each one. The list is ended with an\nentry that has a NULL callback pointer.\nIt's not const because we write the owning_server member\n\u003cdt\u003e\u003cb\u003eextensions\u003c/b\u003e\n\u003cdd\u003eNULL or array of libwebsocket_extension structs listing the\nextensions this context supports. If you configured with\n--without-extensions, you should give NULL here.\n\u003cdt\u003e\u003cb\u003essl_cert_filepath\u003c/b\u003e\n\u003cdd\u003eIf libwebsockets was compiled to use ssl, and you want\nto listen using SSL, set to the filepath to fetch the\nserver cert from, otherwise NULL for unencrypted\n\u003cdt\u003e\u003cb\u003essl_private_key_filepath\u003c/b\u003e\n\u003cdd\u003efilepath to private key if wanting SSL mode,\nelse ignored\n\u003cdt\u003e\u003cb\u003essl_ca_filepath\u003c/b\u003e\n\u003cdd\u003eCA certificate filepath or NULL\n\u003cdt\u003e\u003cb\u003essl_cipher_list\u003c/b\u003e\n\u003cdd\u003eList of valid ciphers to use (eg,\n\u0022RC4-MD5:RC4-SHA:AES128-SHA:AES256-SHA:HIGH:!DSS:!aNULL\u0022\nor you can leave it as NULL to get \u0022DEFAULT\u0022\n\u003cdt\u003e\u003cb\u003egid\u003c/b\u003e\n\u003cdd\u003egroup id to change to after setting listen socket, or -1.\n\u003cdt\u003e\u003cb\u003euid\u003c/b\u003e\n\u003cdd\u003euser id to change to after setting listen socket, or -1.\n\u003cdt\u003e\u003cb\u003eoptions\u003c/b\u003e\n\u003cdd\u003e0, or LWS_SERVER_OPTION_DEFEAT_CLIENT_MASK\n\u003cdt\u003e\u003cb\u003euser\u003c/b\u003e\n\u003cdd\u003eoptional user pointer that can be recovered via the context\npointer using libwebsocket_context_user\n\u003cdt\u003e\u003cb\u003eka_time\u003c/b\u003e\n\u003cdd\u003e0 for no keepalive, otherwise apply this keepalive timeout to\nall libwebsocket sockets, client or server\n\u003cdt\u003e\u003cb\u003eka_probes\u003c/b\u003e\n\u003cdd\u003eif ka_time was nonzero, after the timeout expires how many\ntimes to try to get a response from the peer before giving up\nand killing the connection\n\u003cdt\u003e\u003cb\u003eka_interval\u003c/b\u003e\n\u003cdd\u003eif ka_time was nonzero, how long to wait before each ka_probes\nattempt\n\u003c/dl\u003e\n\u003chr\u003e\n","s":{"c":1752653891,"u": 1536}} ],"g": 13010,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}