User login

Navigation

Contribute

Interested in contributing to FootNotes? Click here to submit news stories to us or visit this site for more information about available opportunities.

GNOME Support

Friends of GNOME

Now's a good time to say thanks for the best desktop environment on the planet by becoming a Friend of GNOME or by upping your current Friends level. Contribute by joining the Friends of GNOME program. All contributions are tax-deductible in the U.S. Thanks to our generous Friends

Links of Interest

Syndicate

Online users:

omarlenovo

DNS-SD support in gnome-vfs

Submitted by stro on Fri, 2004-06-18 13:07. GNOME

Alexander Larsson wrote: I've added support for dns service discovery using unicast and
multicast dns (called Rendezvous by apple) to gnome-vfs HEAD. The mDNS
support is done using the howl library, and the unicast code just uses
libresolv.

DNS Service Discovery is a way of using standard DNS programming interfaces, servers, and packet formats to browse the network for services.

This has two parts:

1) Gnome-vfs exports API to browse and resolve services using
dns-sd. This means applications can easily support detection of
various types of services, both on the local link and system wide
using unicast dns.

At the moment there is no support in the gnome-vfs api to publish
services, because I'm not sure how publish in the unicast case
(dns-update perhaps?), so I don't want to lock down the API for that
yet. If you want to publish mDNS stuff you can use howl directly.

2) Support in network:// for service discovery of ftp and webdav
shares. By default, all link-local share are shown in
network://, but you can also configure it
(using /system/dns_sd/display_local) to show just a link to the
link-local shares, or disable it totally.

It queries your unicast dns domain for a list of browsing
domains and shows links to all those domains in network://. You
can also add additional domains to network:// by setting
/system/dns_sd/extra_domains to a comma-separated list of
additional domains.

I have rpms for how availible at:
http://people.redhat.com/alexl/RPMS/
These rpms work in FC1 and FC2 (at least) and contains some important
patches that i've sent to the howl mailing list this week.

Testing the mDNS support can be done by exporting things with howl
(use the mDNSPublish app in the howl code, or edit
/etc/howl/mDNSResponder.conf), or by e.g. enabling ftp shares on an OS
X machine on the same network link.

Testing unicast dns-sd is harder. And easy way is to add "dns-sd.org"
to the list of browsed domains with something like:
gconftool-2 -s --type string /system/dns_sd/extra_domains dns-sd.org

Another way is to set up your own dns-sd zones. I've done this on my
box at home, and my zone files contain something like this:

_browse._dns-sd._udp.alex.test:

IN NS 192.168.0.10
IN PTR alex.test.
IN PTR dns-sd.org.
IN PTR redhat.com.

_webdav._tcp.alex.test:

IN NS 192.168.0.10
IN PTR Test32Share._webdav._tcp.alex.test.

Test32Share IN SRV 0 0 80 greebo.homeip.net.
Test32Share IN A 192.168.0.1
Test32Share IN TXT "path=/dav"

Here is a screenshot of this in action:

http://people.redhat.com/alexl/files/network2.png

Its showing the network location with two local mDNS shares (Alex test
dav, and Alex test ftp), one local MacOS X ftp share (Anna Rosus dator,
I just enabled the ftp sharing), two unicast dns-sd domains (alex.test
which is my local test domain, and dns-sd.org which is from the dns-sd
RFC).

Re: DNS-SD support in gnome-vfs

Submitted by Anonymous George on Sat, 2004-06-19 01:21.

Windows has always done this too, albiet usually poorly. Or am I missing something?

One thing it always creates in Windows networks is a lot of noise on the local network as machines search for "Master Browsers", domain controllers, domains, shares, etc.

MS seemed to try to alleviate this with caching but that leads to inconsistent behaviour eg. shares remaining visible on the local machine even when the resource is unavailable.

I hope this stuff is different. I read bits of the "Replacing NBD" and "DNS-SD" docs and it looked interesting but I hope it doesn't become too noisy and I hope it can be kept coherent and robust. The NBD doc touches on the need for a distributed cache with cache coherency and the DNS-SD doc has a bit on network efficiency through a basic over-the-wire compression scheme so they're obviously thinking about this stuff a bit. I'll be interested to see how it performs in a hostile/large environment.

Cheers

Stor

» parent