From kde-devel Thu Oct 28 19:46:43 2004 From: Thiago Macieira Date: Thu, 28 Oct 2004 19:46:43 +0000 To: kde-devel Subject: Re: DNS based service discovery Message-Id: <200410281646.44068.thiago.macieira () kdemail ! net> X-MARC-Message: https://marc.info/?l=kde-devel&m=109899292024323 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1424016844==" --===============1424016844== Content-Type: multipart/signed; boundary="nextPart2833896.nfoud21gJc"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2833896.nfoud21gJc Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.=20 You never know if you'll have to extend the functionality by adding a new=20 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=20 find a better way of doing something. If you move them to the d pointer,=20 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=20 assumptions about the nature of the PTR lookup. So far, I had never seen=20 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 ?=20 No, QValueList, and make your ServiceBase's operator=3D=3D do = the=20 comparison. The problem is you'll need a default constructor -- and=20 therefore the class cannot be abstract -- and operator=3D. Please bear in mind that you will have to do this for Qt4/KDE4, so you migh= t=20 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=20 either. For instance, we have _anon._ftp._tcp. So you may need something=20 like: QString service, QString protocol, QString specialisation =3D QString::null where protocol could also be overloaded with int (IPPROTO_TCP, IPPROTO_UDP)= =20 or an enum. But please allow the full string construction, because we may=20 suddenly want to support SCTP or DCCP (replacements for TCP and UDP,=20 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= =20 list services in your network. For instance, it can be used to find all the= =20 http websites, all the FTP servers, all the SMB servers, SSH servers, etc.= =20 That's exactly what lisa/kio_network does, except that it does active=20 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=20 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=20 current KResolver code. =46or a full integration, we'd need an extended KResolver that does raw DNS= =20 queries. That's not kdelibs's job -- at least not now. It would be best=20 suited to a network library, so, probably in kdenetwork. Besides, all the=20 applications you name for patches, as well as those mentioned in the wiki,= =20 are kdenetwork applications. So, I'm proposing: =2D> multicast DNS simple resolution (hostname to IP and vice-versa): in=20 libkdecore =2D> SRV-based service resolution: in libkdecore (that's already in my ToDo) =2D> DNS-SD service lookups: somewhere in kdenetwork =2D> DNS-SD service publishing via Multicast DNS: somewhere in kdenetwork =2D> kcm & ioslave: also in kdenetwork The only problem with Multicast DNS in kdelibs is that we need a local=20 caching daemon. Each app doing its own sending and caching is probably=20 unnecessary and could generate a lot of traffic. Even doing that in=20 auxiliary threads would impose a lot of difficulty, given what I've read=20 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= =20 the Debian package's page and similar ones. What does libhowl do, exactly? Does it implement the Multicast DNS sending = &=20 receiving? Does it do caching? Or does it implement only a communication=20 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=20 KDE 2.2 through 3.2 has had many problems due to QDns bugs. For instance,=20 it simply ignored the AAAA replies it received, and so applications hung=20 while waiting for a name resolution. I'm not sure if those bugs are fixed -- KDE has stopped using QDns for some= =20 time now. And I was also under the impression that it would go away for=20 Qt4, replaced by a new resolver API similar to what I developed for KDE --= =20 using getaddrinfo. However, it's still there in Qt4 TP2, so I'm not sure=20 what will happen. The benefit of using it instead of going to the libresolv functions is that= =20 it implements caching and parsing. So, if it stays in Qt4 and if we really= =20 need to do DNS stuff -- and mind you that it won't work for mDNS -- then I= =20 don't see a problem in using it. =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 --nextPart2833896.nfoud21gJc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBgUykM/XwBW70U1gRAnKBAJ404ip9enCBrEJ7Rf74oLGcfbjM0ACgpuOA WgcfAUkqRQsZ0Qb5QuVuIj8= =6qfH -----END PGP SIGNATURE----- --nextPart2833896.nfoud21gJc-- --===============1424016844== 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 << --===============1424016844==--