{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"en-US,en;q\u003d0.5", "gen_ut":1594304395, "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", "oid":{ "oid": "1be6b4d075e63cbe9d4c4f9696a0a7647c475068", "alias": [ "refs/heads/_temp","refs/heads/master"]},"tree": [ { "name": "READMEs","mode": "16384", "size":0}, { "name": "cmake","mode": "16384", "size":0}, { "name": "contrib","mode": "16384", "size":0}, { "name": "doc-assets","mode": "16384", "size":0}, { "name": "include","mode": "16384", "size":0}, { "name": "lib","mode": "16384", "size":0}, { "name": "lwsws","mode": "16384", "size":0}, { "name": "minimal-examples","mode": "16384", "size":0}, { "name": "plugin-standalone","mode": "16384", "size":0}, { "name": "plugins","mode": "16384", "size":0}, { "name": "scripts","mode": "16384", "size":0}, { "name": "test-apps","mode": "16384", "size":0}, { "name": "win32port","mode": "16384", "size":0}, { "name": ".gitignore","mode": "33188", "size":778}, { "name": ".mailmap","mode": "33188", "size":103}, { "name": ".sai.json","mode": "33188", "size":9529}, { "name": "CMakeLists-implied-options.txt","mode": "33188", "size":9104}, { "name": "CMakeLists.txt","mode": "33188", "size":35366}, { "name": "Kconfig","mode": "33188", "size":857}, { "name": "LICENSE","mode": "33188", "size":2585}, { "name": "Makefile.projbuild","mode": "33188", "size":54}, { "name": "README.md","mode": "33188", "size":17733}, { "name": "bug_report.md","mode": "33188", "size":2120}, { "name": "changelog","mode": "33188", "size":23415}, { "name": "component.mk","mode": "33188", "size":1659}, { "name": "libwebsockets.dox","mode": "33188", "size":14433}],"s":{"c":1594304395,"u": 1317}} ,{"schema":"libjg2-1", "cid":"cd05ac38747b5c692642223082bda1e3", "oid":{ "oid": "1be6b4d075e63cbe9d4c4f9696a0a7647c475068", "alias": [ "refs/heads/_temp","refs/heads/master"]},"blobname": "README.md", "blob": "[](https://libwebsockets.org/git/libwebsockets) [](https://scan.coverity.com/projects/3576) [](https://bestpractices.coreinfrastructure.org/projects/2266) [](https://www.codacy.com/app/lws-team/libwebsockets?utm_source\u003dgithub.com\u0026amp;utm_medium\u003dreferral\u0026amp;utm_content\u003dwarmcat/libwebsockets\u0026amp;utm_campaign\u003dBadge_Grade) [](https://lgtm.com/projects/g/warmcat/libwebsockets/alerts/) [](https://lgtm.com/projects/g/warmcat/libwebsockets/context:cpp) [](https://lgtm.com/projects/g/warmcat/libwebsockets/context:javascript)\n\n# Libwebsockets\n\nLibwebsockets is a simple-to-use, pure C library providing client and server\nfor **http/1**, **http/2**, **websockets**, **MQTT** and other protocols in a security-minded,\nlightweight, configurable, scalable and flexible way. It's easy to build and\ncross-build via cmake and is suitable for tasks from embedded RTOS through mass\ncloud serving.\n\n[80 independent minimal examples](https://libwebsockets.org/git/libwebsockets/tree/minimal-examples) for\nvarious scenarios, CC0-licensed (public domain) for cut-and-paste, allow you to get started quickly.\n\n\n\nNews\n----\n\n## v4.0 is released\n\nUsers wanting a stable branch should follow v4.0-stable to get the most stable version\nat any given time.\n\nSee the [changelog](https://libwebsockets.org/git/libwebsockets/tree/changelog) for\ninformation on the huge amount of new features in this release, and additional information\nbelow.\n\n```\n - NEW: Lws is now under the MIT license, see ./LICENSE for details\n \n - NEW: GLIB native event loop support, lws + gtk example\n\n - NEW: native lws MQTT client... supports client stream binding like h2 when\n multiple logical connections are going to the same endpoint over MQTT, they\n transparently and independently share the one connection + tls tunnel\n \n - NEW: \u0022Secure Streams\u0022... if you are making a device with client connections\n to the internet or cloud, this allows separation of the communications\n policy (endpoints, tls cert validation, protocols, etc) from the code, with\n the goal you can combine streams, change protocols and cloud provision, and\n reflect that in the device's JSON policy document without having to change\n any code.\n\n - NEW: lws_system: New lightweight and efficient Asynchronous DNS resolver\n implementation for both A and AAAA records, supports recursive (without\n recursion in code) lookups, caching, and getaddrinfo() compatible results\n scheme (from cache directly without per-consumer allocation). Able to\n perform DNS lookups without introducing latency in the event loop.\n\n - NEW: lws_system: ntpclient implementation with interface for setting system\n time via lws_system ops\n \n - NEW: lws_system: dhcpclient implementation\n \n - NEW: Connection validity tracking, autoproduce PING/PONG for protocols that\n support it if not informed that the connection has passed data in both\n directions recently enough\n\n - NEW: lws_retry: standardized exponential backoff and retry timing based\n around backoff table and lws_sul\n\n - NEW: there are official public helpers for unaligned de/serialization of all\n common types, see eh, lws_ser_wu16be() in include/libwebsockets/lws-misc.h\n\n - NEW: lws_tls_client_vhost_extra_cert_mem() api allows attaching extra certs\n to a client vhost from DER in memory\n \n - NEW: lws_system: generic blobs support passing auth tokens, per-connection\n client certs etc from platform into lws\n\n - NEW: public helpers to consume and produce ipv4/6 addresses in a clean way,\n along with lws_sockaddr46 type now public. See eg, lws_sockaddr46-based\n lws_sa46_parse_numeric_address(), lws_write_numeric_address()\n in include/libwebsockets/lws-network-helper.h\n\n - Improved client redirect handling, h2 compatibility\n \n - NEW: lwsac: additional features for constant folding support (strings that\n already are in the lwsac can be pointed to without copying again), backfill\n (look for gaps in previous chunks that could take a new use size), and\n lwsac_extend() so last use() can attempt to use more unallocated chunk space\n\n - NEW: lws_humanize: apis for reporting scalar quanties like 1234 as \u00221.234KB\u0022\n with the scaled symbol strings passed in by caller\n\n - NEW: freertos: support lws_cancel_service() by using UDP pair bound to lo,\n since it doesn't have logical pipes\n\n - NEW: \u0022esp32\u0022 plat, which implemented freertos plat compatibility on esp32, is\n renamed to \u0022freertos\u0022 plat, targeting esp32 and other freertos platforms\n\n - NEW: base64 has an additional api supporting stateful decode, where the input\n is not all in the same place at the same time and can be processed\n incrementally\n\n - NEW: lws ws proxy: support RFC8441\n \n - NEW: lws_spawn_piped apis: generic support for vforking a process with child\n wsis attached to its stdin, stdout and stderr via pipes. When processes are\n reaped, a specified callback is triggered. Currently Linux + OSX.\n \n - NEW: lws_fsmount apis: Linux-only overlayfs mount and unmount management for\n aggregating read-only layers with disposable, changeable upper layer fs\n\n - Improvements for RTOS / small build case bring the footprint of lws v4 below\n that of v3.1 on ARM \n \n - lws_tokenize: flag specifying # should mark rest of line as comment\n\n - NEW: minimal example for integrating libasound / alsa via raw file\n\n - lws_struct: sqlite and json / lejp translation now usable\n\n\n```\n\n## Introducing Secure Streams client support\n\nSecure Streams is an optional layer above lws (`-DLWS_WITH_SECURE_STREAMS\u003d1`) that\nseparates connectivity policy into a JSON document, which can be part of the\nfirmware or fetched at boot time.\n\nCode no longer deals with details like endpoint specification or tls cert stack used\nto validate the remote server, it's all specified in JSON, eg, see\n[this example](https://warmcat.com/policy/minimal-proxy.json). Even the protocol to use to talk to the\nserver, between h1, h2, ws or MQTT, is specified in the policy JSON and the code\nitself just deals with payloads and optionally metadata, making it possible to\nswitch endpoints, update certs and even switch communication protocols by just\nediting the JSON policy and leaving the code alone.\n\nLogical Secure Stream connections outlive any underlying lws connection, and support\n\u0022nailed-up\u0022 connection reacquisition and exponential backoff management.\n\nSee [./lib/secure-streams/README.md](https://libwebsockets.org/git/libwebsockets/tree/lib/secure-streams/README.md) and the related minimal examples\nfor more details.\n\n## mqtt client support\n\nIf you enable `-DLWS_ROLE_MQTT\u003d1`, lws can now support QoS0 and QoS1 MQTT client\nconnections. See the examples at ./minimal-examples/mqtt-client\n\n## libglib native event loop support\n\nglib's event loop joins libuv, libevent and libev support in lws for both the\n`lws_context` creating and owning the loop object for its lifetime, and for\nan already-existing \u0022foreign loop\u0022 where the `lws_context` is created, attaches,\ndetaches, and is destroyed without affecting the loop.\n\nThis allows direct, lock-free integration of lws functionality with, eg, a GTK app's\nexisting `GMainLoop` / glib `g_main_loop`. Just select `-DLWS_WITH_GLIB\u003d1` at cmake\ntime to enable. The -eventlib minimal examples also support --glib option to\nselect using the glib loop at runtime.\n\nThere's also a gtk example that is built if lws cmake has `-DLWS_WITH_GTK\u003d1`.\n\n## `lws_system` helper for attaching code to a single event loop from another thread\n\n`lws_system` ops struct now has a member that enables other threads (in the\nsame process) to request a callback they define from the lws event loop thread\ncontext as soon as possible. From here, in the event loop thread context,\nthey can set up their lws functionality before returning and letting it\noperate wholly from the lws event loop. The original thread calling the\napi to request the callback returns immediately.\n\n## Improvements on tx credit\n\nH2 clients and servers can now modulate RX flow control on streams precisely,\nie, define the size of the first incoming data and hand out more tx credit\nat timing of its choosing to throttle or completely quench the remote server\nsending as it likes.\n\nThe only RFC-compatible way to acheive this is set the initial tx credit to\n0 and set it explicitly when sending the headers... client code can elect to\ndo this rather than automatically manage the credit by setting a new flag\nLCCSCF_H2_MANUAL_RXFLOW and indicating the initial tx credit for that stream\nin client connection info member manual_initial_tx_credit. A new public api\nlws_wsi_tx_credit() allows dynamic get and add to local and estimated remote\npeer credit for a connection. This api can be used without knowing if the\nunderlying connection is h2 or not.\n\n## `lws_system`: DHCP client\n\nDHCP client is now another network service that can be integrated into lws, with\n`LWS_WITH_SYS_DHCP_CLIENT` at CMake. When enabled, the `lws_system` state\nis held at `DHCP` until at least one registered network interface acquires a\nusable set of DHCP information including ip, subnet mask, router / gateway\naddress and at least one DNS server.\n\nSee the [api-test-dhcp](https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/api-tests/api-test-dhcpc) Minimal Example for how to use.\n\n## UDP integration with `lws_retry`\n\nUDP support in lws has new helper that allow `lws_retry` to be applied for retry,\nand the ability to synthesize rx and tx udp packetloss systemwide to confirm\nretry strategies. Since multiple transactions may be in flight on one UDP\nsocket, the support relies on an `lws_sul` in the transaction object to manage\nthe transaction retries individually.\n\nSee `READMEs/README.udp.md` for details.\n\n## `lws_system`: system state and notification handlers\n\nLws now has the concept of systemwide state held in the context... this is to\nmanage that there may be multiple steps that need the network before it's possible\nfor the user code to operate normally. The steps defined are\n\n`CONTEXT_CREATED`, `INITIALIZED`, `IFACE_COLDPLUG`, `DHCP`, `TIME_VALID`, `POLICY_VALID`,\n`REGISTERED`, `AUTH1`, `AUTH2`, `OPERATIONAL` and `POLICY_INVALID`. OPERATIONAL is the\nstate where user code can run normally.\n\nUser and other parts of lws can hook notifier callbacks to receive and be able to\nveto system state changes, either definitively or because they have been triggered\nto perform a step asynchronously and will move the state on themselves when it\ncompletes.\n\nBy default just after context creation, lws attempts to move straight to OPERATIONAL.\nIf no notifier interecepts it, it will succeed to do that and operate in a\nbackwards-compatible way. Enabling various features like lws ntpclient also enable\nnotifiers that hold progress at the related state until their operation completes\nsuccessfully, eg, not able to enter `TIME_VALID` until ntpclient has the time.\n\nSee `READMEs/README.lws_system.md` for details.\n\n## `lws_system`: HAL ops struct\n\nLws allows you to define a standardized ops struct at context creation time so your\nuser code can get various information like device serial number without embedding\nsystem-specific code throughout the user code. It can also perform some generic\nfunctions like requesting a device reboot.\n\nSee `READMEs/README.lws_system.md` for details.\n\n## `lws_system`: ntpclient\n\nOptional lws system service enabled by cmake `-DLWS_WITH_SYS_NTPCLIENT` intercepts\nthe `lws_system` `TIME_VALID` state and performs ntpclient to get the date and time\nbefore entering `TIME_VALID`. This allows user code to validate tls certificates\ncorrectly knowing the current date and time by the time it reached OPERATIONAL.\n\n## Connection Validity tracking\n\nLws now allows you to apply a policy for how long a network connection may go\nwithout seeing something on it that confirms it's still valid in the sense of\npassing traffic cohernetly both ways. There's a global policy in the context\nwhich defaults to 5m before it produces a PING if possible, and 5m10 before\nthe connection will be hung up, user code can override this in the context,\nvhost (for server) and client connection info (for client).\n\nAn api `lws_validity_confirmed(wsi)` is provided so user code can indicate\nthat it observed traffic that must mean the connection is passing traffic in\nboth directions to and from the peer. In the absence of these confirmations\nlws will generate PINGs and take PONGs as the indication of validity.\n\n## `lws_system`: Async DNS support\n\nMaster now provides optional Asynchronous (ie, nonblocking) recursive DNS resolving.\nEnable with `-DLWS_WITH_SYS_ASYNC_DNS\u003d1` at cmake. This provides a quite\nsophisticated ipv4 + ipv6 capable resolver that autodetects the dns server on\nseveral platforms and operates a UDP socket to its port 53 to produce and parse DNS\npackets from the event loop. And of course, it's extremely compact.\n\nIt broadly follows the getaddrinfo style api, but instead of creating the results\non the heap for each caller, it caches a single result according to the TTL and\nthen provides refcounted const pointers to the cached result to callers. While\nthere are references on the cached result it can't be reaped.\n\nSee `READMEs/README.async-dns.md` for detailed information on how it works, along\nwith `api-tests/api-test-async-dns` minimal example.\n\n## Detailed Latency\n\nYou can now opt to measure and store us-resolution statistics on effective\nlatencies for client operations, and easily spool them to a file in a\nformat suitable for gnuplot, or handle in your own callback. Enable\n`-DLWS_WITH_DETAILED_LATENCY\u003d1` in cmake to build it into lws.\n\nIf you are concerned about operation latency or potential blocking from\nuser code, or behaviour under load, or latency variability on specific\nplatforms, you can get real numbers on your platform using this.\n\nTimings for all aspects of events on connections are recorded, including\nthe time needed for name resolution, setting up the connection, tls\nnegotiation on both client and server sides, and each read and write.\n\nSee `READMEs/README.detailed-latency.md` for how to use it.\n\n## Client connection logic rewrite\n\nLws master now makes much better use of the DNS results for ipv4 and ipv6... it\nwill iterate through them automatically making the best use it can of what's\nprovided and attempting new connections for each potentially usable one in turn\nbefore giving up on the whole client connection attempt.\n\nIf ipv6 is disabled at cmake it can only use A / ipv4 records, but if ipv6 is\nenabled, it tries both; if only ipv6 is enabled it promotes ipv4 to\n::ffff:1.2.3.4 IPv4-in-IPv6 addresses.\n\n## New network helpers for ipv4 and ipv6\n\nAn internal union `lws_sockaddr46` that combines `struct sockaddr_in` and\n`struct sockaddr_in6` is now public, and there are helpers that can parse (using\n`lws_tokenize`) any valid numeric representation for ipv4 and ipv6 either\ninto byte arrays and lengths, or directly to and from `lws_sockaddr46`.\n\n## h2 long poll support\n\nLws now supports the convention that half-closing an h2 http stream may make\nthe stream 'immortal', in terms of not being bound by normal timeouts. For\nthe client side, there's an api that can be applied to the client stream to\nmake it transition to this \u0022read-only\u0022 long poll mode.\n\nSee `READMEs/README.h2-long-poll.md` for full details, including how to test\nit with the minimal examples.\n\n## h1 client parser improvements\n\nH1 is not so simple to parse because the header length is not known until it\nhas been fully parsed. The next header, or http body may be directly coalesced\nwith the header as well. Lws has supported bulk h1 parsing from a buffer for a\nlong time, but on clientside due to interactions with http proxying it had\nbeen stuck parsing the header bytewise out of the tls buffer. In master,\neverything now bulk parses from a buffer and uses a buflist to pass leftovers\nthrough the event loop cleanly.\n\n## `lws_sul` time refactor\n\nJust before v3.2 there was a big refactor about how lws handles time. It now\nexplicitly schedules anything that may happen in the future on a single, sorted\nlinked-list, at us resolution. When entering a poll wait (or returning to an\nevent lib loop) it checks the interval between now and the earliest event on the\nlist to figure out how long to wait if there are no network events. For the\nevent loop case, it sets a native event lib timer to enforce it.\n\nSee `READMEs/README.lws_sul.md` for more details and a handy api where you can\nschedule your own arbitrary callbacks using this system.\n\n## Master is now MIT-licensed\n\nLibwebsockets master is now under the MIT license. See ./LICENSE.\n\n## Support\n\nThis is the libwebsockets C library for lightweight websocket clients and\nservers. For support, visit\n\n https://libwebsockets.org\n\nand consider joining the project mailing list at\n\n https://libwebsockets.org/mailman/listinfo/libwebsockets\n\nYou can get the latest version of the library from git:\n\n- https://libwebsockets.org/git\n\nDoxygen API docs for master: https://libwebsockets.org/lws-api-doc-master/html/index.html\n\n","s":{"c":1594304395,"u": 1808}} ],"g": 7759,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":1, "sat":0, "lfc": "0000"}