mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-23 00:00:06 +01:00
c591e1adfc
This adds the option to have lws do its own dns resolution on the event loop, without blocking. Existing implementations get the name resolution done by the libc, which is blocking. In the case you are opening client connections but need to carefully manage latency, another connection opening and doing the name resolution becomes a big problem. Currently it supports - ipv4 / A records - ipv6 / AAAA records - ipv4-over-ipv6 ::ffff:1.2.3.4 A record promotion for ipv6 - only one server supported over UDP :53 - nameserver discovery on linux, windows, freertos It also has some nice advantages - lws-style paranoid response parsing - random unique tid generation to increase difficulty of poisoning - it's really integrated with the lws event loop, it does not spawn threads or use the libc resolver, and of course no blocking at all - platform-specific server address capturing (from /etc/resolv.conf on linux, windows apis on windows) - it has LRU caching - piggybacking (multiple requests before the first completes go on a list on the first request, not spawn multiple requests) - observes TTL in cache - TTL and timeout use lws_sul timers on the event loop - ipv6 pieces only built if cmake LWS_IPV6 enabled
76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
# Asynchronous DNS
|
|
|
|
## Introduction
|
|
|
|
Lws now features optional asynchronous, ie, nonblocking DNS
|
|
resolution done on the event loop, enable `-DLWS_WITH_SYS_ASYNC_DNS=1`
|
|
at cmake to build it in.
|
|
|
|
## Description
|
|
|
|
The default libc name resolution is via libc `getaddrinfo()`, which is
|
|
blocking, possibly for quite long periods (seconds). If you are
|
|
taking care about latency, but want to create outgoing connections,
|
|
you can't tolerate this exception from the rule that everything in
|
|
lws is nonblocking.
|
|
|
|
Lws' asynchronous DNS resolver creates a caching name resolver
|
|
that directly queries the configured nameserver itself over UDP,
|
|
from the event loop.
|
|
|
|
It supports both ipv4 / A records and ipv6 / AAAA records (see later
|
|
for a description about how). One server supported over UDP :53,
|
|
and the nameserver is autodicovered on linux, windows, and freertos.
|
|
|
|
Other features
|
|
|
|
- lws-style paranoid response parsing
|
|
- random unique tid generation to increase difficulty of poisoning
|
|
- it's really integrated with the lws event loop, it does not spawn
|
|
threads or use the libc resolver, and of course no blocking at all
|
|
- platform-specific server address capturing (from /etc/resolv.conf
|
|
on linux, windows apis on windows)
|
|
- LRU caching
|
|
- piggybacking (multiple requests before the first completes go on
|
|
a list on the first request, not spawn multiple requests)
|
|
- observes TTL in cache
|
|
- TTL and timeout use `lws_sul` timers on the event loop
|
|
- ipv6 pieces only built if cmake `LWS_IPV6` enabled
|
|
|
|
## Api
|
|
|
|
If enabled at cmake, the async DNS implementation is used automatically
|
|
for lws client connections. It's also possible to call it directly, see
|
|
the api-test-async-dns example for how.
|
|
|
|
The Api follows that of `getaddrinfo()` but results are not created on
|
|
the heap. Instead a single, const cached copy of the addrinfo struct
|
|
chain is reference-counted, with `lws_async_dns_freeaddrinfo()` provided
|
|
to deduct from the reference count. Cached items with a nonzero
|
|
reference count can't be destroyed from the cache, so it's safe to keep
|
|
a pointer to the results and iterate through them.
|
|
|
|
## Dealing with IPv4 and IPv6
|
|
|
|
DNS is a very old standard that has some quirks... one of them is that
|
|
multiple queries are not supported in one packet, even though the protocol
|
|
suggests it is. This creates problems on ipv6 enabled systems, where
|
|
it may prefer to have AAAA results, but the server may only have A records.
|
|
|
|
To square the circle, for ipv4 only systems (`LWS_IPV6=0`) the resolver
|
|
requests only A records. For ipv6-capable systems, it always requests
|
|
first A and then immediately afterwards AAAA records.
|
|
|
|
To simplify the implementation, the tid b0 is used to differentiate
|
|
between A (b0 = 0) and AAAA (b0 = 1) requests and responses using the
|
|
same query body.
|
|
|
|
The first response to come back is parsed, and a cache entry made...
|
|
it leaves a note in the query about the address of the last `struct addrinfo`
|
|
record. When the second response comes, a second allocation is made,
|
|
but not added to the logical cache... instead it's chained on to the
|
|
first cache entry and the `struct addrinfo` linked-list from the
|
|
first cache entry is extended into the second one. At the time the
|
|
second result arrives, the query is destroyed and the cached results
|
|
provided on the result callback.
|
|
|