From what I read about Varlink.org, it requires answers to be
delivered in the same order in which queries has came. That is
quite unwanted feature for the name resolution. We cannot set
priorities affecting earlier queries. If some names are resolved
sooner and previous name is taking long, it should not require
first responses from all previous queries to arrive. I mean, it
would be okay for configuration and daemon status query. But not
for name queries.
That is described on https://varlink.org/#protocol, second paragraph.
DNS servers can send responses in any order, not necessary the same in which queries arrived. I think that is important feature to work well and fast. I would say without ability to do that, Varlink interface is out of game.
Petr
On Do, 17.10.24 18:11, Petr Menšík (pemensik@xxxxxxxxxx) wrote: resolved offers you "cooked" and "raw" interfaces. If you opt for the "raw" interface you will get the data in DNS serialization (minus label compression and such), in the IPC replies....I cannot parse what you are writing here. Let me just say that D-Bus is problematic for doing DNS resolution with because DNS is really basic stuff that should work during earliest boot already. D-Bus is a late boot concept and in fact assumes that certain other OS functionality already works, such as user database resolution and logging services, both of which in turn might require host name resolution to already work. That makes D-Bus a poor choice as IPC for doing host name resolution. Varlink being much simpler and not requiring a broker always works, hence that's what we do....First of all, as mentioned "raw" RR lookups done via the Varlink IPC interface encode the RR data in DNS serialization. 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.
Dunno. Varlink is a trivial IPC. In systemd-resolved we support it side-by-side with D-Bus. I have zero interest in adding a 3rd IPC interface, hence whatever you come up with, expect us to be very cool on the idea on adding more.
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.
For a nss-resolve plugin delivering just addresses, it might be okay. For more complex responses I doubt translating DNS packet into JSON is reasonable.
The most important problem of existing system interface are blocking only calls. Every more complex program runs some kind of event loop, capable of handling multiple sockets and timeouts in a single thread. But that is not possible with API systems provide today. Modern programs are asynchronous for a good reason. I think providing them low-level building blocks still makes sense. They may be used inside higher level languages. I don't think DBus should be used, just because it has already existing integration to toolkits. It does not seem to be high-speed enough.D-Bus might not be great for "high-speed", but uh, it's still a a lot faster than a DNS lookup would require it. So, what can I say. There are good reasons to avoid D-Bus for this (see above), but "performance" really isn't it. Lennart -- Lennart Poettering, Berlin
-- Petr Menšík Software Engineer, RHEL Red Hat, https://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
