On Do, 17.10.24 18:11, Petr Menšík (pemensik@xxxxxxxxxx) wrote: > > I certainly have answered the questions you raised for *myself*, > > though I am pretty sure you are not going to like my answer: I think > > the Varlink IPC APIs that systemd-resolved implements are the way to > > go. There's work going on to add ALPN and stuff hooked into > > systemd-resolved already. It provides simple SRV resolution APIs > > already, asynchronously. > > > > Lennart > > > > -- > > Lennart Poettering, Berlin > > There is not anything wrong with Varlink IPC itself. There needs to be a > decent encoding of every information shared back into the application. If > DNS protocol should not be used for that, then there needs to be some other > protocol to encode and decode that information. I want received information > complex, at least (simple) possibility of it. That means the information > transferred would not be simple anyway. It might need to be structured, > possibly quite complex.As is HTTPS and SVCB record. Sure, SRV is relatively > trivial in comparison. New records have arbitrary key-value parameters, > which are future extensible. 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 think the problem is Varlink needs a new protocol for the name resolution. > I have seen only DBus API for systemd-resolved. It is fine for some things, > not working for others. But Varlink is the new API, which you say is not > necessary anymore. Network BSD sockets are still handled by applications > themselves, often made easier with some toolkits on top. If people still > need socket handles, then they need something like struct sockaddr address > for it. Ideally with a way to get additional information with it. Like TTL, > servername, priority or weight. 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. > I think we could still use unix domain socket in some standard path and send > queries from applications to local daemons over it. DNS protocol is > compressed enough and binary already. I am not sure if translating DNS > message into varlink structures will make it actually simpler to parse. It > would require completely new code on side of applications. I would use > simplified DNS protocol on local pipe for IPC. That is close enough to what > some applications already implemented or have libraries for. Though we need > to pass AF_UNSPEC address request in single query, not like separate A+AAAA > requests arriving to cache service. 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. 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. > 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 -- _______________________________________________ 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
