advertisement

Article:
  Understanding Zeroconf and Multicast DNS
Subject:   Some links
Date:   2003-02-27 01:38:18
From:   anonymous2
Zeroconf means different things to different people. For example, the IETF Zeroconf working Group (perhaps "not-Working Group" would be more accurate, given the bickering going on) is only dealing with the IP address assignment problem. They are not specifying the name-to-address translation solution, nor are they dealing with service location.


The service location problem has a few answers (almost everyone has tried it, most implementations were pretty bad), but the IETF answer is Service Location Protocol v2 (see RFC2608, 2609, 2610, 2614 and some others - http://www.srvloc.org).


DNS SRV records (and TXT records, and PTR records, and NUL records - which makes up DNS Service Discovery - http://www.dns-sd.org) can help a bit, but suffer from not being able to do server side filtering. Imagine that you need to pull down the TXT records for every printer on a large network to find the one that can print on A2. SLPv2 can solve that problem.


There are also a couple of options for multicast DNS, one by Apple, and another by Microsoft. Both are pretty similar though.


For more info, including some implementation code, see http://zeroconf.sf.net


<bradh-NOSPAM@frogmouth.net>
Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • ZeroConf, SLP, SSDP & UPnP
    2003-06-21 20:45:17  anonymous2 [Reply | View]

    ZeroConf really just deals with IP discovery and UPnP is perfectly happy to run over it. The service discovery part is handled by SLP which I really don't like (see http://www.goland.org/Tech/slpv2.htm for details) because, ironically enough, it requires the exact sort of centralization that the article accuses UPnP of requiring. The core of UPnP discovery is SSDP and here the article is right in spirit but wrong on the details. SSDP uses URIs to identify the services that one is looking for. Anyone, anywhere can define any URI they want to without ever having to talk to the UPnP forum. But in reality UPnP consists of much more than just SSDP, it also includes the device description mechanism that I wasn't ever really involved with so I won't speak to it. It is in the area of the device description that ends one up in the UPnP forum. The irony of the whole mess is that when we did UPnP we really wanted to use multi-cast based DNS instead of SSDP but the standards just weren't baked yet and we had to release. Also multi-cast DNS suffers from a number of scalability issues (imagine asking for a printer in a building with 200 printers) that SSDP, in theory, was intended to work around. In reality SSDP never added in the critical proxy functionality so in practice the difference isn't that large.

    Yaron

    P.S. See section 6 of the SSDP spec (http://upnp.org/download/draft_cai_ssdp_v1_03.txt) for some details on why scalability issues are so hard to deal with in a discovery context.