Home | History | Annotate | only in /external/mdnsresponder
Up to higher level directory
NameDateSize
Android.mk06-Dec-20164.2K
Clients/06-Dec-2016
LICENSE06-Dec-2016730
Makefile06-Dec-20161.5K
mDNSCore/06-Dec-2016
mdnsd.rc06-Dec-2016150
mDNSPosix/06-Dec-2016
mDNSResponder.sln06-Dec-201629.8K
mDNSShared/06-Dec-2016
MODULE_LICENSE_APACHE206-Dec-20160
NOTICE06-Dec-2016730
PrivateDNS.txt06-Dec-20169.6K
README.txt06-Dec-20167.5K
README.version06-Dec-2016126

README.txt

      1 What is mDNSResponder?
      2 ----------------------
      3 
      4 The mDNSResponder project is a component of Bonjour,
      5 Apple's ease-of-use IP networking initiative:
      6 <http://developer.apple.com/bonjour/>
      7 
      8 Apple's Bonjour software derives from the ongoing standardization
      9 work of the IETF Zero Configuration Networking Working Group:
     10 <http://zeroconf.org/>
     11 
     12 The Zeroconf Working Group has identified three requirements for Zero
     13 Configuration Networking:
     14 1. An IP address (even when there is no DHCP server to assign one)
     15 2. Name-to-address translation (even when there is no DNS server)
     16 3. Discovery of Services on the network (again, without infrastucture)
     17 
     18 Requirement 1 is met by self-assigned link-local addresses, as
     19 described in "Dynamic Configuration of IPv4 Link-Local Addresses"
     20 <http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt>
     21 
     22 Requirement 2 is met by sending DNS-like queries via Multicast (mDNS).
     23 
     24 Requirement 3 is met by DNS Service Dicsovery (DNS-SD).
     25 
     26 Self-assigned link-local address capability has been available since
     27 1998, when it first appeared in Windows '98 and in Mac OS 8.5.
     28 Implementations for other platforms also exist.
     29 
     30 The mDNSResponder project allows us to meet requirements 2 and 3.
     31 It provides the ability for the user to identify hosts using names
     32 instead of dotted-decimal IP addresses, even if the user doesn't have a
     33 conventional DNS server set up. It also provides the ability for the
     34 user to discover what services are being advertised on the network,
     35 without having to know about them in advance, or configure the machines.
     36 
     37 The name "mDNS" was chosen because this protocol is designed to be,
     38 as much as possible, similar to conventional DNS. The main difference is
     39 that queries are sent via multicast to all local hosts, instead of via
     40 unicast to a specific known server. Every host on the local link runs an
     41 mDNSResponder which is constantly listening for those multicast queries,
     42 and if the mDNSResponder receives a query for which it knows the answer,
     43 then it responds. The mDNS protocol uses the same packet format as
     44 unicast DNS, and the same name structure, and the same DNS record types.
     45 The main difference is that queries are sent to a different UDP port
     46 (5353 instead of 53) and they are sent via multicast to address
     47 224.0.0.251. Another important difference is that all "mDNS" names
     48 end in ".local." When a user types "yourcomputer.local." into their Web
     49 browser, the presence of ".local." on the end of the name tells the host
     50 OS that the name should be looked up using local multicast instead of by
     51 sending that name to the worldwide DNS service for resolution. This
     52 helps reduce potential user confusion about whether a particular name
     53 is globally unique (e.g. "www.apple.com.") or whether that name has only
     54 local significance (e.g. "yourcomputer.local.").
     55 
     56 
     57 About the mDNSResponder Code
     58 ----------------------------
     59 
     60 Because Apple benefits more from widespread adoption of Bonjour than
     61 it would benefit from keeping Bonjour proprietary, Apple is making
     62 this code open so that other developers can use it too.
     63 
     64 Because Apple recognises that networks are hetrogenous environments
     65 where devices run many different kinds of OS, this code has been made
     66 as portable as possible.
     67 
     68 A typical mDNS program contains three components:
     69 
     70     +------------------+
     71     |   Application    |
     72     +------------------+
     73     |    mDNS Core     |
     74     +------------------+
     75     | Platform Support |
     76     +------------------+
     77 
     78 The "mDNS Core" layer is absolutely identical for all applications and
     79 all Operating Systems.
     80 
     81 The "Platform Support" layer provides the necessary supporting routines
     82 that are specific to each platform -- what routine do you call to send
     83 a UDP packet, what routine do you call to join multicast group, etc.
     84 
     85 The "Application" layer does whatever that particular application wants
     86 to do. It calls routines provided by the "mDNS Core" layer to perform
     87 the functions it needs --
     88  * advertise services,
     89  * browse for named instances of a particular type of service
     90  * resolve a named instance to a specific IP address and port number,
     91  * etc.
     92 The "mDNS Core" layer in turn calls through to the "Platform Support"
     93 layer to send and receive the multicast UDP packets to do the actual work.
     94 
     95 Apple currently provides "Platform Support" layers for Mac OS 9, Mac OS X,
     96 Microsoft Windows, VxWorks, and for POSIX platforms like Linux, Solaris,
     97 FreeBSD, etc.
     98 
     99 Note: Developers writing applications for OS X do not need to incorporate
    100 this code into their applications, since OS X provides a system service to
    101 handle this for them. If every application developer were to link-in the
    102 mDNSResponder code into their application, then we would end up with a
    103 situation like the picture below:
    104 
    105   +------------------+    +------------------+    +------------------+
    106   |   Application 1  |    |   Application 2  |    |   Application 3  |
    107   +------------------+    +------------------+    +------------------+
    108   |    mDNS Core     |    |    mDNS Core     |    |    mDNS Core     |
    109   +------------------+    +------------------+    +------------------+
    110   | Platform Support |    | Platform Support |    | Platform Support |
    111   +------------------+    +------------------+    +------------------+
    112 
    113 This would not be very efficient. Each separate application would be sending
    114 their own separate multicast UDP packets and maintaining their own list of
    115 answers. Because of this, OS X provides a common system service which client
    116 software should access through the "/usr/include/dns_sd.h" APIs.
    117 
    118 The situation on OS X looks more like the picture below:
    119 
    120                                    -------------------
    121                                   /                   \
    122   +---------+    +------------------+    +---------+   \  +---------+
    123   |  App 1  |<-->|    daemon.c      |<-->|  App 2  |    ->|  App 3  |
    124   +---------+    +------------------+    +---------+      +---------+
    125                  |    mDNS Core     |
    126                  +------------------+
    127                  | Platform Support |
    128                  +------------------+
    129 
    130 Applications on OS X make calls to the single mDNSResponder daemon
    131 which implements the mDNS and DNS-SD protocols. 
    132 
    133 Vendors of products such as printers, which are closed environments not
    134 expecting to be running third-party application software, can reasonably
    135 implement a single monolithic mDNSResponder to advertise all the
    136 services of that device. Vendors of open systems which run third-party
    137 application software should implement a system service such as the one
    138 provided by the OS X mDNSResponder daemon, and application software on
    139 that platform should, where possible, make use of that system service
    140 instead of embedding their own mDNSResponder.
    141 
    142 See ReadMe.txt in the mDNSPosix directory for specific details of
    143 building an mDNSResponder on a POSIX Operating System.
    144 
    145 
    146 Compiling on Older C Compilers
    147 ------------------------------
    148 
    149 We go to some lengths to make the code portable, but //-style comments
    150 are one of the modern conveniences we can't live without.
    151 
    152 If your C compiler doesn't understand these comments, you can transform
    153 them into classical K&R /* style */ comments with a quick GREP
    154 search-and-replace pattern.
    155 
    156 In BBEdit on the Mac:
    157 1. Open the "Find" dialog window and make sure "Use Grep" is selected
    158 2. Search For  : ([^:])//(.*)
    159 3. Replace With: \1/*\2 */
    160 4. Drag your mDNSResponder source code folder to the Multi-File search pane
    161 5. Click "Replace All"
    162 
    163 For the more command-line oriented, cd into your mDNSResponder source code
    164 directory and execute the following command (all one line):
    165 
    166 find mDNSResponder \( -name \*.c\* -or -name \*.h \) -exec sed -i .orig -e 's,^//\(.*\),/*\1 */,' -e '/\/\*/\!s,\([^:]\)//\(.*\),\1/*\2 */,' {} \;
    167 

README.version

      1 URL: http://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-320.10.80.tar.gz
      2 Version: 320.10.80
      3 BugComponent: 31808
      4