Project homepage Mailing List  API Docs  Github Mirror 
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"en-US,en;q\u003d0.5", "gen_ut":1611402873, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"", "f":3, "items": [ { "schema":"libjg2-1", "oid":{ "oid": "dd17dfb99dcd998ff8d4f8e09374194add26f4ec", "alias": [ "refs/heads/main","refs/heads/master"]},"tree": [ { "name": "","mode": "33188", "size":4396}, { "name": "","mode": "33188", "size":2434}, { "name": "","mode": "33188", "size":6711}, { "name": "","mode": "33188", "size":26825}, { "name": "","mode": "33188", "size":3677}, { "name": "","mode": "33188", "size":911}, { "name": "","mode": "33188", "size":2069}, { "name": "","mode": "33188", "size":53649}, { "name": "","mode": "33188", "size":5950}, { "name": "","mode": "33188", "size":1144}, { "name": "","mode": "33188", "size":7884}, { "name": "","mode": "33188", "size":2304}, { "name": "","mode": "33188", "size":2310}, { "name": "","mode": "33188", "size":1917}, { "name": "","mode": "33188", "size":3325}, { "name": "","mode": "33188", "size":1812}, { "name": "","mode": "33188", "size":6663}, { "name": "","mode": "33188", "size":7305}, { "name": "","mode": "33188", "size":1650}, { "name": "","mode": "33188", "size":4371}, { "name": "","mode": "33188", "size":3823}, { "name": "","mode": "33188", "size":9001}, { "name": "","mode": "33188", "size":3368}, { "name": "","mode": "33188", "size":3913}, { "name": "","mode": "33188", "size":6430}, { "name": "","mode": "33188", "size":1554}, { "name": "","mode": "33188", "size":4366}, { "name": "","mode": "33188", "size":7848}, { "name": "","mode": "33188", "size":25145}, { "name": "","mode": "33188", "size":6081}, { "name": "","mode": "33188", "size":8128}, { "name": "","mode": "33188", "size":2144}, { "name": "","mode": "33188", "size":3033}, { "name": "","mode": "33188", "size":5795}, { "name": "","mode": "33188", "size":2087}, { "name": "","mode": "33188", "size":14872}, { "name": "","mode": "33188", "size":1778}, { "name": "","mode": "33188", "size":4558}, { "name": "","mode": "33188", "size":337}, { "name": "","mode": "33188", "size":1009}, { "name": "release-checklist","mode": "33188", "size":1100}],"s":{"c":1611396863,"u": 5018}} ,{"schema":"libjg2-1", "cid":"58e4ab5356ca7e08310498a5d8fcd489", "oid":{ "oid": "dd17dfb99dcd998ff8d4f8e09374194add26f4ec", "alias": [ "refs/heads/main","refs/heads/master"]},"blobname": "READMEs/", "blob": "# Asynchronous DNS\n\n## Introduction\n\nLws now features optional asynchronous, ie, nonblocking recursive DNS\nresolution done on the event loop, enable `-DLWS_WITH_SYS_ASYNC_DNS\u003d1`\nat cmake to build it in.\n\n## Description\n\nThe default libc name resolution is via libc `getaddrinfo()`, which is\nblocking, possibly for quite long periods (seconds). If you are\ntaking care about latency, but want to create outgoing connections,\nyou can't tolerate this exception from the rule that everything in\nlws is nonblocking.\n\nLws' asynchronous DNS resolver creates a caching name resolver\nthat directly queries the configured nameserver itself over UDP,\nfrom the event loop.\n\nIt supports both ipv4 / A records and ipv6 / AAAA records (see later\nfor a description about how). One server supported over UDP :53,\nand the nameserver is autodicovered on linux, windows, and freertos.\n \nOther features\n\n - lws-style paranoid response parsing\n - random unique tid generation to increase difficulty of poisoning\n - it's really integrated with the lws event loop, it does not spawn\n threads or use the libc resolver, and of course no blocking at all\n - platform-specific server address capturing (from /etc/resolv.conf\n on linux, windows apis on windows)\n - LRU caching\n - piggybacking (multiple requests before the first completes go on\n a list on the first request, not spawn multiple requests)\n - observes TTL in cache\n - TTL and timeout use `lws_sul` timers on the event loop\n - Uses CNAME resolution inside the same response if present, otherwise\n recurses to resolve the CNAME (up to 3 deep)\n - ipv6 pieces only built if cmake `LWS_IPV6` enabled\n\n## Api\n\nIf enabled at cmake, the async DNS implementation is used automatically\nfor lws client connections. It's also possible to call it directly, see\nthe api-test-async-dns example for how.\n\nThe Api follows that of `getaddrinfo()` but results are not created on\nthe heap. Instead a single, const cached copy of the addrinfo struct\nchain is reference-counted, with `lws_async_dns_freeaddrinfo()` provided\nto deduct from the reference count. Cached items with a nonzero\nreference count can't be destroyed from the cache, so it's safe to keep\na pointer to the results and iterate through them.\n\n## Dealing with IPv4 and IPv6\n\nDNS is a very old standard that has some quirks... one of them is that\nmultiple queries are not supported in one packet, even though the protocol\nsuggests it is. This creates problems on ipv6 enabled systems, where\nit may prefer to have AAAA results, but the server may only have A records.\n\nTo square the circle, for ipv4 only systems (`LWS_IPV6\u003d0`) the resolver\nrequests only A records. For ipv6-capable systems, it always requests\nfirst A and then immediately afterwards AAAA records.\n\nTo simplify the implementation, the tid b0 is used to differentiate\nbetween A (b0 \u003d 0) and AAAA (b0 \u003d 1) requests and responses using the\nsame query body.\n\nThe first response to come back is parsed, and a cache entry made...\nit leaves a note in the query about the address of the last `struct addrinfo`\nrecord. When the second response comes, a second allocation is made,\nbut not added to the logical cache... instead it's chained on to the\nfirst cache entry and the `struct addrinfo` linked-list from the\nfirst cache entry is extended into the second one. At the time the\nsecond result arrives, the query is destroyed and the cached results\nprovided on the result callback.\n\n## Recursion\n\nWhere CNAMEs are returned, DNS servers may take two approaches... if the\nCNAME is also resolved by the same server and so it knows what it should\nresolve to, it may provide the CNAME resolution in the same response\npacket.\n\nIn the case the CNAME is actually resolved by a different name server,\nthe server with the CNAME does not have the information to hand to also\nresolve the CNAME in the same response. So it just leaves it for the\nclient to sort out.\n\nThe lws implementation can deal with both of these, first it \u0022recurses\u0022\n(it does not recurse on the process stack but uses its own manual stack)\nto look for results in the same packet that told it about the CNAME. If\nthere are no results, it resets the query to look instead for the CNAME,\nand restarts it. It allows this to happen for 3 CNAME deep.\n\nAt the end, either way, the cached result is set using the original\nquery name and the results from the last CNAME in the chain.\n\n\n","s":{"c":1611396863,"u": 5280}} ],"g": 1057,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 0, "si": 0, "db":0, "di":0, "sat":0, "lfc": "7d0a"}