[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: DNS based service discovery
From:       Thiago Macieira <thiago.macieira () kdemail ! net>
Date:       2004-10-30 0:53:16
Message-ID: 200410292153.23868.thiago.macieira () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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 
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 
"International Domain Name". If your UTF-8 domain isn't ASCII, then it's 
internationalised and, therefore, IDN.

At least, that's how I read things. Making mDNS not follow the IDN Nameprep 
guidelines would wreak havoc and I, quite frankly, refuse to implement it 
that way.

Also note that PTR queries over normal DNS must be ACE-encoded. I don't care 
what DNS-SD says: if you transmit over the normal DNS servers, it has to be 
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 
also have problems with IDN.

getaddrinfo supports, in glibc, the  AI_IDN flag. However, like all other 
8-bit functions in glibc, it must accept the locale's encoding for input. 
Since Qt/KDE is fully Unicode, we have a problem.

In any event, it's not just the nss module. Reading the getaddrinfo() code 
indicates that IDN transformation is processed in getaddrinfo itself, 
meaning the nss module would get the ACE-encoded domainname. Which means 
that getaddrinfo() in glibc would have to be changed as well.

As for systems that don't implement IDN in their name-resolver functions, 
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. 

That's what it seems. We need a local daemon to implement the more advanced 
features for cache coherency. A normal app cannot keep a multicast socket 
open and keep processing all the information. That's not its job, nor that 
of libkdecore.

>How caching in libresolv is implemented? Without any additional daemon? 

It's not. libresolv does not cache.

QDns does: it keeps the resolved records in memory until they expire, as per 
TTL.

mDNS, however, requires that the application keep receiving resolutions and 
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, 
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. The 
warning on it is "This class is part of the Qt 3 compatibility library. It 
is provided to keep old source code working. We strongly advise against 
using it in new code.", though.

We may have to implement our own resolver code, after all. KResolver has the 
necessary framework for that, if necessary.

-- 
  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

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]