AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 29 Pull Requests Releases Wiki Activity

[*] amend another comment: AuNetResolver.Unix.cpp

Browse Source
This commit is contained in:
Reece Wilson 2024-11-20 23:48:33 +00:00
parent 71a008dc49
commit 08a3574fca
1 changed files with 63 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
Source/IO/Net/AuNetResolver.Unix.cpp
View File

@ -488,70 +488,75 @@ namespace Aurora::IO::Net
#if defined(AURORA_HAS_GLIBC_RESOLVER_PROXY_STUBS)
// Our name-resolution signaling options for glibc / GAHHNUUU-EEB-SNCCEE are:
// 1) [gahnuu IO] Wait forever for glibc to spawn a thread with their own pthreads; or
// 2) [gahnuu IO] Use their interface for sending a signal instead. Noting that Linux-likes can
// handle sigev_notify_thread_id notifications, via a signalqueue and sigevent field.
// 3) [posix] Just call getaddrinfo in a thread pool ourselves (or just not and create a thread each time. same for winxp.)
//
// Noting that GAHHNUUU-SNCCEE resolv NSS modules are the only hope of standard Linux-like applications of getting DoH,
// alternative plugin-based DNS services, and cached results on their system.
// musl and other embedded drivers are hopeless.
//
// No matter the POSIX implementation type, it'll match WinXP - 11 with the Windows Name Resolution stack under Windows Sockets 2.
// Canceling? Windows XP, Vista and 7 doesn't even have GetAddrInfoExCancel. glibc says, na, not yet because its not in posix yet. libresolv could, but using libresolv this early would suck.
// Canceling, but can we? Ok, we can sort of cancel on all platforms. On old Windows, we could force term a thread, but we dont, and idk if we should. Windows8+ can cancel, no matter what.
// On other POSIX systems, we could force term a thread, but we dont, and idk if we should.
// On Android, we might have android_res_cancel / android_getaddrinfofornetwork. We might not. We don't have android support in this file yet, or at all for that matter.
// On glibc, we have gai_cancel, that might work, might not.
// On glibc, posix, and Windows 7-XP, we will probably find ourselves spinning in a yield loop until the DNS request has been resolved or properly canceled.
// this is fine for desktop clients cleaning up a subsystem. Might not be so great for mobiles or unstable connections.
// Caching? Yea probably.
// IPv6? Yea, if the platform vendor supports it.
// User config? Yea, if the platform vendor supports it.
// Native async? Maybe a thread pool if we're lucky. Otherwise we can just spawn a thread and get the same results
//
// On the plus side, libc abstraction of getaddrinfo in async form (glibc) or our own hack of spawn a thread (hello ::StartStandard),
// we always guarantee the system has a good async getaddrinfo;
// the interface we just established has the ability for the user to configure it; and
// the system will probably be handling our DNS caching in a global platform standard.
//
// On alternative libcs and platforms:
// >Musl will just have to write a good internal DNS library with plugin routing, caching, and/or async. Not my problem.
// >Android has its' own DNS stack based on ISCs lib, with caching. No async expected.
// >XNU has its' own dns stack based on ISCs lib (or at least they did. old libresolv.). No async expected.
// We can expect forks of ISCs library with IPv6 support with cached entries, somewhere; or similar features under getaddrinfo.
//
// On Linux:
// >Most Linux users will be using their own local version of glibc.
// >DNS can be configured how the user wants.
// >systemd-resolv and friends should take care of system local cache conctrol.
// >and yes that does mean implicit integration with systemd
// (systemd-resolve via the NSS module 'nss-resolve' gets served under our users of getaddrinfo [also incl the call under glibc aio] ).
//
// We assume best case glibc/signal on linux glibc targets.
// glibcs async resolve just uses getaddrinfo under the hood, with an actual threadpool. the only question which is faster: pthread spawn or a linux sigqueue?
// Knowing we can jut rely on getaddrinfo no matter what, we just spawn a detached thread, if we need async on other platforms with the same expected feature set.
// getaddrinfo may suck, but it's the only minimum interface we can provide and expect.
// > Most Linux users will be using their own local version of glibc.
// > DNS can be configured however the user wants using standard Linuxy glibc stuff
// > Enterprise resolution and such is governed by glibc modules.
// > systemd-resolv and friends should take care of system local cache control
// > ...and yes that does mean implicit integration with systemd
// (systemd-resolve via the NSS module 'nss-resolve' gets served under our users of getaddrinfo [also including the blocking call under glibcs' "aio" ] ).
// > The only noteworthy DoH and signed nameserver resolution modules come under the umbrella of glibc modules
// > All of these items worthy of note all sit underneath one blocking getaddrinfo interface.
//
// On alternative libcs and platforms:
// > Musl will just have to write a good internal DNS library with plugin routing, caching, and/or async. Not my problem.
// > Android has its' own DNS stack based on ISCs lib, with caching. ** No async expected. **
// > XNU has its' own dns stack based on ISCs lib (or at least they did. old libresolv.). ** No async expected. **
//
// So far as providing a common async abstraction for the expected platform provider is concerned, this should be the right thing.
//
// We could always build our own resolver on top of this and:
// >platform("k.root-servers.net") ?? (EU RIPE NCC, headquartered in Amsterdam. probably won't care for german or american lower level judges having a moment. )
// >193.0.14.129 ?? 2001:7fd::1 ??
// >platform("g.root-servers.net") ?? (US DoD glow plant. the good thing: EU plebs and activists be damned, they will not touch DNS results without a vaild US federal court order and 15 layers of bureaucracy. bc DOD feds.)
// >192.112.36.4 ?? 2001:500:12::d0d
// > platform("k.root-servers.net") ?? (EU RIPE NCC, headquartered in Amsterdam. probably won't care for german or american lower level judges having a moment. )
// > 193.0.14.129 ?? 2001:7fd::1 ??
// > platform("g.root-servers.net") ?? (US DoD glow plant. the good thing: EU plebs and activists be damned, they will not touch DNS results without a vaild US federal court order and 15 layers of bureaucracy. bc DOD feds.)
// > 192.112.36.4 ?? 2001:500:12::d0d
// for the most globally standard, consistent, and censorship-free results.
// The downsides:
// No caching (TODO: registry with sqlite?)
// Probably wont be privacy friendly.
// Not all servers with be authenticated or encrypted.
// You could implement a nonstandard DNS server that's always recursive, cached, and encrypted, *but* then you probably need to worry about user consent and extra costs.
// > No caching (TODO: registry with sqlite?)
// > Probably wont respect the users' privacy
// > Not all servers will be authenticated and/or encrypted
// > Should you implement a nonstandard DNS server that's always recursive, cached, and encrypted, you then you need to worry about user consent and extra hosting costs
//
// Alternatively, we could use c-ares. That could provide a good extended resolver and provides cancelation. It's C89, run on Windows, runs on pretty much anything. It's completely nonblocking.
// Problem is, it doesn't get hooked by the users preferences properly. The caching sucks. It's not really the system resolver. We should use use this if we were porting to an embedded or a generic platform.
// freertos, freebsd, console ports, and MAYBE physically-portable musl targets are the only few platforms that can begin to justify this.
// [lowprio] Might pull it in for everybody to use later. We don't really need it until there's a demand for SRV & TXT & MX DNS resolution. It's a valid request.
// Alternatively, we could use c-ares.
// c-ares could provide a good extended resolver and provides cancelation. It's C89, runs on Windows, and runs on pretty much anything for that matter. It's completely nonblocking - unlike the pools abusing BIO getaddrinfo.
// The problems are:
// > It doesn't get hooked by the users preferences properly
// > The caching sucks (what caching?)
// > It's not really the system resolver
// > how do users extend this with modern resolution plugins?
// > how do they add enterprise domain nameservers?
// > how do they purge their cache?
// We should use c-ares, if we were to port our code to an embedded or a generic platform. freertos, freebsd, gaming console ports, and MAYBE physically-portable musl targets are the only few platforms that can begin to justify this.
//
// As for using glibc thread pool, our name-resolution completion signaling options for glibc / GAHHNUUU-EIB-SNCCEE are:
// 1) [gahnuu IO] Wait forever for glibc to spawn a thread with their own pthreads just to call a completion routine; or
// 2) [gahnuu IO] Use their interface for sending a signal instead. Noting that Linux-likes can handle sigev_notify_thread_id notifications, via a signalqueue and sigevent field.
// 3) [posix] Just call getaddrinfo in a thread pool ourselves (or just not and create a thread each time. this same laziness is shared for Windows XP - 7.)
// Glibcs async resolver uses getaddrinfo under the hood, with an actual half-arsed threadpool without NIO. The only question which is faster: pthread spawn or a linux sigqueue?
//
// No matter the POSIX getaddrinfo implementation type, the constraints match WinXP through 11, with the Windows Name Resolution stack under Windows Sockets 2.
// Canceling? Windows XP, Vista and 7 doesn't even have GetAddrInfoExCancel ** No async expected. **. glibc says, na, not yet because its not in posix yet. libresolv could, but using libresolv this early would suck.
// Canceling, but can we?
// Ok, we can sort of cancel on all platforms.
// On old Windows, we could force term a thread, but we dont, and idk if we should. Windows8+ can cancel, no matter what.
// On other POSIX systems, we could force term a thread, but we dont, and idk if we should.
// On Android, we might have android_res_cancel / android_getaddrinfofornetwork. We might not. We don't have android support in this file yet, or at all for that matter.
// On glibc, we have gai_cancel, that might work, might not.
// On glibc, posix, and Windows 7-XP, we will probably find ourselves spinning in a yield loop until the DNS request has been resolved or properly canceled.
// This is fine for desktop clients cleaning up a subsystem. Might not be so great for mobiles or unstable connections.
// If we really wanted to be autistic about this, we could just lie about the cancellation status, and let the platforms broken resolver waste resources in the background.
//
// Caching? Yea, probably.
//
// IPv6? Yea, if the platform vendor supports it.
//
// User config? Yea, if the platform vendor supports it.
//
// Native async? Maybe a thread pool, if we're lucky, otherwise we can just spawn a getaddrinfo-calling thread and get consistent cross-platform results. See: ** No async expected. **
//
// Knowing we can jut rely on getaddrinfo no matter what, we just spawn a detached thread under each platform specific implementation, should we not have a viable platform native async interface available.
// getaddrinfo may suck, but it's the only minimum interface we can expect and provide abstractions for.
// It's the first target of interest for vendors trying to roll their own resolver, and it's the only thing we can rely on.
//
// [update:lowprio] Might pull in c-ares for everybody to use later. We don't really need it until there's a demand for SRV & TXT & MX DNS resolution. It's a valid request.
static void Annoying(int)
{
// We probably do not need SA_NODEFER or iterator protection.