On 21. 10. 24 11:53, Lennart Poettering
wrote:
Okay. It might be better than D-Bus, but having to make separate connections for every single resolution is still a bit wasteful. If we can keep some context between two resolutions, just a single stream connection would be enough. If raw stream/TCP DNS is used, it can deliver random ordered responses over single connection. That seems even better option. Just use an unix socket for raw DNS. Of course additional resolution via Varlink would be still possible, but I would not propose them as a primary way.On So, 20.10.24 18:33, Petr Menšík (pemensik@xxxxxxxxxx) wrote:From what I read about Varlink.org, it requires answers to be delivered in the same order in which queries has came.That's quite a misunderstanding. Varlink takes benefit of the fact that AF_UNIX connections are cheap, and it optimizes for that (i.e. there is no handshake protocol or so, like in D-Bus). i.e. if you want 7 DNS resolutions done at the same time you just create 7 connections in parallel, and they run asynchronously and finish whenever they are ready.
Agreed. If D-Bus requires this, then it is not a good choice for fast (primary) name resolution. Maybe for getting configuration status or updates. Not a high traffic because of ordering problem. Slowest responding service would slow all other services when its buffers get full. That is unfortunate.This part actually makes Varlink a lot more efficient, because it removes the "global ordering" requirement that D-Bus enforces: on D-Bus any two messages sent by two clients must be delivered in the same order everywhere, even if unrelated. This inability to reorder stuff is expensive, but Varlink never had that: the connections are truly independent, and while there is ordering on each connection, there's no further ordering enforced, which means it's easy to process Varlink with thread pools and stuff, which is a mechanism D-Bus is pretty incompatible with, because of the global ordering thing.
My idea is that thread pools should be used only when a single thread cannot deliver enough processing power. IMO handling multiple connections would not speed up or simplify resolution process. Of course that *needs* to be possible, but it should not be a required feature.(Note that resolved does not use thread pools right now. But it still is a ton more efficient to talk to it via Varlink because the bottleneck that the multiplexed, singleton to the D-Bus broker is).
I think the primary choice should be to use existing libraries for working with DNS. Not translating DNS packet into json encoded object on Varlink. That creates a new protocol, hence "reinvents" DNS. The more different resource records you support this way, the more complex it will be. I think well designed C API could deliver the similar experience, even without JSON encapsulation. DNS libraries exists for every common language. I think systemd-resolved made a mistake to not re-use any and reimplemented everything from scratch. I would not recommend that to anyone, DNS is not as simple as it seems. Using the JSON library instead of the DNS is not a better solution IMO.Again. The Varlink interface in resolved right now delivers the raw DNS RR bytes to you if you want, but it has well-defined semantics on method calls and their time-outs that you do not have to reinvent.
Well DNS RRsets are tiny, even in a DNSSEC world. "raw" bytes are typically encoded in base64 in json, and that's what resolved does if you ask for the raw bytes. base64 is a bit wasteful, but it really does not matter at all for DNS data. Lennart -- Lennart Poettering, Berlin
Most of DNS RRsets are tiny. DNS can contain OPENPGPKEY records, which are not so tiny. It can contain also DNSKEYs. Especially those of a post quantum cryptography are rather large. Not something today's application is unable to process, but not tiny. Large DNS responses might be up to 64 kB, but sure, most of them are smaller than 1.2 kB. But mandatory base64 encoding and decoding can be avoided. If it can be avoided, then I think it should be.
Petr
-- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
