[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-29 17:03:06
Message-ID: 200410291903.06827.stachowski () hypair ! net
[Download RAW message or body]

Dnia czwartek, 28 października 2004 21:46, Thiago Macieira napisał:
> Jakub Stachowski wrote:
> >These d-pointers can be useful for better abstracting RemoteService and
> >QueryBase - instead of derived classes for mDNS and uDNS they can be made
> >into *Private part.
>
> All public, non-trivial classes should have d pointers and virtual hooks.
> You never know if you'll have to extend the functionality by adding a new
> member in the next 3 years.
>
> >> - classes have inlined methods and member variables -- might not be a
> >> good idea
> >
> >Inlined methods removed, by what is wrong with member variables? Most
> > classes in kdelibs have them.
>
> Nothing wrong per se, but you won't be able to remove them later, if you
> find a better way of doing something. If you move them to the d pointer,
> you can do whatever you wish with them.

You are right, it didn't add any complexity.

>
> >> Actually, for UDNSQuery, I'd rather you did not use QDns at all. Please
> >> use KResolver for PTR-resolution, if that's what you need.
> >
> >How can I do it? I see only API for straight name-to-address resolution,
> > not name-to-name/
>
> Indeed. It's not really possible with the current code. I had made wrong
> assumptions about the nature of the PTR lookup. So far, I had never seen
> PTRs being used for anything but IP-to-name resolutions.
>
> Please bear in mind that you will have to do this for Qt4/KDE4, so you
> might as well do it now.

Things that are needed for unicast DNS-SD:
- name-to-name PTR resolving
- SVR name-to-address:port
- TXT data for given name
- ability to use UTF-8 instead of IDN for PTR query

>
> >It seems I'm spoiled by KDevelop too much :-)
>
> /usr/bin/indent is your friend :-)

I just found something similar - astyle. 

>
> >> Seems to be achieving that. However, is it really necessary to make the
> >> resolutions go "_http._tcp"?
> >
> >I have to thank Matthias Ettrich and slides from his aKademy talk for
> > that. As second part of service type can be only either _tcp or _udp I
> > can make it enum.
>
> After reading some about DNS-SD, it would seem that a pair isn't enough
> either. For instance, we have _anon._ftp._tcp. So you may need something
> like:
> 	QString service, QString protocol, QString specialisation = QString::null
>

I have to think a bit more about that.

> where protocol could also be overloaded with int (IPPROTO_TCP, IPPROTO_UDP)
> or an enum. But please allow the full string construction, because we may
> suddenly want to support SCTP or DCCP (replacements for TCP and UDP,
> respectively).
>
> >Possible way of integration: add new category "Network hosts" (or similar)
> > to dnssd:// (in addition to typical like "FTP servers").  URL belonging
> > to this category would be internally (in dnssd slave) redirected to lisa
> > ioslave - exactly as media:// does. I could use ForwardingSlaveBase from
> > kioslave/media for that.
>
> Agreed.

So I will do that.

>
> >> Aside from what I pointed out above, I think we could give it a try.
> >> However, as things go, you'll first need an application using it for it
> >> to move away from kdenonbeta. Then you'll need a second for it to go
> >> into kdelibs.
> >
> >Ehm, what "second" ? Second application using it?
>
> The first application using your code gets to have your library. When a
> second application needs it, the library is moved to kdelibs.
>
> As I said in another email, I'd like to integrate Multicast DNS into the
> current KResolver code.

Good idea, that would make KResolver one and consistent interface to all types 
of DNS.
Another possibility: implement mDNS resolving in nss module. This would allow 
using libresolv for that and would support also console/non-KDE apps.

>
> For a full integration, we'd need an extended KResolver that does raw DNS
> queries. That's not kdelibs's job -- at least not now. It would be best
> suited to a network library, so, probably in kdenetwork. Besides, all the
> applications you name for patches, as well as those mentioned in the wiki,
> are kdenetwork applications.
>
> So, I'm proposing:
> -> multicast DNS simple resolution (hostname to IP and vice-versa): in
> libkdecore
> -> SRV-based service resolution: in libkdecore (that's already in my ToDo)
> -> DNS-SD service lookups: somewhere in kdenetwork
> -> DNS-SD service publishing via Multicast DNS: somewhere in kdenetwork
> -> kcm & ioslave: also in kdenetwork
>
> 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. How caching in 
libresolv is implemented? Without any additional daemon?

>
> >> Also, can it work at all without libhowl? How difficult would it be to
> >> reimplement it, if necessary?
> >
> >I could try to reimplement it using parts from mdnsd
> >(http://dotlocal.org/mdnsd/) . They are only 2 important .c files so it
> > would be possible to embed it. I can't say anything about difficulty and
> > required time before I try doing it.
>
> I could not find a homepage for libhowl on the Internet. I could only find
> the Debian package's page and similar ones.

http://www.porchdogsoft.com/products/howl/
They just released new (bugfix only) version.

>
> What does libhowl do, exactly? Does it implement the Multicast DNS sending
> & receiving? Does it do caching? Or does it implement only a communication
> protocol to an "mdnsd" daemon?

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

mdnsd mentioned earlier is completely independent work - much smaller, simpler 
and low-level.

>
> Does the service require a daemon?
>
> >I understand that extra lib is problem but what is wrong with QDns?
>
> Past experience showed it not to be reliable. The async resolver code for
> KDE 2.2 through 3.2 has had many problems due to QDns bugs. For instance,
> it simply ignored the AAAA replies it received, and so applications hung
> while waiting for a name resolution.
>
> I'm not sure if those bugs are fixed -- KDE has stopped using QDns for some
> time now.

Well, it is still buggy - broken TXT handling. 

> And I was also under the impression that it would go away for 
> Qt4, replaced by a new resolver API similar to what I developed for KDE --
> using getaddrinfo. However, it's still there in Qt4 TP2, so I'm not sure
> what will happen.
>
> The benefit of using it instead of going to the libresolv functions is that
> it implements caching and parsing. So, if it stays in Qt4 and if we really
> need to do DNS stuff -- and mind you that it won't work for mDNS -- then I
> don't see a problem in using it.

I checked Qt4tp2 docs and it seems that QDns is down to one function - 
getHostbyName. So unfortunately, it really has to be replaced.

Sorry for long delay - I am trying to implement all suggestions and it takes 
time.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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