Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
>> I'm afraid that's not always true. Running Debian Lenny here without > > Paul, Iñaki, -- you guys are right. > > It also means that there's no point worrying about pushing extra > records in the DNS responses. It won't affect the XS side of things, but from the XO client side of things the new gresolver interface in glib might be off interest to people. http://mysterion.org/~danw/blog/2009/04/gresolver Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
2009/4/22 Iñaki Arenaza : > I'm afraid that's not always true. Running Debian Lenny here without Paul, Iñaki, -- you guys are right. It also means that there's no point worrying about pushing extra records in the DNS responses. > I've used tcpdump to dump DNS traffic while running 'ping -n I bow to your proof. I was doing the same thing here when I got your email ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
Martin Langhoff writes: >> also note that this will require that you run some sort of DNS cache on the > > The standard dns resolver libs on linux (part of glibc?) caches > alright. All platforms I know cache things alright, and it's fairly > serious bug if your OS doesn't. I'm afraid that's not always true. Running Debian Lenny here without nscd, configured to query an external DNS server (I normally run bind locally, but I changed resolv.conf for the tests and stopped bind). I've used tcpdump to dump DNS traffic while running 'ping -n some.valid.dns.name -c 3'. Everytime I re-launch the ping command, a new query is sent out. If I remove the '-n' in the ping command, a reverse query is sent for each iteration of the ping (to print the remote end name). Even installing and enabling nscd doesn't seem to change that (nscd doesn't cache hosts queries on Debian, see Debian bug #335476). I've tried other things like telneting to an external host and firefox browsing the same page repeatedly (closing firefox between request so firefox internal caches don't play tricks on me), and it seems consistent. So at least in Debian, glibc doesn't seem to cache DNS queries by default. Iñaki. -- Computing and Electronics Department Mondragon Unibertsitatea - http://www.mondragon.edu/telematika/ Loramendi, 4, 20500, Arrasate-Mondragon (Spain) +34 943794700 (ext. 6432) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
Martin Langhoff writes: (sorry if you receive this email twice; I've had a network glitch while sending it for the first time and I'm not sure it has gone through) >> also note that this will require that you run some sort of DNS cache on the > > The standard dns resolver libs on linux (part of glibc?) caches > alright. All platforms I know cache things alright, and it's fairly > serious bug if your OS doesn't. I'm afraid that's not always true. Running Debian Lenny here without nscd, configured to query an external DNS server (I normally run bind locally, but I changed resolv.conf for the tests and stopped bind). I've used tcpdump to dump DNS traffic while running 'ping -n some.valid.dns.name -c 3'. Everytime I re-launch the ping command, a new query is sent out. If I remove the '-n' in the ping command, a reverse query is sent for each iteration of the ping (to print the remote end name). Even installing and enabling nscd doesn't seem to change that (nscd doesn't cache hosts queries on Debian, see Debian bug #335476). I've tried other things like telneting to an external host and firefox browsing the same page repeatedly (closing firefox between request so firefox internal caches don't play tricks on me), and it seems consistent. So at least in Debian, glibc doesn't seem to cache DNS queries by default. Iñaki. -- Computing and Electronics Department Mondragon Unibertsitatea - http://www.mondragon.edu/telematika/ Loramendi, 4, 20500, Arrasate-Mondragon (Spain) +34 943794700 (ext. 6432) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 9:46 PM, Jonas Smedegaard wrote: > Here's my understanding: I've read the damned specs, don't worry. I need help getting sh*t done because there's a lot of stuff to do. any takers? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 07:26:30AM -0400, Benjamin M. Schwartz wrote: >Martin Langhoff wrote: >> The short of it is that mdns/dns-sd make sense for a small, >> underutilised network of peers. They assume that the network is a >> cheap resource, that broadcast messages are cheap, and that there is >> no coordinating server. > >mDNS assumes all of the above things. DNS-SD does not. DNS-SD is >perfectly happy to work on a standard DNS server. From the spec > >""" > This document proposes no change to the structure of DNS messages, > and no new operation codes, response codes, resource record types, > or any other new DNS protocol values. This document simply specifies > a convention for how existing resource record types can be named and > structured to facilitate service discovery. >""" >(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) > >I'm not particularly knowledgeable about the XS service discovery >requirements, nor about DNS, so I can't reasonably tell you to use >DNS-SD. > What I can say is that it seems like it should be workable. DNS-SD using unicast DNS seems reasonable to me too. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV -> A, but instead PTR -> SRV + TXT -> A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsflUACgkQn7DbMsAkQLiL2wCfV/HuaLPQ0kv/mvYH4fdImsIs ookAnAu5ir3uxxKNjCdTwu4gfNxdE4hZ =7Jde -END PGP SIGNATURE- ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
