From kde-devel Sat Oct 30 00:53:16 2004 From: Thiago Macieira Date: Sat, 30 Oct 2004 00:53:16 +0000 To: kde-devel Subject: Re: DNS based service discovery Message-Id: <200410292153.23868.thiago.macieira () kdemail ! net> X-MARC-Message: https://marc.info/?l=kde-devel&m=109909766315418 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0501907071==" --===============0501907071== Content-Type: multipart/signed; boundary="nextPart1279248.pkCR1aPhWi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1279248.pkCR1aPhWi Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Jakub Stachowski wrote: >Things that are needed for unicast DNS-SD: >- name-to-name PTR resolving Not possible with KResolver. Possible with QDns. >- SVR name-to-address:port Will be possible with KResolver, including proper weight and priority=20 handling. >- TXT data for given name Not possible with KResolver. Possible with QDns. >- ability to use UTF-8 instead of IDN for PTR query You mean "ability to use UTF-8 instead of ACE for mDNS". IDN means=20 "International Domain Name". If your UTF-8 domain isn't ASCII, then it's=20 internationalised and, therefore, IDN. At least, that's how I read things. Making mDNS not follow the IDN Nameprep= =20 guidelines would wreak havoc and I, quite frankly, refuse to implement it=20 that way. Also note that PTR queries over normal DNS must be ACE-encoded. I don't car= e=20 what DNS-SD says: if you transmit over the normal DNS servers, it has to be= =20 ACE, not UTF-8. >Good idea, that would make KResolver one and consistent interface to all > types of DNS. Yep, that's the idea. >Another possibility: implement mDNS resolving in nss module. This would > allow using libresolv for that and would support also console/non-KDE > apps. I've thought about that. But not only is that outside our scope, it would=20 also have problems with IDN. getaddrinfo supports, in glibc, the AI_IDN flag. However, like all other=20 8-bit functions in glibc, it must accept the locale's encoding for input.=20 Since Qt/KDE is fully Unicode, we have a problem. In any event, it's not just the nss module. Reading the getaddrinfo() code= =20 indicates that IDN transformation is processed in getaddrinfo itself,=20 meaning the nss module would get the ACE-encoded domainname. Which means=20 that getaddrinfo() in glibc would have to be changed as well. As for systems that don't implement IDN in their name-resolver functions,=20 it's not a problem: the nss module would be passed only pure ASCII domains. >> The only problem with Multicast DNS in kdelibs is that we need a local >> caching daemon. Each app doing its own sending and caching is probably >> unnecessary and could generate a lot of traffic. Even doing that in >> auxiliary threads would impose a lot of difficulty, given what I've read >> from the mdns drafts. > >So we would end up with Apple's mDNSResponder replacement.=20 That's what it seems. We need a local daemon to implement the more advanced= =20 features for cache coherency. A normal app cannot keep a multicast socket=20 open and keep processing all the information. That's not its job, nor that= =20 of libkdecore. >How caching in libresolv is implemented? Without any additional daemon?=20 It's not. libresolv does not cache. QDns does: it keeps the resolved records in memory until they expire, as pe= r=20 TTL. mDNS, however, requires that the application keep receiving resolutions and= =20 sending information to the multicast group. >It is basically wrapper over Apple's mDNSResponder. l can't use it > directly because it is under some strange license (APSL). libhowl is > under BSD license. It doesn't directly link with Apple's code, instead it > comunicates with responder using corba (and yes, this is hairy stuff). > mDNSResponder does all hard work like network handling, DNS packets > parsing, caching, providing "special" services like > _services._dns-sd._udp (lists all service types on network). A-ha! So it's the local daemon I was wondering all the time. It seems to me that we should find a replacement for it. At the very least,= =20 something that doesn't use CORBA. DCOP/D-BUS would be ideal. >mdnsd mentioned earlier is completely independent work - much smaller, > simpler and low-level. That's a start. >I checked Qt4tp2 docs and it seems that QDns is down to one function - >getHostbyName. So unfortunately, it really has to be replaced. Indeed... so TT folks have replaced it. However, it has not gone away completely. It's still available as Q3Dns. Th= e=20 warning on it is "This class is part of the Qt 3 compatibility library. It= =20 is provided to keep old source code working. We strongly advise against=20 using it in new code.", though. We may have to implement our own resolver code, after all. KResolver has th= e=20 necessary framework for that, if necessary. =2D-=20 Thiago Macieira - Registered Linux user #65028 thiago (AT) macieira (DOT) info ICQ UIN: 1967141 PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 --nextPart1279248.pkCR1aPhWi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBguYDM/XwBW70U1gRAnwnAJwLu7EyZ6CMFJA8DS+yGSI3epBXGwCfScTI iITzWJoyPLpozKzPuDWnTvc= =TBDa -----END PGP SIGNATURE----- --nextPart1279248.pkCR1aPhWi-- --===============0501907071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0501907071==--