{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"en-US,en;q\u003d0.5", "gen_ut":1560964149, "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": "5462529bcc10060ef4b959b2181da335ed9a7f71", "alias": [ "refs/heads/master"]},"tree": [ { "name": "api-tests","mode": "16384", "size":0}, { "name": "client-server","mode": "16384", "size":0}, { "name": "crypto","mode": "16384", "size":0}, { "name": "dbus-client","mode": "16384", "size":0}, { "name": "dbus-server","mode": "16384", "size":0}, { "name": "http-client","mode": "16384", "size":0}, { "name": "http-server","mode": "16384", "size":0}, { "name": "raw","mode": "16384", "size":0}, { "name": "ws-client","mode": "16384", "size":0}, { "name": "ws-server","mode": "16384", "size":0}, { "name": "README.md","mode": "33188", "size":4011}, { "name": "selftests-library.sh","mode": "33261", "size":1877}, { "name": "selftests.sh","mode": "33261", "size":1392}],"s":{"c":1560946473,"u": 342}} ,{"schema":"libjg2-1", "cid":"302720fa4bac670f4347ebece2f19dbd", "oid":{ "oid": "5462529bcc10060ef4b959b2181da335ed9a7f71", "alias": [ "refs/heads/master"]},"blobname": "minimal-examples/README.md", "blob": "|name|demonstrates|\n---|---\nclient-server|Minimal examples providing client and server connections simultaneously\ncrypto|Minimal examples related to using lws crypto apis\ndbus-server|Minimal examples showing how to integrate DBUS into lws event loop\nhttp-client|Minimal examples providing an http client\nhttp-server|Minimal examples providing an http server\nraw|Minimal examples related to adopting raw file or socket descriptors into the event loop\nws-client|Minimal examples providing a ws client\nws-server|Minimal examples providing a ws server (and an http server)\n\n## FAQ\n\n### Getting started\n\nBuild and install lws itself first (note that after installing lws on \u005c*nix, you need to run `ldconfig` one time so the OS can learn about the new library. Lws installs in `/usr/local` by default, Debian / Ubuntu ldconfig knows to look there already, but Fedora / CentOS need you to add the line `/usr/local/lib` to `/etc/ld.so.conf` and run ldconfig)\n\nThen start with the simplest:\n\n`http-server/minimal-http-server`\n\n### Why are most of the sources split into a main C file file and a protocol file?\n\nLws supports three ways to implement the protocol callback code:\n\n - you can just add it all in the same source file\n\n - you can separate it as these examples do, and #include it\n into the main sources\n\n - you can build it as a standalone plugin that is discovered\n and loaded at runtime.\n\nThe way these examples are structured, you can easily also build\nthe protocol callback as a plugin just with a different\nCMakeLists.txt... see https://github.com/warmcat/libwebsockets/tree/master/plugin-standalone\nfor an example.\n\n### Why would we want the protocol as a plugin?\n\nYou will notice a lot of the main C code is the same boilerplate\nrepeated for each example. The actual interesting part is in\nthe protocol callback only.\n\nLws provides (-DLWS_WITH_LWSWS\u003d1) a generic lightweight server app called 'lwsws' that\ncan be configured by JSON. Combined with your protocol as a plugin,\nit means you don't actually have to make a special server \u0022app\u0022\npart, you can just use lwsws and pass per-vhost configuration\nfrom JSON into your protocol. (Of course in some cases you have\nan existing app you are bolting lws on to, then you don't care\nabout this for that particular case).\n\nBecause lwsws has no dependency on whatever your plugin does, it\ncan mix and match different protocols randomly without needing any code\nchanges. It reduces the size of the task to just writing the\ncode you care about in your protocol handler, and nothing else to write\nor maintain.\n\nLwsws supports advanced features like reload, where it starts a new server\ninstance with changed config or different plugins, while keeping the old\ninstance around until the last connection to it closes.\n\n### I get why there is a pss, but why is there a vhd?\n\nThe pss is instantiated per-connection. But there are almost always\nother variables that have a lifetime longer than a single connection.\n\nYou could make these variables \u0022filescope\u0022 one-time globals, but that\nmeans your protocol cannot instantiate multiple times.\n\nLws supports vhosts (virtual hosts), for example both https://warmcat.com\nand https://libwebsockets are running on the same lwsws instance on the\nsame server and same IP... each of these is a separate vhost.\n\nYour protocol may be enabled on multiple vhosts, each of these vhosts\nprovides a different vhd specific to the protocol instance on that\nvhost. For example many of the samples keep a linked-list head to\na list of live pss in the vhd... that means it's cleanly a list of\npss opened **on that vhost**. If another vhost has the protocol\nenabled, connections to that will point to a different vhd, and the\nlinked-list head on that vhd will only list connections to his vhost.\n\nThe example \u0022ws-server/minimal-ws-server-threads\u0022 demonstrates how to deliver\nexternal configuration data to a specific vhost + protocol\ncombination using code. In lwsws, this is simply a matter of setting\nthe desired JSON config.\n\n\n","s":{"c":1560946473,"u": 181}} ],"g": 557,"chitpc": 0,"ehitpc": 0, "indexed":0 }