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. 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. (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 using the DNS protocol itself is highly problematic however, > > because the protocol is just so complex these days with multiple > > transports, and time-out/repeat behaviour that is just a complete mess > > when applied to local IPC. > > Local service can abstract different transports. Application itself does not > need to support more than plaintext DNS. Timeouts should not occur between > localhost service. It should respond with SERVFAIL if upstream failed to > respond in time. The service can still wait a bit more, but should tell the > application failed resolution early. If response arrives later, retried > query would be answered from cache. > > It should also make retries and handling of TC responses for the client. > TCP-like response over unix stream pipe can always deliver final reply, > whatever the response was. 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. > Varlink seems to be based on json. That is okay for a small structured data. > I doubt encoding all data from response would be more efficient using json, > than already provided by DNS packet.Especially when applications needing > expanded responses already have DNS packet parsing implemented. 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 -- _______________________________________________ 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
