[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-28 19:46:43
Message-ID: 200410281646.44068.thiago.macieira () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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.

>But no doubt it is better to use SW_TEXT_RECORD_MAX_LEN instead of
> hardcoded 255 in case of future changes.

Thanks.

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

>> ServiceList is descended from QPtrList. Please make it a QValueList,
>> since the QPtr* are going away in Qt4 anyways.
>
>So I should use QValueList<ServiceBase*> ? 

No, QValueList<ServiceBase>, and make your ServiceBase's operator== do the 
comparison. The problem is you'll need a default constructor -- and 
therefore the class cannot be abstract -- and operator=.

Please bear in mind that you will have to do this for Qt4/KDE4, so you might 
as well do it now.

>It seems I'm spoiled by KDevelop too much :-)

/usr/bin/indent is your friend :-)

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

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

>> Probably integration with network:/ (lisa) is desireable.
>
>They are quite different - DNS-SD provides list of services regardless of
>their physical location (so you can reconnect printer named "Photo
> printer" to another machine and it will still work fine) when lisa
> provides list of computers on network and list of services provided by
> them.

Yes, but there's an overlap of functionality, because DNS-SD can be used to 
list services in your network. For instance, it can be used to find all the 
http websites, all the FTP servers, all the SMB servers, SSH servers, etc. 
That's exactly what lisa/kio_network does, except that it does active 
probing.

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

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

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.

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

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?

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

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