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

List:       kde-devel
Subject:    Re: DNS based service discovery
From:       Jakub Stachowski <stachowski () hypair ! net>
Date:       2004-10-30 12:51:49
Message-ID: 200410301451.49328.stachowski () hypair ! net
[Download RAW message or body]

Dnia Saturday, 30 of October 2004 02:53, Thiago Macieira napisał:
> Jakub Stachowski wrote:
> >Things that are needed for unicast DNS-SD:
> >- name-to-name PTR resolving
>
> Not possible with KResolver. Possible with QDns.

Forgot about one more requirement for mDNS - long queries. This means that you 
send query for PTR record and this works until is cancelled. During this time 
records can be both added and removed. But this is really distant from 
current KResolver.  It is only used for DNS-SD so it can be left it kdnssd.

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

Nope, I meant for both uDNS and mDNS. And for both PTR and SRV (noticed that 
after reading DNS-SD spec more carefully).

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

Implementing it any other way would make it useless - incompatible with 
specification and every existing implementations.

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

From DNS-SD spec: " DNS recommends guidelines for allowable characters for 
host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are not
host names."

DNS-SD is _not_ DNS - it only happens to reuse existing infrastructure - DNS 
servers. 

From RFC 1035 : 
"For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner.  At present, this rule is in
force throughout the domain system without exception.  However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided."

Well, DNS-SD case seems like "future addition beyond current usage".


>
> >Good idea, that would make KResolver one and consistent interface to all
> > types of DNS.
>
> Yep, that's the idea.
>

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

After reading some more (mDNS spec, Apple's mDNSResponder code, GNOME code, 
mdnsd code) I think that reimplementing daemon is not best idea:

- libhowl/mDNSResponder is gaining more and more users: GNOME, and firefox (in 
development) for example
- one running responder is means more efficient 
- implementing full mDNS daemon is quite a big work - because it is not only 
resolver but also server - and I'm not too convinced at the moment that it 
would be beneficial
- all other attempts to implement mDNS daemon failed 
	- mdnsd not updated for 1.5 year (still basic), 
	- gmdns - GNOME's effort based on mdnsd dropped in favor of libhowl
	- avahi (on freedesktop.org) - dead as well
- Apple's mDNSResponder (used by libhowl) can be viewed as kind of 'reference 
implementation'
- libhowl gets bugfixes and patches form various sources - for example in last 
version it can work on Solaris thanks to gnomes

As you can see, now I am for using libhowl and mDNSResponder as mDNS low-level 
API for KResolver (exactly as libresolv is used for uDNS). Publishing part 
should be kept in kdnssd.
Single disadvantage is that it adds external dependency (probably optional if 
someone doesn't care about mDNS) instead of internal.

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

Well, I searched for some time and found only two working solutions: howl and 
Apple's rendezvous SDK that cannot be used because of license.


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

I see that it is gone but i don't see any replacement.

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

So using it means linking to one more library?

>
> We may have to implement our own resolver code, after all. KResolver has
> the necessary framework for that, if necessary.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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