On Mo, 21.10.24 12:38, Petr Menšík (pemensik@xxxxxxxxxx) wrote: > > 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. > > Okay. It might be better than D-Bus, but having to make separate connections > for every single resolution is still a bit wasteful. Uh. I mean, if you want, kep the connections around aftre each resolution and reuse them. But frankly, you are focussing on the wrong things. Roundtrips are wasteful, and D-Bus is rife of them. A singular bottleneck that the broker is is wasteful. But local AF_UNIX sockets are not in comparison, not even remotely. > 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. Sure, reinvent IPC another time. Have fun! > > 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. > 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. I know you don't like systemd-resolved, but maybe you can at least acknowledge that is does exist. > 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. Good luck with yet another C API. > 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. Sorry, but marhsalling is not where the cost is for local IPC. In current Linux systems it's roundtrips, roundtrips, roundtrips. Forget everything else. 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
