summaryrefslogtreecommitdiffstats
path: root/mDNSResponder/README.txt
diff options
context:
space:
mode:
authorSebastian Huber <sebastian.huber@embedded-brains.de>2014-01-30 13:52:13 +0100
committerSebastian Huber <sebastian.huber@embedded-brains.de>2014-01-30 16:23:04 +0100
commit9449f151d0ccf3ac755d5f2bd9b4057ae2b03157 (patch)
treeada21dc6aa0b146c62a7561a08fb51fe4a8922ee /mDNSResponder/README.txt
parentDHCPCD(8): Add MASTER_ONLY option (diff)
downloadrtems-libbsd-9449f151d0ccf3ac755d5f2bd9b4057ae2b03157.tar.bz2
mDNS: Import
The sources can be obtained via: http://opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-544.tar.gz
Diffstat (limited to 'mDNSResponder/README.txt')
-rw-r--r--mDNSResponder/README.txt166
1 files changed, 166 insertions, 0 deletions
diff --git a/mDNSResponder/README.txt b/mDNSResponder/README.txt
new file mode 100644
index 00000000..86b041ee
--- /dev/null
+++ b/mDNSResponder/README.txt
@@ -0,0 +1,166 @@
+What is mDNSResponder?
+----------------------
+
+The mDNSResponder project is a component of Bonjour,
+Apple's ease-of-use IP networking initiative:
+<http://developer.apple.com/bonjour/>
+
+Apple's Bonjour software derives from the ongoing standardization
+work of the IETF Zero Configuration Networking Working Group:
+<http://zeroconf.org/>
+
+The Zeroconf Working Group has identified three requirements for Zero
+Configuration Networking:
+1. An IP address (even when there is no DHCP server to assign one)
+2. Name-to-address translation (even when there is no DNS server)
+3. Discovery of Services on the network (again, without infrastucture)
+
+Requirement 1 is met by self-assigned link-local addresses, as
+described in "Dynamic Configuration of IPv4 Link-Local Addresses"
+<http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt>
+
+Requirement 2 is met by sending DNS-like queries via Multicast (mDNS).
+
+Requirement 3 is met by DNS Service Dicsovery (DNS-SD).
+
+Self-assigned link-local address capability has been available since
+1998, when it first appeared in Windows '98 and in Mac OS 8.5.
+Implementations for other platforms also exist.
+
+The mDNSResponder project allows us to meet requirements 2 and 3.
+It provides the ability for the user to identify hosts using names
+instead of dotted-decimal IP addresses, even if the user doesn't have a
+conventional DNS server set up. It also provides the ability for the
+user to discover what services are being advertised on the network,
+without having to know about them in advance, or configure the machines.
+
+The name "mDNS" was chosen because this protocol is designed to be,
+as much as possible, similar to conventional DNS. The main difference is
+that queries are sent via multicast to all local hosts, instead of via
+unicast to a specific known server. Every host on the local link runs an
+mDNSResponder which is constantly listening for those multicast queries,
+and if the mDNSResponder receives a query for which it knows the answer,
+then it responds. The mDNS protocol uses the same packet format as
+unicast DNS, and the same name structure, and the same DNS record types.
+The main difference is that queries are sent to a different UDP port
+(5353 instead of 53) and they are sent via multicast to address
+224.0.0.251. Another important difference is that all "mDNS" names
+end in ".local." When a user types "yourcomputer.local." into their Web
+browser, the presence of ".local." on the end of the name tells the host
+OS that the name should be looked up using local multicast instead of by
+sending that name to the worldwide DNS service for resolution. This
+helps reduce potential user confusion about whether a particular name
+is globally unique (e.g. "www.apple.com.") or whether that name has only
+local significance (e.g. "yourcomputer.local.").
+
+
+About the mDNSResponder Code
+----------------------------
+
+Because Apple benefits more from widespread adoption of Bonjour than
+it would benefit from keeping Bonjour proprietary, Apple is making
+this code open so that other developers can use it too.
+
+Because Apple recognises that networks are hetrogenous environments
+where devices run many different kinds of OS, this code has been made
+as portable as possible.
+
+A typical mDNS program contains three components:
+
+ +------------------+
+ | Application |
+ +------------------+
+ | mDNS Core |
+ +------------------+
+ | Platform Support |
+ +------------------+
+
+The "mDNS Core" layer is absolutely identical for all applications and
+all Operating Systems.
+
+The "Platform Support" layer provides the necessary supporting routines
+that are specific to each platform -- what routine do you call to send
+a UDP packet, what routine do you call to join multicast group, etc.
+
+The "Application" layer does whatever that particular application wants
+to do. It calls routines provided by the "mDNS Core" layer to perform
+the functions it needs --
+ * advertise services,
+ * browse for named instances of a particular type of service
+ * resolve a named instance to a specific IP address and port number,
+ * etc.
+The "mDNS Core" layer in turn calls through to the "Platform Support"
+layer to send and receive the multicast UDP packets to do the actual work.
+
+Apple currently provides "Platform Support" layers for Mac OS 9, Mac OS X,
+Microsoft Windows, VxWorks, and for POSIX platforms like Linux, Solaris,
+FreeBSD, etc.
+
+Note: Developers writing applications for OS X do not need to incorporate
+this code into their applications, since OS X provides a system service to
+handle this for them. If every application developer were to link-in the
+mDNSResponder code into their application, then we would end up with a
+situation like the picture below:
+
+ +------------------+ +------------------+ +------------------+
+ | Application 1 | | Application 2 | | Application 3 |
+ +------------------+ +------------------+ +------------------+
+ | mDNS Core | | mDNS Core | | mDNS Core |
+ +------------------+ +------------------+ +------------------+
+ | Platform Support | | Platform Support | | Platform Support |
+ +------------------+ +------------------+ +------------------+
+
+This would not be very efficient. Each separate application would be sending
+their own separate multicast UDP packets and maintaining their own list of
+answers. Because of this, OS X provides a common system service which client
+software should access through the "/usr/include/dns_sd.h" APIs.
+
+The situation on OS X looks more like the picture below:
+
+ -------------------
+ / \
+ +---------+ +------------------+ +---------+ \ +---------+
+ | App 1 |<-->| daemon.c |<-->| App 2 | ->| App 3 |
+ +---------+ +------------------+ +---------+ +---------+
+ | mDNS Core |
+ +------------------+
+ | Platform Support |
+ +------------------+
+
+Applications on OS X make calls to the single mDNSResponder daemon
+which implements the mDNS and DNS-SD protocols.
+
+Vendors of products such as printers, which are closed environments not
+expecting to be running third-party application software, can reasonably
+implement a single monolithic mDNSResponder to advertise all the
+services of that device. Vendors of open systems which run third-party
+application software should implement a system service such as the one
+provided by the OS X mDNSResponder daemon, and application software on
+that platform should, where possible, make use of that system service
+instead of embedding their own mDNSResponder.
+
+See ReadMe.txt in the mDNSPosix directory for specific details of
+building an mDNSResponder on a POSIX Operating System.
+
+
+Compiling on Older C Compilers
+------------------------------
+
+We go to some lengths to make the code portable, but //-style comments
+are one of the modern conveniences we can't live without.
+
+If your C compiler doesn't understand these comments, you can transform
+them into classical K&R /* style */ comments with a quick GREP
+search-and-replace pattern.
+
+In BBEdit on the Mac:
+1. Open the "Find" dialog window and make sure "Use Grep" is selected
+2. Search For : ([^:])//(.*)
+3. Replace With: \1/*\2 */
+4. Drag your mDNSResponder source code folder to the Multi-File search pane
+5. Click "Replace All"
+
+For the more command-line oriented, cd into your mDNSResponder source code
+directory and execute the following command (all one line):
+
+find mDNSResponder \( -name \*.c\* -or -name \*.h \) -exec sed -i .orig -e 's,^//\(.*\),/*\1 */,' -e '/\/\*/\!s,\([^:]\)//\(.*\),\1/*\2 */,' {} \;