mirror of
https://github.com/pocoproject/poco.git
synced 2024-12-12 18:20:26 +01:00
b41f211ece
* Initial commit
* initial commit
* added README.md
* Update README.md
* Add top level CMakeLists like another project in POCO framework. see #1
* Add CMakeLists to Avahi and Bonjour. (see #1)
* Missing changing in top level CMakeLists correct. (see #1)
* Add samples CMakeLists. (see #1)
* Add temporary cmake find module for Avahi and Bonjour in cmake directory. (see #1)
* Add mandatory requirement diff for POCO framework to DNSSD cmake can be work correctly. (see #1)
* Update README.md
Add cmake build way.
* Update README.md
Minor change.
* Update README.md
Removed ambiguous sentence.
* Moved files
* Add cmake modules
* Add cmake modules
* Remove modules
* Correct linux cmake ci.
* Exclude DNSSD from macos, windows.
* Update CMakeLists.txt
* Remove unused gitignore
* Remove deprecated vs versions
* Add vs160 and vs170 for DNSSD
* Remove deprecated sln
* Revert bad changes
* Revert bad changes
* chore: remove vs90 sln files
* chore: remove vs90 x64 files
* Revert "chore: remove vs90 sln files"
This reverts commit 51d78f82f1.
* chore: add DNSSD to components
* chore(DNSSD): disable in CI, update copyright and doc
* fix(DNSSD): CMake on Apple platforms: fix finding library providing DNSSD.
* fix(DNSSD): Handle kDNSServiceFlagsNonBrowsable that was removed in 1096.0.2
* chore: naming and code modernize review comments
* enh(DNSSD): Define DNSSD_*_API for non-MSVC compilers.
---------
Co-authored-by: Günter Obiltschnig <guenter.obiltschnig@appinf.com>
Co-authored-by: <soroosh@soroosh-pc.localdomain>
Co-authored-by: Seyyed Soroosh Hosseinalipour <soorosh_abi@hotmail.com>
Co-authored-by: Matej Kenda <matejken@gmail.com>
209 lines
9.9 KiB
Plaintext
209 lines
9.9 KiB
Plaintext
DNS Service Discovery and Zero Configuration Networking Overview
|
|
DNS-SD
|
|
|
|
!!!Introduction
|
|
|
|
A growing number of embedded devices are connected to TCP/IP networks.
|
|
And many of these devices are no longer passive network nodes, waiting
|
|
for someone else to control them. They are full-blown network citizens,
|
|
actively communicating with their peers and often relying on the network
|
|
services provided by other devices to do their job. For this to work,
|
|
all these devices must be configured properly. Configuring the network
|
|
parameters (e.g., IP address, netmask, etc.) of a device is a tedious task,
|
|
as many devices do not have an appropriate user interface to do this comfortably.
|
|
This is especially an issue with consumer devices, where the user might not even have the
|
|
necessary technical knowledge to configure such a device. And as the
|
|
number of devices in a network grows, configuring each device separately
|
|
is no longer practical. There from comes the need for the automatic
|
|
configuration of network devices and the automatic discovery of network
|
|
services. In recent years, the industry has come up with a variety of
|
|
different technologies and specifications to address this.
|
|
|
|
|
|
!!!Fundamental Issues
|
|
|
|
Generally, there are three fundamental issues that must be dealt with
|
|
for the automatic discovery of network devices and services, and three
|
|
more issues that must be dealt with for the actual invocation or use of
|
|
the discovered services.
|
|
|
|
|
|
!!Address Assignment
|
|
|
|
Every device must be assigned a unique network address. In case of
|
|
TCP/IP networks this can be done with the help of a DHCP (Dynamic Host
|
|
Configuration Protocol) server. Should, however, no DHCP server be
|
|
available (for example, in typical home user networks), another way of
|
|
assigning an IP addresses must be found. Apart from manual
|
|
configuration, which is often undesirable, a method called APIPA
|
|
(Automatic Private IP Addressing, or AutoIP for short) is used. In this
|
|
case, a device's TCP/IP stack randomly chooses an IP address in the
|
|
private (link-local) IP address range 169.254.0.0 to 169.254.255.255. To
|
|
prevent two or more devices from accidentally selecting the same address,
|
|
each device must probe, using the ARP (Address Resolution Protocol),
|
|
whether the chosen address is available.
|
|
|
|
|
|
!!Name Resolution
|
|
|
|
Whenever a user (or device) wants to access another device over the
|
|
network, he usually wants to refer to the device by its name, not by its
|
|
IP address. In a typical TCP/IP network, a DNS (Domain Name System)
|
|
server is used to map domain names to IP addresses. Again, if no DNS
|
|
server is available, such as in a typical home network, another way of
|
|
resolving names to IP addresses is required. Multicast DNS (mDNS), as
|
|
used by Zeroconf, is such an alternative technology.
|
|
|
|
|
|
!!Service Discovery
|
|
|
|
A user or device must be able to find a service provided by one or more
|
|
devices in the network. The important part here is that the user (or
|
|
device) usually does not care which device implements the service, as
|
|
long as the service with specific properties is available and
|
|
accessible. A typical example for service discovery is: <*I need to print
|
|
a document in color. Give me an IP address and port number where I can
|
|
send the print job to, using the Internet Printing Protocol (IPP), so
|
|
that the document will be printed in color.*>
|
|
|
|
What all technologies for service discovery have in common is, that they
|
|
make use of IP multicasting. IP multicasting uses addresses in a special
|
|
address range (224.0.0.0 to 239.255.255.255). A packet (typically, a UDP
|
|
packet) sent to a multicast address is received by all hosts listening
|
|
to that specific address.
|
|
|
|
Service discovery is implemented in the following way:
|
|
|
|
- An application or device that needs a certain service sends a request
|
|
describing the required properties of the service to a specific multicast
|
|
address (and port number).
|
|
- Other applications or devices on the same network receive the request,
|
|
and if they provide the requested service themselves (or know another device
|
|
that implements the service), respond with a message describing where the
|
|
service can be found.
|
|
- The application or device searching for the service collects all responses,
|
|
and from the responses chooses the one service provider it is going to use.
|
|
|
|
In addition, devices that join or leave a network can send announcements to other
|
|
devices describing the availability of the services they provide.
|
|
|
|
|
|
!!Service Description
|
|
|
|
Once a certain service has been discovered, it may be necessary to
|
|
obtain more information about the service. For example, if a service
|
|
consists of multiple operations, it is necessary to find out exactly
|
|
what operations are supported, and what arguments must be passed to
|
|
them. This is the purpose of service description.
|
|
|
|
In case only well-defined service protocols are used (e.g., HTTP,
|
|
Internet Printing, or media streaming), service description is not
|
|
necessary, because the only information needed to access the service is
|
|
the network address (IP address and port number, or URI), and this
|
|
information can be obtained by service discovery. In other cases, the
|
|
information obtained via service discovery is insufficient to
|
|
successfully access the service. In such a case, service discovery only
|
|
returns the address of a network resource that provides detailed
|
|
information about the capabilities of the service, and how to access
|
|
them.
|
|
|
|
|
|
!!Service Invocation
|
|
|
|
After an application has obtained enough information about the services
|
|
it wants to access -- either via service discovery alone, or together
|
|
with service description, the application will access or invoke them.
|
|
This is usually beyond the scope of most service discovery technologies,
|
|
and the domain of specialized technologies and protocols. Examples for
|
|
such technologies are HTTP (HyperText Transfer Protocol), SOAP,
|
|
Java RMI (Remote Method Invocation), CORBA (Common Object Request Broker
|
|
Architecture), or media streaming protocols such as RTSP
|
|
(Real Time Streaming Protocol).
|
|
|
|
|
|
!!Service Presentation
|
|
|
|
Some technologies (UPnP and Jini) provide facilities to present a device
|
|
specific user interface to the user, via another device (e.g., a central
|
|
management workstation, the user's PC or TV set). Such a user interface
|
|
can be used to allow the user to directly interact with a device, in
|
|
order to configure it, or to use some of its functions not available
|
|
otherwise.
|
|
|
|
This requires that the user interface is implemented in a device
|
|
independent way. One way to do this is to implement the user interface
|
|
in HTML (HyperText Markup Language), served by an embedded web server
|
|
built into the device. Another way is to implement the user interface in
|
|
Java, so that it can be run everywhere a Java Virtual Machine is
|
|
available. The user interface code than talks to the device over a
|
|
network connection, using a possibly proprietary protocol.
|
|
|
|
|
|
!!!Zero Configuration Networking (Zeroconf)
|
|
|
|
Zero Configuration Networking (Zeroconf) is a technology originally developed
|
|
by Apple and promoted under the trademark name Bonjour. Zeroconf is
|
|
built upon technologies known as multicast DNS (mDNS) and DNS
|
|
Service Discovery (DNS-SD), which themselves are based on the proven
|
|
DNS protocol. Its most popular uses are in network printers, network
|
|
cameras and for sharing music using Apple's iTunes music jukebox
|
|
software. Open source implementations are available from Apple and
|
|
others for all important platforms.
|
|
|
|
Zeroconf uses DHCP and AutoIP for address assignment if no DHCP server
|
|
is available. A special variant of the well-known DNS protocol,
|
|
multicast DNS, is used for name resolution in case no DNS server is
|
|
available. In mDNS, a name resolution query is sent not directly to a
|
|
DNS server, as with traditional DNS, but to a multicast address. All
|
|
network devices supporting Zeroconf and listening to this multicast
|
|
address respond to name resolution queries, if they have the requested
|
|
information.
|
|
|
|
Finally, for service discovery, an extension of the DNS protocol called
|
|
DNS Service Discovery is used. DNS-SD can be used both with multicast
|
|
DNS (the usual way), or with traditional unicast queries to a DNS
|
|
server. With the additional support for DNS Update and DNS Long Lived
|
|
Queries, two extensions of the DNS protocol, Zeroconf can be used to
|
|
announce services across the global internet. In this case, an ordinary
|
|
DNS server is used to make the service information available. Periodic
|
|
automatic updates of the DNS server's database ensure that its service
|
|
information is up to date.
|
|
|
|
A major advantage of Zeroconf is that it is based on proven technology.
|
|
Also, it can be implemented in a very resource efficient way, making it
|
|
a good choice for resource constrained embedded devices.
|
|
|
|
Beside heavy use by Apple in many of its applications for Mac OS X and
|
|
Windows (iTunes), Zeroconf is popular among manufacturers of printers
|
|
and network cameras.
|
|
|
|
|
|
!!Zeroconf Implementations
|
|
|
|
Two implementations of Zeroconf are currently in widespread use.
|
|
|
|
Apple's Bonjour was the first implementation of Zeroconf. The
|
|
implementation is available under an open source license and
|
|
can be used on different platforms like Mac OS X, Windows, Linux or
|
|
VxWorks. Bonjour is an integrated part of Mac OS X and iOS.
|
|
A Windows installer (and SDK) is available as well.
|
|
|
|
Avahi is another open source implementation of Zeroconf, targeted
|
|
mostly at Linux, although it can also be used on other POSIX platforms
|
|
like FreeBSD or Solaris. Avahi has been integrated into many
|
|
Linux distributions such as Debian, Ubuntu, SuSE and others.
|
|
|
|
|
|
!!The POCO DNS-SD Library
|
|
|
|
The POCO DNS-SD library provides an easy-to-use
|
|
and unified programming interface for integrating Zeroconf features
|
|
(service discovery and host name resolution) into a C++ application.
|
|
The library does not implement its own mDNS and DNS-SD protocol stacks,
|
|
but rather uses an existing Zeroconf implementation for that purpose.
|
|
Apple's Bonjour and Avahi can be used as backend for the DNS-SD library.
|
|
|
|
A great advantage of the library is that it provides a unified
|
|
programming interface. For the programmer, it's completely
|
|
transparent whether Avahi or Bonjour is used as backend.
|