s
Master’s Thesis
Bonjour - Zero Configuration Networking on Embedded
Systems
Written by: David Österdahl
Performed at: Sony Ericsson Mobile Communications, Lund, Sweden
Supervised by: Department of Communication Systems, LTH
2007-01-25
1
Abstract
This master’s thesis has been performed at Sony Ericsson Mobile Communications in
Lund and attempts to shed light over the Zero Configuration Networking technology
”Bonjour” created by Apple. The purpose is to increase the knowledge of the technology behind it and explore the possible future applications of the Bonjour technology on
embedded devices such as Sony Ericsson mobile phones. Furthermore, the intention is
to create a simple working demo that can show the potential of Bonjour on embedded
devices.
1
Contents
1
Abstract
1
2
Background
5
3
Bonjour and Zero Configuration Networking
5
4
IP Addresses without DHCP
4.1 Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
5
mDNS - multicast DNS
5.1 A crash course in regular DNS
5.2 mDNS . . . . . . . . . . . . . .
5.3 Three types of mDNS queries .
5.4 Getting your own name . . . .
5.5 Making yourself known . . . .
.
.
.
.
.
9
9
10
11
12
12
.
.
.
.
13
14
15
15
16
7
Service discovery in a WAN perspective
7.1 Unicast vs Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Domain enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Dynamic DNS updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
17
17
18
8
The competitor - UPnP
8.1 UPnP in the brief .
8.1.1 Discovery .
8.1.2 Description
8.1.3 Control . . .
8.1.4 Eventing . .
8.1.5 Presentation
6
9
Services - not devices
6.1 The DNS SRV record . . . . .
6.2 Late binding . . . . . . . . . .
6.3 DNS-SD TXT records . . . . .
6.4 Publishing your own services
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
20
20
21
21
Bonjour vs UPnP - pros and cons
9.1 Naming issues . . . . . . . .
9.2 Exclusive features . . . . . .
9.3 DLNA . . . . . . . . . . . .
9.4 Similarities . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
24
24
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
9.5
Summing up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Audio Use Cases
10.1 UC: Streaming - PC to Phone . . . . . .
10.1.1 Short description . . . . . . . . .
10.1.2 Actors . . . . . . . . . . . . . . .
10.1.3 Main Flow Scenario . . . . . . .
10.1.4 Technical notes . . . . . . . . . .
10.2 UC: Streaming - Phone to Phone . . . .
10.2.1 Short description . . . . . . . . .
10.2.2 Actors . . . . . . . . . . . . . . .
10.2.3 Main Flow Scenario . . . . . . .
10.2.4 Technical notes . . . . . . . . . .
10.3 UC: Streaming - Phone to Speakers . .
10.3.1 Short description . . . . . . . . .
10.3.2 Actors . . . . . . . . . . . . . . .
10.3.3 Main Flow Scenario . . . . . . .
10.4 UC: Copy/Copy DRM Phone to Phone
10.4.1 Short description . . . . . . . . .
10.4.2 Actors . . . . . . . . . . . . . . .
10.4.3 Main Flow Scenario . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Imaging/Video Use Cases:
11.1 UC: Stream Video/Images PC to Phone . . . . . . . . . . .
11.1.1 Short description . . . . . . . . . . . . . . . . . . . .
11.1.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1.3 Main Flow Scenario . . . . . . . . . . . . . . . . . .
11.1.4 Technical notes . . . . . . . . . . . . . . . . . . . . .
11.2 UC: Stream Video/images Phone to PC/Media center/TV
11.2.1 Short description . . . . . . . . . . . . . . . . . . . .
11.2.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.3 Main Flow Scenario . . . . . . . . . . . . . . . . . .
11.2.4 Technical notes . . . . . . . . . . . . . . . . . . . . .
11.3 UC: Copy Photos/Movies from PC to Phone . . . . . . . .
11.3.1 Short description . . . . . . . . . . . . . . . . . . . .
11.3.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.3 Main Flow Scenario . . . . . . . . . . . . . . . . . .
11.4 UC: Copy Photos/Movies from Phone to PC . . . . . . . .
11.4.1 Short description . . . . . . . . . . . . . . . . . . . .
11.4.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . .
11.4.3 Main Flow Scenario . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
26
26
26
27
27
27
27
27
28
28
28
28
28
28
28
29
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
31
31
31
31
31
31
31
32
32
32
32
32
32
32
32
33
11.5 UC: Copy Photos/Movies Phone to Phone
11.5.1 Short description . . . . . . . . . . .
11.5.2 Actors . . . . . . . . . . . . . . . . .
11.5.3 Main Flow Scenario . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
33
12 Use Cases Summary
12.1 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2 Imaging/Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3 Legal Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
34
35
35
13 The building blocks of Bonjour
36
14 Porting mDNS source code to the SEMC platform
14.1 Layered layout - easy porting . . . . . . . . . .
14.2 Problems arise . . . . . . . . . . . . . . . . . . .
14.3 Three steps become two . . . . . . . . . . . . .
14.4 The socket interface . . . . . . . . . . . . . . . .
14.5 Modifying the select model . . . . . . . . . . .
14.6 Registering and publishing services . . . . . .
14.7 Summary . . . . . . . . . . . . . . . . . . . . . .
14.8 Conclusions . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
38
39
40
40
41
41
42
15 Final words
44
16 Appendix 1
46
4
2
Background
In todays networked society, the number of devices and gadgets connected to the internet or some other network increases by the day. Computers, printers, digital boxes and
mobile phones are not reserved for engineers and tech-freaks anymore, but has become a
natural part of every man and woman’s life. The functionality of such devices are often
dependent on the users technical ability to configure them properly, and as the number of
devices grow, so does the need for a simple way of getting them to work together without
having to call a man in a white lab coat. One way to achieve that is to use Zero Configuration Networking in more devices. Bonjour is one of the solutions to that problem. It
exists today in computers and various other embedded devices, but at the present time
(December 2006), there are no mobile phones that implement Bonjour.
This master’s thesis focuses on the Bonjour technology and its possible use on Sony Ericsson mobile phones. The competing technology UPnP is briefly discussed and described
and then compared to Bonjour in terms of exclusive features, similarities and differences.
UPnP does not lie in focus for this master’s thesis, but it is still interesting since it aims to
solve the same problems and has the support of several large companies
3
Bonjour and Zero Configuration Networking
Bonjour is Apples open source implementation of the Zero Configuration Networking
technology suggested by the IETF Zeroconf working group created in September 1999.
Bonjour was formerly knows as Rendez-vouz but the name was changed due to a settlement in a naming conflict with Tibco Software inc in 2004. The goal of Zeroconf is to
offer a technology that allows the browsing for and announcing of services on a network
without the need for setup. Bonjour includes the technologies IPv4 local link addressing
(IPv4LL), multicast DNS (mDNS) and DNS service discovery (DNS-SD).
It is not just Apple that are interested in the technology. By the time the Zeroconf working group was finished with its work on local link addressing - IPv4LL - in 2003, it was
included in Mac OS (9 and X), Microsoft Windows (98, ME, 2000, XP, 2003), in every network printer from every major vendor and a variety of other networked products. This
does not mean that they all support Bonjour. What it means is that the all the devices can
acquire an IPv4 address themselves without the need for configuration or a central DHCP
server and some of them support the second and third step of Zeroconf as well.
5
Bonjour is basically a tripod that rests on the following three legs;
1. IPv4 Local link addressing (IPv4LL)
2. mDNS
3. DNS Service Discovery
It tries to solve the ever present equation of making things that ”just work” without the
user having to be an engineer or a tech-freak. The creator of Bonjour, Stuart Cheshire,
states it as [6]
”Zeroconf is the little missing link that makes TCP/IP on the local network as easy
as USB ”
Although the functionality in Bonjour is quite new, the technology is based not on new
custom made protocols but rather on a solid and already present foundation - DNS.
The benefits of this design lays in the fact that DNS already is a widespread technology.
It is one of the Internets core services and has been around since the mid eighties. Thus
there are numerous experts on the protocol already, and most larger companies have their
own DNS-server. That makes Bonjour easy to understand and get to know. There are no
new protocols to learn or implement, only extensions of present DNS.
It has been the aim of Apple all along to make it easy for software and hardware producers
to implement Bonjour into networked applications and hardware. They feel that is the
only way to spread the technology and the main reason for making it open source.
6
4
IP Addresses without DHCP
Every application that wants to communicate with the IP protocol needs an IP address.
This is not something the average user wants to care about and actually not something he
or she really needs to care about. When you are at work or in your home, the IP address
you have is often given to you by means of DHCP. In Zero Configuration Networking
you cannot rely on the presence of a DHCP-server since the system is designed to work
wherever you set up you computer. You don’t know what the network will look like or
even if any network infrastructure exists at the next place you decide to start working
with your laptop. This could be a local café, your school, your friend’s house or any other
location you choose to open your laptop. The allocation of IP addresses in zeroconf therefore happens ”automagically” through the use of IPv4 Link-Logical Addressing. This is
made possible with a smart use of ARP-probes that first check the availability of a pseudorandom selected address in the non-regulated 169.254.x.x area, and then takes control of
that address if it is free. See figures 1 and 2 below.
Figure 1: ARP probe to get IP address. An ARP probe is sent out to establish if the selected IP
address is in use by another interface. Note the 0.0.0.0 in the Sender IP field.
4.1
Conflicts
It might happen that a conflict of interest occurs when you try to allocate a new IP address
for yourself. There are two basic situations where this can take place.
1. Another computer tries to get the same IP at the same time as yourself. How unlikely this may be, it still can occur. Pseudo-random number generators in computers are not perfect randomizers, and even if they were, there would always be a
certain risk that the same number would be selected. In this case the solution is just
to keep on going. At some point, one of the two will think he can use the address
7
Figure 2: Gratuitous ARP after acquired IP. The IP address has been verified as free and the
machine is telling all other machines that it has taken control of that IP by sending a gratuitous
ARP where it fills in the selected IP in the Sender IP field
and start doing so, then he will also respond to the ARP-probe sent by the other.
The other one will then select another address to probe and the problem is resolved.
The faster of the two will win the race.
2. Another computer erroneously sends out packets where he claims to be you by specifying your IP address as the sender. This situation should normally not occur. If
it does, it might be the result of bad code in an application or perhaps a person
configuring the network wrong using manually specified IP addresses.
RFC 3927 [2] states that one way to handle this kind of conflict is by backing down gracefully and letting the other party take control over the IP address in conflict. This might
seem unfair, but it is perfectly logical. Imagine what would happen if both computers
continued the competition for the same IP address. They would be rendered useless on
the network, something that would gain nobody.
The other way is used mainly if the previous owner has open TCP connections it would
rather not lose. If so, he gets to send a single ARP announcement to let the competing
party realize it’s mistake. If the competition continues, the previous owner still must back
off and hence get another IP address.
8
5
mDNS - multicast DNS
5.1
A crash course in regular DNS
The DNS system is a robust distributed database and acts as the translator between names
and numbers on the Internet. It makes humans deal with what we like - names - and
machines deal in what they prefer - numbers. There are DNS queries and DNS replies.
A domain has a file known as a zone file that resides on the DNS-server and controls the
translation between IP addresses and domain names and the other way around. A zone
is often the same as a domain without its sub-domains.
All data in the DNS is kept in Resource records - RR:s. There are dozens of them but only
a handful are used in a widespread way. The most important ones can be divided into
three sub-groups and they are:
Zone
• SOA - Start of authority record - indicates the beginning of a zone and should
occur first in a zone file.
• NS - Name Server record - Defines an authoritative name server for a zone. The
glue that holds the distributed DB of DNS together.
Host
• A - Address record - Maps a hostname to an IP address.
• PTR - Pointer record - Maps an IP address to a hostname (reverse)
• CNAME - Canonical name record - Maps an alias hostname to an A record
hostname (ex www.foo.com mapped onto foo.com)
• MX - Mail Exchange record - Specifies a host that handles email for another
host.
Security
• KEY - Public Key record - Used to associate a public key with a DNS name.
• NXT - Next record - Handles negative answer caching i.e answers like ”host X
does not exist in zone YYY”
• SIG - Signature record - Used to cryptographically sign zone data
The most common usage asks for an A, PTR or CNAME record. This is what happens
when you use the program nslookup in unix or windows to lookup a name.
9
Apollo:$ nslookup www.apple.com
Server: 10.129.0.4
Address: 10.129.0.4 53
Non-authoritative answer:
www.apple.com canonical name = www.apple.com.akadns.net.
Name: www.apple.com.akadns.net
Address: 17.254.0.91
the answer ”non-authorative” means it is a CNAME, an alias for an A record we searched
for. If we instead do the lookup for apple.com we get:
Apollo:$ nslookup apple.com
Server: 10.129.0.4
Address: 10.129.0.4 53
Name: apple.com
Address: 17.254.3.183
You can find a graph of the DNS system in Figure 7 in the Appendix.
5.2
mDNS
After an IP address is acquired, it is time to attach a name to it. On the internet, this is
the task of the DNS system, in the world of Bonjour, it is up to mDNS. mDNS stands
for multicast DNS and is actually an extension of the functionallity of the regular DNS
system. Instead of relying on a number of central servers for the translation of numbers to
names and vice versa, every client is responsible for its own responses. In all clients lies
a mDNS-responder that responds to queries directed to it and handles queries directed to
other clients. This mDNS responder is one of the central building-blocks of Bonjour and
Zeroconf. The address 224.0.0.251 (FF02::FB in IPv6) is reserved for mDNS-queries and all
Bonjour clients listen to that address.
Devices have cache-tables over their last queries and their answers. This reduces the
traffic on the network at the cost of possible stale data, as always when caching data. All
answers to queries have a TTL associated with them that say how long a query should be
considered valid. If the TTL is close to 0, a new query is sent out to refresh it. If there is
no answer, the entry is removed from the cache.
10
5.3
Three types of mDNS queries
There are three basic types of queries that can occur on a Bonjour network, these are:
• one-shot query
This is a regular single mDNS query similar to ordinary DNS queries. The difference
is that the query is sent out on the multicast mDNS address 224.0.0.251 on port 5353.
The answers then arrive as normal DNS packets. If no reply arrives, the query is
resent several times.
• one-shot multiple answer query
This query uses the same sending pattern as before, but is aware that multiple answers may occur (or should occur). It uses a so called known answer list to avoid
that duplicate records are sent on the network. A known answer list is attached to
every query and contains a list of the queries that the host already has gotten answers for. Imagine for instance that the host expects five answers for one query. He
sends out the query and gets only three answers back. He then waits for a period
of time and then resends the query in an attempt to get the last two peers to answer. If no known-answers list was used, then the first three would answer to the
query this time too. This may not be a problem when it is only three peers, but on
a large enough scale, this is a problem for sure. Less traffic implies faster network.
Therefore, the list of already known hosts is attached and those host simply do not
respond a second time if they see their name in that list.
• continuous ongoing queries
Imagine a buddylist in a chat-program (adium, ichat or any other you may think
of) now imagine this application being a Bonjour capable one. The list of users is
depending on the mDNS service to gather information on who is and is not on the
network at the present time. This is data bound to change as people move from one
place to the other or turn their devices on and off without prior notice. Here the
need for rapid updates is apparent. How does Bonjour solve this? The answer is
through repetitive queries. The known answer list is used here too as an important
tool to reduce network load. Also, an exponential back-off algorithm is used instead
of a constant rate one to reduce the load even more. When a client joins a network or
service, it announces its arrival by doing a gratuitous response. It announces departure the same way, but this time the TTL-field is set to 0 which makes all listening
computers delete it from the cache directly. If a client or service should fail to say
goodbye the clean way, the TTL will still make it disappear from the cache, only a
bit later.
Also, for continuous queries, the responses are sent via multicast. This might seem
like a waste of bandwidth at a first glance, but is actually the opposite since all
computers listening on the channel get the response and update their cache-tables
11
accordingly. This might later prevent redundant queries from being sent.
5.4
Getting your own name
When a name has been selected, a mDNS-query is sent out to check if that name is free or
taken. It is sent as a DNS-query of type T ANY which means that if any record matches
that name, that record (and possibly more) is returned. If no reply is returned, the query
is resent after a delay of 250ms, if there still is no reply, another delay of 250ms is initiated
before the third query is sent. If the third query does not render any answers in another
250ms (total waiting-time is now 750ms) you are free to use that name. What if two
hosts should send a query for the same name at the exact same time? Well, it is not very
probable that this event occurs, but if it does, the conflict is settled by using the authoritysection of the DNS-record as a tiebreaker. Values are compared and as soon as a value is
lexiographically greater, the owner of that record wins. That means for instance that in
this case:
apollo.local.
apollo.local.
A 169.254.101.1
A 169.254.200.1
the latter wins since 200 > 101.
5.5
Making yourself known
After you have a name on the network, it is time to let others know you are there. Bonjour
does this by announcing itself on the network by sending a gratuitous multicast DNSresponse that contains all of its resource records in the answer section.
12
6
Services - not devices
When an IP address has been acquired it is possible to start being useful and communicate
with others on the net. Perhaps we want to know what services are available to us on the
net. Is somebody sharing music, a printer or photos for instance? The traditional way to
do this would be by knowing that a service exists, punching in a name or an IP address
and perhaps even a port number before you can connect to that service. When you are
using a networked printer, it is not uncommon that you add it to your favorite printers by
typing its IP address.
This of course works the same day you do it, but there is no guarantee it will work in the
future. The admin of the network might change a faulty NIC on the printer, or maybe
even the printer itself and if DHCP is used, the printer will probably get a new IP address
with the consequence that you will not find it again the next time you need to use it. If it
is a small company, maybe the admin can set the IP manually and keep it unchanged, but
then again, in a big network with hundreds of printers and maybe thousands of clients,
this would probably not be a very time efficient solution.
How can we avoid this? Bonjour favors the usage of services before devices. What this
means is that instead of finding the printers IP, the user knows the name of the printer
and uses that name to access the printer. This way the IP address can change and even
the printer itself can change, but as long as the name stays the same, the printer will be
usable and look the same to the person using it.
Take a webserver, for instance www.foo.com. By writing the name of the server preceded
by a www, you can access thats servers web resources. Today this is nothing we give
much thought to, but what really happens is that we connect to the server’s webservice
on port 80, this is decided for us by the www that maps the request to port 80 on the
webserver. We could also write foo.com:80, but that would be exactly the same thing as
omitting it.
Under the hood lies the DNS-system and the DNS-zone file, it is specified that when a
request for www.foo.com arrives, it is redirected to the same IP as foo.com itself. The
webserver running on the host foo.com then takes all requests that start with www and
redirect them to the webservice on port 80. Your don’t really know what you are connecting to, you just do it.
But what if you don’t even know the name of the service? Maybe you are a consultant
working in a temporary office at a client’s and need to use the printer, how would you
know what printer to use? Bonjour uses a concept known as DNS service discovery to find
all services on the local subnet. This is an extension of the normal DNS system, it does
not replace or threaten the normal operation of the DNS servers but instead it uses the
infrastructure and implementation of the DNS system to spread information about what
13
services are available to a user on the network.
6.1
The DNS SRV record
SRV stands for service and the DNS SRV record is described in RFC 2782. It adds a SRV
Resource record to the DNS standard for the purpose of service discovery and gives a new
way of finding services in a domain.
The format of the SRV RR, whose DNS type code is 33:
\_Service.\_Proto.Name TTL Class SRV Priority Weight Port Target
Service: The symbolic name of the desired service. Ex dacp, ldap
Proto.Name: The symbolic name of the desired protocol. Ex TCP or UDP
TTL: The ”best-before” stamp of the information in the query.
Class: IN - Internet. see RFC 1035 for more detail.
Priority: Lower priorities must be contacted before higher
Weight: If the priorities are the same, weight is used instead
Port: 0-65535
Target Domain name of target host. ”.” means the service name is reserved but not
available on this system.
A SRV query tells us the hostname of the machine and the port-number of the queried
service. The query could generate multiple SRV records since a machine could have several services running for e.g tolerance reasons. In that case it doesn’t matter which one the
client picks. So far it is all standard DNS, but DNS-SD takes it one step further by adding
the ability to present a list to the user so that he can choose which service to use. This also
makes an indirect demand on the service names to be of a clear and descriptive kind and
the use of long file names and special characters are allowed thanks to the UTF-8 standard
encoding. This facilitates greatly the users pick of service.
The following example is an extract from RFC 2782 and uses the fictional service ”foobar”
to illustrate the use of SRV records;
$ORIGIN example.com.
@
SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
14
NS ns2.ip-provider.net.
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp
SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin’s box and the server
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server
A
172.30.79.10
old-slow-box
A
172.30.79.11
sysadmins-box
A
172.30.79.12
new-fast-box
A
172.30.79.13
; NO other services are supported
*._tcp
SRV 0 0 0 .
*._udp
SRV 0 0 0 .
6.2
Late binding
If a user picks a service to connect to that interests him more than for the moment, for
example the pick of a default printer, this is something you are likely to use several times
in the next few weeks or months. It is important here that the client software stores the
service name and not the device information (such as IP address). IP addresses and portnumbers kan change whereas service names are intended to be stable identifiers for a
given resource. The point being that the translation between name and number (IP) is
done as late as possible to minimize the risk of using stale information.
6.3
DNS-SD TXT records
Just like with the SRV record, the TXT record exists in the DNS standard but DNS-SD
establishes some guidelines about it’s usage to fit the service discovery purpose. The TXT
record exist in DNS-SD to provide more information about each service that is offered
and is optional to use. Each component string in a DNS-SD TXT record consists of a byte
telling the length of the string followed by a key/value pair of some kind. An example
of a TXT record string could for instance be paper=A4 where paper is the key and A4 the
value.
15
6.4
Publishing your own services
Besides browsing, you can of course publish your own services as well. This is made
for you by e.g iTunes when you select the ”share my music” checkbox in the preferences
dialog. You do not have to make any other configuration besides choosing if you want to
share the whole library or just some selected playlists.
This should be the normal behavior towards the end user, as an end user, you can’t really
choose if you want a certain application to announce itself via Bonjour. The support for
that has to be built into the applications. On the other hand, if you are a developer, it’s a
whole new story. As a developer you have the power to choose what applications should
have the ability to announce them selves as services via Bonjour. What service you wish
to expose to other users on the net is totally depending on what kind of applications are
running on the device and which of those it is suitable for others to know about. The list
of existing applications that are ”subject to Bonjourity” can be made very long, but there
are for instance, ftp servers, http servers, different kind of sharing applications such as
music, video and image sharing, printers, scanners to name a few. Basically all network
capable applications that may be of interest for other users on the network is potential
Bonjour candidates.
It is fairly easy to add Bonjour functionality to an existing application given the fact that
you have access to the Bonjour API on your platform. Bonjour is currently delivered by
Apple for the platforms OS X (built in), Windows (installable file), different Unix flavors
(installable file), and VxWorks (installable file). If your platform is not in the list, your
are free to implement you own version of Bonjour. This is possible since Bonjour is Open
Source and hence you have full access to the source code.
16
7
Service discovery in a WAN perspective
You can’t help but think that it would be very nice to take all this connectivity to a more
”populated” area than your present LAN and luckily this too is possible with the Bonjour
Zeroconf technology. Zeroconf was made to work primarily in a ”close” environment, but
this definition today is a bit fuzzy since we get more and more connected every day.
7.1
Unicast vs Multicast
When you use Bonjour/Zeroconf in your LAN, your DNS-SD is working with multicast
DNS. This is ideal for smaller networks since the software does not have to figure out
where it should send the packets, but just sends them on a channel that all interested
parties listen to. This is obviously not a good strategy for larger networks. The solution is
simple, we just move from mDNS to DNS, from multicast to unicast. DNS-SD was built
to work with both of these technologies and the only real difference is that unicast DNS
requires some configuration on the router side before it can be put to use.
7.2
Domain enumeration
When a user browes a domain he gets results based on what services are advestised in the
domain he browses. On a local basis it is pretty logical what domain is being browsed,
but in a wider perspective, something is needed to select a domain to browse. Of course
the user could do this, but that contradicts the zero configuration bit in zero configuration. This leads us to Domain Enumeration. DNS-SD performs five queries of Domain
Enumeration:
• Where are interesting domains to browse
b._dns-sd._udp.<domain>.
• What is the recommended domain in that list
db._dns-sd._udp.<domain>.
• Where are recommended places to register my services
r._dns-sd._udp.<domain>.
• What is the recommended domain in that list of places
dr._dns-sd._udp.<domain>.
• Are there any additional domains in addition to the local domain (for legacy users)
17
lb._dns-sd._udp.<domain>.
By learning pieces of information about the network topology from the configuration it
has been assigned, (DHCP, DNS, Netmask etc) the client builds its DNS-SD Domain Enumeration queries and checks for answers to the questions above.
7.3
Dynamic DNS updates
When a computer moves in and out of different networks and at the same time offers
sevices published via Bonjour, it is easy to understand that there is a bit of a problem.
DNS was originally built to contain records that does not change on a regular basis. The
DNS records that determine what service or hostname that maps to what IP address easily becomes stale when a computer moves between networks and this is why Dynamic
DNS updates are used to inform the network and update the information in the DNS
database.
You still take your name and your servicenames with you when you change your IP address and since Zeroconf networking imposes the usage of service names instead of IP
addresses as mentioned before, the connectivity of a service is maintained as long as the
DNS record of name-IP mapping is kept up to date.
18
8
The competitor - UPnP
8.1
UPnP in the brief
UPnP or Universal Plug and Play, is an alternative to the Bonjour Zeroconf solution provided by Apple. The UPnP technology is the product of the UPnP forum and is pushed
primarily by Microsoft. It shows both similarities and differences towards Bonjour. The
”universal” part comes from the fact that no device drivers are needed and that common
protocols are used such as HTTP, XML in conjunction with SOAP, UDP and IP
UPnP does not adopt the use of DNS/mDNS for service discovery like Bonjour does, but
instead relies upon ssdp - Simple Service Discovery Protocol to handle it’s service discovery needs. The UPnP forum itself states their function as:
”The UPnP Forum seeks to develop standards for describing device protocols and XML based
device schemas for the purpose of enabling device-to-device interoperability in a scalable networked
environment”
UPnP in short is this: First get an IP-address via 1) DHCP or 2) AutoIP. The addressing
scheme in AutoIP is exactly the same as in Bonjour and hence uses ARP probes to find
a free IP-address to use and then claims it by a gratuitous ARP request. After this, the
networking part can begin.
Given an IP address the next steps are described below:
8.1.1
Discovery
Discovery:Advertisement UPnP uses SSDP - Simple Service Discovery Protocol for service discovery. SSDP includes multicast discovery support just as mDNS. When a new
device is added to a network it advertises its presence and its services by sending NOTIFY ssdp:alive packets to the address 239.255.255.250. Any control point on the network
can then listen in and gather information about the new device.
When a device leaves a network, it advertises this by sending NOTIFY ssdp:byebye packets
in the same mulitcast manner.
Each discovey message contains four major components:
1. a potential search target, sent in a NT header
2. a composite identifier for the advertisement, sent in a USN header
3. an URL for more information about the device, sent in a LOCATION header
19
4. a duration for which the advertisement is valid, sent in a CACHE-CONTROL header
Discovery: Search: Request When a control point is added to the network, it wants information about existing services that might be of interest to it and sends a search request
of type M-SEARCH ssdp:discover via multicast 239.255.255.250:1900. Since the search requests are sent via the unreliable UDP, the specification states they should be resent periodically as a safety precaution to guarantee the reception of M-SEARCH request on the
network.
Discovery: Search: Response When a device receives a search request, it must send a
response to the source IP address and port of the device that sent the request out on the
multicast channel. The response follows the same pattern as the NOTIFY ssdp:alive listed
above except for the NT header is an ST header here.
8.1.2
Description
After one device finds another on the network, it needs more information about it. The
way to get this in UPnP is to issue a request for a description of the device. Descriptions
are really XML files that give more detailed information about the devices and services
that they offer. There are two types of descriptions:
Description: Device description A device description is written by an UPnP vendor and
is usally based on a standard UPnP device template produced by a UPnP Forum working
committee. It includes manufacturer information as the serial number, the manufacturer
name, model name, model number, URLs to vendor-specific websites and so on.
Description: Service description The service description is based on the same foundation
as the device description but with a different content. It includes a set of commands and
actions the service responds to, and also a set of arguments for each action. It also includes
a set of variables with data type, range and event characteristics that describe the service
at runtime.
8.1.3
Control
If a control point is aware of a device and its services, it can ask those services to perform
actions on its behalf and then poll the devices for their state variables that tell the control
point the result of the action that was performed. This is the remote controlling function
similar to RPC offered in UPnP.
SOAP - Simple Object Access Protocol defines the use of XML and HTTP for remote procedure calls. UPnP uses SOAP to deliver control messages to devices and return results or
error back to control points.
20
Control: Action: Invoke To invoke an action on a service, a control point sends a request
in the HTTP POST format. If this is rejected with ”405 Method not allowed” then the
control point must send a M-POST and MAN instead.
Control: Action: Response The service must complete the action and respond e.g with
a ”HTTP 200 OK” within 30 seconds including transmission time. If the service fails to
respond within this time, what the control point does is application-specific.
Control: Query: Invoke This command is sent when a control point wishes to check the
status of a certain state variable at the service, for instance to check the status of the service. Only one variable can be queried per message and hence multiple messages must
be sent to query several variables at a service. The format is HTTP POST here too and as
before, if the request is rejected with ”405 Method not allowed”, the control point must
send a M-POST and MAN instead
Control: Query: Response To answer a query for the value of a state variable, the service
must also respond within 30 seconds including transmission time as before. If this is not
done, what the control point will do is application specific. If the service cannot provide
a value for the variable, a response must be sent within 30 seconds, including expected
transmission time.
8.1.4
Eventing
This is a natural succession to the Control functions. If a control point attaches to a service,
it is probably interested in the state variables of that service. By using eventing, the control
point can ”subscribe” to state variables and get the service to send updates when these
variables change. The control point can listen quietly instead of polling very often.
A subscription message is a request to receive all event messages, not just a selected few.
No mechanism exist to subscribe to a selected part of the event messages.
The list of subscribes is maintained and updated via subscription renewal, cancellation
and event messages that control the questions of when, who and what the subscription is
about.
8.1.5
Presentation
If a device has an URL for presentation, the control point can access this URL and use the
presentation service to control the device. The device description is delivered via a description message and retrieving a description message is a simple HTTP-based process.
The control point issues a HTTP GET request to the presentation URL and the device
returns a presentation page.
21
9
Bonjour vs UPnP - pros and cons
One thing that at first glance may seem to favor UPnP before Bonjour is the fact that UPnP
is more adopted and has the support of numerous big companies on the market such as
Microsoft and Logitech whereas Bonjour originates from Apple only.
By more adopted I mean that there are several media units on the market today marked
”UPnP Compliant” or ”UPnP Compatible”. Bonjour also has some media devices on the
market today such as NAS - network attached storage units but there are not nearly as
many devices as for UPnP. On the other hand, Bonjour is already embedded in almost
all new printers produced today to facilitate the discovery of new printers in the network.
Also, UPnP seems to be growing in popularity, but so is Bonjour. At WWDC - Apples
annual developer conference, some examples of coming and present third party Bonjour
products where shown. The most innovative one of these may have been the small prototype SD memory card for digital cameras with built in WiFi and Bonjour! Apples Stuart
Cheshire demonstrated how it works by taking some pictures of the audience using a digital camera and the prototype SD card. The images where then automatically uploaded
and imported to his laptop computer running iPhoto by means of WiFi and Bonjour. That
shows the power of Bonjour in conjunction with WiFi and gives a hunch of what the future
has to offer in terms of Zero Configuration Networking.
9.1
Naming issues
Bonjour suffers from the same problems as Apple do - The lack of users in respect to
Microsoft Windows. Steve Jobs estimated the number of registered Mac OS X users in
August 2006 to about 10 Million which he saw as a high number. The same number for
Windows is approximately 600 Million. The shortage in users affects new technology in
the expected way, fewer people know Bonjour/Rendez-vous than UPnP.
The name UPnP itself has a big advantage. It has the letters PnP in it. Although it has
nothing formally to do with the Plug and Play technology, the name implies that it has,
and therefore users tend to think of it as having the same properties and advantages as
PnP that they already know of. Bonjour does not really say anything about what it can
do. Zero Configuration Networking does say a little more, but may seem to be complex
for the end user judging from the name.
Plug and Play is a well known term in the PC world and is associated with ease of use and
simplicity in general. To plug in a device and have it work at once without the need to
install drivers is something we all want. The term Plug and Play is often associated with
22
Microsoft and the launch of Windows 95, but similar technology has been in Apples Mac
OS since before Windows 95.
9.2
Exclusive features
One advantage in UPnP is the ability to present a kind of descriptive page for each published service. That page can be a simple html page with links to functions on the device.
That gives the user of the service a good overview of what that service has to offer and
could be a good interface towards the user e.g in mobile devices. Bonjour has the ability to publish http services, but does not have this descriptive function for each service
published. UPnP uses XML to describe what a device can do and how it does it. That is
an advantage in the way that XML already is a standard for describing and categorizing
information on the web.
UPnP
• Uses XML for descriptions, an easy to work standard for marking up text.
• Includes profiles to control a device remotely
• Browses by device - then by service (like bluetooth)
On the Bonjour side, the perhaps biggest advantage over UPnP is that Bonjour browses
for services, not devices. This means that you do not have to search through all devices
running Bonjour on the network and ask each one if they support that service you are
looking for. Instead you look directly for the services you are interested in may it be
printing, photo sharing, httpserver etc. Furthermore you leave it up to the application to
decide what service or services it is interested in. Bonjour also tries to minimize the network load by actively avoiding to flood the network with redundant service information.
This is achieved by using a ”known answers list” (see 5.3 - ”Three types of mDNS queries”)
which is sent out with each query and stops the redundant information from being sent
in the query response. UPnP does not have this restraint but instead keeps pumping out
the redundant information on the network.
Bonjour
• Built on DNS - a well known internet standard.
• Reduces network load by using known answers list
• Browses by service - not by device
23
9.3
DLNA
DLNA or Digital Living Network Alliance is an interest group with some of the largest
consumer electronics and computer companies as members. They provide guidelines
for products and what they should support to make it a better experience to the end
users. Apple is not a member of DLNA and one of the reasons is probably the following
statement from DLNA[8]:
”The DLNA expects UPnP to be the primary media management and control standard for products
that are built using DLNA guidelines”
This is not in line with Apples Bonjour project at all. Further it is a threat to Bonjour in
the sense that DLNA has some powerful members that manufacture products for a very
large number of customers. This is emphasized by mentioning some of DLNAs members
Microsoft, Nokia, Intel, HP, Sony, Motorola.
DLNA has a clear profile towards the public and developers. They have a structured website that contains documents including use-cases and specifications needed to develop
software according to their specifications. Bonjour does have a website but is not as clear
in its statements of what to do and how to do it. Additionally, DLNA has managed to get
the interest of many companies in the computer business and that speaks for them as a
future surviving standard.
DLNA will surely be an increased competitive factor for Bonjour. It is likely that DLNA
in the long run may increase the pressure on Apple to work more actively to introduce
Bonjour in more devices for the consumer market, something the Bonjour technology
would benefit from.
9.4
Similarities
It is easy to forget the similarities in Bonjour and UPnP. Since they try to solve the same
problems, you automatically think of them as Windows vs Apple or as two solutions that
exclude each other. But they are not all that different. For instance they both use link local
addressing to get an IP address when there is no DHCP server around.
In fact Bonjour and UPnP can coexist on the same device. They listen on different multicast channels but have the same range of IP addresses. That allows one device to run
both Bonjour and UPnP on the same network interface card. That means that the marketing division can get their 600 million potential customers at the same time as they get the
wow-effect of supporting Apple technology. It is a win-win situation.
24
9.5
Summing up
Microsoft has an alternative to mDNS name resolution in the protocol LLMNR - Link
Local Multicast Name Resolution. It is very similar to mDNS but differences include
that mDNS is not standardized while LLMNR is in the process of standardization by the
IETF. The use of .local addresses is unique to mDNS. It lets a device choose an arbitrary
device name in the .local domain to be used in local networks as long as the name is not
already taken by another device on the same subnet. This is considered a problem by
some members of the IETF. At the same time, LLMNR allows a device to pick any domain
name, which some other members if IETF sees as a problem.
Microsoft’s SSDP protocol is supported in Windows and on various DLNA enabled media
systems where it is used for media exchange. DNS-SD is used with mDNS and is built in
to Apples operating system OS X and in many other of Apples products. It is considered
simpler and easier to implement than SSDP because it uses DNS rather HTTP. Many Linux
distributions already include DNS-SD functionality.
Both alternatives lack standardization today and it seems there is more than some dissonance in the IETF workgroups deciding in these matters.
A big distinction between UPnP and Bonjour/Zeroconf is that the latter tries to be lightweight
by using tiny DNS packets that provide service location and name resolution while the
previous use heavier protocols such as HTTP and XML and wishes to define exactly how
the services should be accessed. UPnP has four device control protocols Internet Gateway
Device, Media Server/Media Renderer, Printer Device and Scanner. To be labeled UPnP
compliant, a device has to conform precisely to one of these DCP:s.
Zeroconf on the other hand relies on existing protocols. It lets the application decide
which one is appropriate in the case of a device supporting several protocols.
Bonjour and UPnP can co-exist in a device given the fact that all needed protocols are
implemented.
10
Audio Use Cases
Note: Although other IP-bearers are possible, All use cases below assume the presence of WiFi in
the Phone
25
Figure 3: The use cases for audio. A star in the lower right corner indicates a ”hot” use case.
Prioritation order for use cases is darker color - higher prioritation
10.1
10.1.1
UC: Streaming - PC to Phone
Short description
Streaming music from your home media center / PC (large storage) to the mobile phone
via wireless (WiFi) connection. The user can enjoy music through the mobile phone anywhere in the apartment/house within range from his (or someone else’s) network.
10.1.2
Actors
User - PC (Media Center)
10.1.3
Main Flow Scenario
You are at home in your house, it is cleaning day again and you have the duty of vacuuming all of the house and cleaning the garage from what someone called ”scrap lying
26
around”. You decide that this is a task that requires music, and you grab your mobile
phone, put on your earphones. You then navigate from the media player to the shared library on your home media center, select your favorite cleaning music and start the cleaning.
When you finished inside the house, you step outside to the garage, still listening to the
music from your computer. When you are almost done, you get an incoming call from a
friend, the music stops while you talk and then resumes directly again when the call is
terminated.
10.1.4
Technical notes
Apples protocol daap is a well established protocol for streaming music from iTunes
shares and would work well here. iTunes has somwhere between 100 and 200 million
users today depending on how you count it [7]
10.2
10.2.1
UC: Streaming - Phone to Phone
Short description
Streaming music between two phones, ad-hoc-style, allows for two or more users to listen
to the same music. It also allows one user sharing his music to listen to what he or she
wants while at the same time another user can remain connected to the shared music and
listen to something completely different. (iTunes)
10.2.2
Actors
User - User
10.2.3
Main Flow Scenario
You are riding the train with a couple of friends, on your way to a Robbie Williams concert.
You have an open beverage of your choice in your hand, but naturally you want to listen
to the music to get in the mood even more. So does your friends. Luckily, you all have the
latest phone from Sony Ericsson with Bonjour music sharing built in. You enter the media
player start the playback of your favorite Robbie album, press the ”More” key and select
”Share live music” from the menu. The others start their media players and select ”Shared
music” and then the ”Live music” active playlist where they pick your name. Now you
27
have the same music in your ears and continue to enjoy your drinks on your way to the
concert.
10.2.4
Technical notes
Works both for 1-1 and 1-several.
10.3
10.3.1
UC: Streaming - Phone to Speakers
Short description
Streaming of music from the phone to wireless capable speakers (airTunes)
10.3.2
Actors
User
10.3.3
Main Flow Scenario
You come to a party that is totally dead and has the wrong music playing. You at once
realize the problem and start saving the saturday night by compiling the perfect partykicking playlist in your phone. After that, you set the output speakers in your media
player to your poor friends’ airTunes speakers and start playing your music. Of course
it is a success, the kitchen becomes a dance floor in minutes and you smile and express a
quiet thank you to the brilliant engineers that thought of this idea.
10.4
10.4.1
UC: Copy/Copy DRM Phone to Phone
Short description
Users are able to copy music files between their phones. This can be DRM protected files
or not, but if they are DRM protected, perhaps it is more appropriate to be transfer a link
to the distribution site.
28
10.4.2
Actors
User - User
10.4.3
Main Flow Scenario
You want to share some music with a friend. You enter either you media player or your
file browser on the phone, select more -¿ sharing and then select the objects you want to
share. Your friend can then navigate to the shared music either by selecting it from the
file browsers ”Online shares” directory and selecting your phone, or by connecting to you
through the media player and then choose to save music.
29
11
Imaging/Video Use Cases:
Note: Although other IP-bearers are possible, All use cases below assume the presence of WiFi in
the Phone
Figure 4: The use cases for video and pictures. A star in the lower right corner indicates a ”hot”
use case. Prioritation order for use cases is darker color - higher prioritation
Note: The following use cases mention both TV and PC. These two units will most likely merge
more and more as time goes by and therefore there is bound to be some overlapping of use cases
here.
11.1
11.1.1
UC: Stream Video/Images PC to Phone
Short description
The user can stream video (or images) from his media center at home to his mobile
phone
30
11.1.2
Actors
User - PC
11.1.3
Main Flow Scenario
You are in bed on a weekend morning, you want to watch you favorite saturday morning
video podcast that has been downloaded automatically to your media center, but the
living room feels very cold and far away compared to the warm cosy bed. So you grab
your phone from the night-stand and start the media player, and after selecting your
home media center you navigate to streaming media where you find your video podcast
waiting for you.
11.1.4
Technical notes
Bigger screens in the devices and the entry of mobile TV will change the user habits and
make the user more inclined to watch video content in the phone.
11.2
11.2.1
UC: Stream Video/images Phone to PC/Media center/TV
Short description
The use can stream video or photos from the phone to another screen connected to a
PC/media center.
11.2.2
Actors
User - PC
11.2.3
Main Flow Scenario
You are sitting in the couch at a friends apartment. You both feel like watching a movie,
but nothing good is on, and your friend has not been downloading any movies in ages.
Suddenly you remember that you have the brand new Superman movie in your mobile.
It is DRM protected since you bought it online, but that does not stop you from streaming
it via Bonjour technology to your friends Front Row media center and from there on to
his 50” LCD-TV.
31
11.2.4
Technical notes
DRM is not an issue when streaming content with e.g RTSP.
11.3
11.3.1
UC: Copy Photos/Movies from PC to Phone
Short description
The user can copy content from his big media library at home to his mobile device for
bringing along and for later viewing.
11.3.2
Actors
PC - User
11.3.3
Main Flow Scenario
It has been an intense weekend out of town with some of your colleagues and friends from
work, but now it is Monday again and time to get serious. Before leaving the apartment
for work, you copy a couple of episodes from your favorite series and the photos you
took during the weekend to your mobile phone. Later, on the commute, you put on your
wireless headphones and watch an episode of Scrubs on your way to work.
11.4
11.4.1
UC: Copy Photos/Movies from Phone to PC
Short description
When you enter for instance your home network with your phone loaded with new pictures, it is possible to upload the new pictures to the main media library on the PC directly
from the phone via WiFi. If you subscribe to a media library, you can get a notification
to upload the content as soon as the main library senses that 1) you are in the network 2)
you have new media in your mobile device.
11.4.2
Actors
User - PC
32
11.4.3
Main Flow Scenario
When you have arrived at the office, a notification pops up in your phone asking if you
want to upload your new items to the media library at work. You choose to accept and
transfer the photos via wireless Bonjour technology to the shared photo library so that
everyone can enjoy the nice and embarrassing photos.
* The users subscribing to that shared photo library get a notification that there is new
content available.
11.5
11.5.1
UC: Copy Photos/Movies Phone to Phone
Short description
Users can share their photos and movies between their phones.
11.5.2
Actors
User - User
11.5.3
Main Flow Scenario
You want to share some photos with a friend. You enter camera album, select more ->
sharing and then select the objects you want to share. Your friend can then navigate to
the shared music by selecting it from the camera albums ”Shared photos” directory and
navigating to your device.
33
12
Use Cases Summary
The majority of the high priority use cases in both audio and imaging/video has some
kind of sharing as their common denominator. It is set beyond any doubt that the trend of
sharing your content with friends and even with complete strangers is a growing phenomenon. Some of these use cases, for instance the ”stream listening” case, is made
possible today through the use of computers and specific hardware and software, but
that hardware is still not in every mans home (for instance media centers running Bonjour/UPnP, wireless base stations interfaced with your stereo/media center e.g Airport
Express/Extreme).
I believe that it is only a matter of time before these kinds of gadgets are in every home. It
may not be Bonjour in them all, but for sure, they will be able to communicate with other
devices in your home and make your content available throughout the house/apartment
and perhaps even adding other smart functions to your living experience.
With Bonjour in the phone, possibly in conjunction with UPnP, Sony Ericsson will be
a leading contender on the mobile market for intelligent media devices supporting the
functions of this ”digital home” through the technologies available. It is not only possible
to build new applications with this functionality, but it is also possible to make existing
applications ”speak Bonjour” if the Bonjour framework is made available to the developers.
The value added to the user experience is significant if the user feels the product is not
only good looking and working as expected, but also surprisingly much easier to use than
expected. Zeroconf when put to correct use is that kind of ”I didn’t know it could be that
easy” feeling that every manufacturer should strive for.
The question should not be ”can we afford to put this in the phone”, instead it should be
”can we afford NOT to put this in the phone” as this functionality grows in importance
every day.
12.1
Audio
The ”Streaming - Phone to Phone” simultaneous or listening individually could be implemented in Sony Ericssons media center providing a unique experience for the Sony
Ericsson user to express him/herself and share content at the same time allowing for compatibility with iTunes sharing/streaming (200+ million users worldwide) and the newly
released Appe TV media center, both of course running Bonjour.
The ”Streaming - Phone to Speakers” Phone 2 Speakers use case is also very appealing
and would fit right in to the above suggestion.
34
12.2
Imaging/Video
With the introduction of high-resolution cameras and real flashes in the mobile cameras,
the user is more and more inclined to use the mobile phone camera for the everyday
collection of images, maybe even as primary photographic device. Those images will
eventually fill up the memory in the phone, and hence the need to move them to a larger
storage area emerges. It is also desirable to keep the valuable images in a place not as
exposed to the risk of theft as a mobile phone.
This place of storage will often be the computer at home or in the near future perhaps the
media center at home (or even online). It would be desirable if the action of uploading
those newly collected images to the main library would not take any significant effort
from the user, but instead would be more or less automatic. That can be achieved by
implementing Bonjour as suggested in the use case ”Copy Photos/Movies from Phone to
PC”.
12.3
Legal Notice
To support the Apple protocols for music and image sharing in full, some kind of collaborative action is required since the protocols daap and dpap are proprietary to Apple.
Even without this, it is still possible to create a unique user experience for the Sony Ericsson customer by using open (or SEMC specific) protocols for those functions.
35
13
The building blocks of Bonjour
Bonjour typically consists of three blocks. On top, the application resides. It can be any
type of application that wants to include the Zero Configuration functionality provided
by Bonjour. Apple encourages software developing companies to include the Zero Configuration technology not only in new networked applications, but also in present applications. It is Apples intention that Bonjour should be simple to integrate in an existing
application.
In most cases the application links to the mdnslib library provided by Apple. The library
includes wrapper API functions that in turn speaks to the mDNS core through a daemon running on top of mDNS core. The daemon and the library uses IPC - Inter Process
Communications via Unix domain sockets to communicate with each-other.
The core layer is as the name implies where the core functionality of Bonjour lies. It
includes functionality for DNS-SD, mDNS and uDNS Bonjour features. The core layer is
generic and identical for all platforms.
In the bottom we have the Platform Support Layer. This layer is the glue that connects
the mDNS Core to whichever platform it runs on. Apple provides this ”glue” for some
platforms, Mac OS 9, Mac OS X, Posix (Linux and BSD-compatible operating systems) VxWorks and Windows. If you want Bonjour to run on any other platform than these above,
you must port the Bonjour code by making your own Platform Support Layer.
For small embedded devices with very constrained resources, with a single address space
and (typically) no virtual memory, the daemon and mDNSlib layer may be eliminated,
and the Client Application may live directly on top of mDNSCore. That is the model used
to implement Bonjour on the Sony Ericsson platform in this thesis. It is not as intuitive as
working with the library, methods are more complex and some tasks otherwise performed
by the library and daemon is now the responsibility of the programmer instead. It is more
work to program this way, but it is necessary for the sake of saving resources on small
devices.
36
Figure 5: mDNS using IPC and Unix Domain Sockets to communicate with the core.
14
Porting mDNS source code to the SEMC platform
The mobile phones at Sony Ericsson are not really Posix compliant and therefore to make
them support Bonjour, the code has to be ported to work on the SEMC (Sony Ericsson Mobile Communications) platform. A platform layer that glues the SEMC platform toghether
with the Bonjour core must be provided. The mDNS code is luckily written in C, same as
the SEMC source, so porting between languages is not necessary but rather between the
SEMC API and the mDNS ANSI C code.
There are two approaches to using Bonjour when implementing it on a device. Either
you use the libraries provided by Apple. Then all communications with the mDNS core
is done through these libraries and on to a daemon running on top of the mDNS core.
The other way is to call the mDNS core direct from the client application without using
a daemon at all. The library alternative is certainly more attractive, the commands are
easier and it is wrapped nicely around the mDNS core to make it easy to use for developers.
The downside with the library approach is that the IPC protocol used to communicate
with the daemon over the Unix Domain Socket interface is not supported in OPA. That
37
Figure 6: The basic layers of mDNS used on embedded systems (daemon and lib eliminated).
makes the library solution impossible for use on SEMC phones today. Instead the second
method where the core is called directly from the client application has to be used. This
is recommended behavior for an embedded device with limited resources and no virtual
memory but at the same time requires more work from the programmers side.
14.1
Layered layout - easy porting
The engineers at Apple has made it as easy as possible to port the Bonjour technology to
new platforms by building it in a very layered way. There are basically three layers, the
platform layer, the mDNS Core layer and the application layer. The platform layer is platform
dependent and provides the Core with the functions it needs to send and receive packets,
allocate memory, copy a string etc on whatever platform it may be running. The smart
thing here is that the core is completely platform independent. It is pure ANSI C and will
run on any platform able to run C code.
To port the Bonjour framework, all you really need to do is provide a working platform layer and link it together with the mDNS Core components. That seemed simple
enough.
14.2
Problems arise
The SEMC platform is a very layered environment. Sony Ericsson deals in application
software, not hardware and they trust others to supply them with hardware and the func38
tions that can be expected from such hardware. That means for instance that they do not
write their own TCP/IP-stack, instead they use a predefined interface that in the IP case
maps down to a lower layer.
For this project, it was interesting since the lower layer included the same socket behavior
as in the POSIX port of Bonjour, namely BSD sockets. The original plan for the demo
was to use the underlying layer to replicate as much as possible of the working POSIX
port made available in the Apple Open Source distribution of Bonjour. A small amount
of changes means a small amount of bugs. There were two ways to go. Either start the
porting on the SEMC layer called OPA which would mean more work code wise, or try
to access the underlying BSD socket interface directly. The way of using the underlying
layers seemed appealing both to me and to my supervisor at SEMC and was chosen by us
in conjunction. So I went ahead and started the porting in the sub layers.
However, this presented a lot of problems to me. I was not accustomed to the developing
environment used at Sony Ericsson prior to my arrival there, that meant I needed some
time getting used to it before really getting to work with the problem at hand. Since the
chosen way of working with lower layers directly and omitting OPA is not the intended
way of using the system, the problems came in hundreds in the form of conflicting layers
resulting in redefined pointers, unknown types, unknown include files and here the list
goes on and on. After three weeks, all my efforts had given me nothing but link and
compiling failures and I had to realize that we were going about it the wrong way.
The OPA layer was my only remaining option. On the good side, the three weeks of
problems gave me a better understanding of the code used in mDNS/Bonjour and even
in the SEMC platform. On the bad side, i lost precious time that I would have needed in
the end.
14.3
Three steps become two
The three three steps of Bonjour are
1. Getting an address without a DHCP server
2. Attaching a name to that address and the possibility to perform namequeries without a conventional DNS server (mDNS)
3. The ability to browse and publish services without the need for a central directory
that keeps track of them (dns.sd)
The first was actually fulfilled when i started. Link local addressing is as mentioned in
earlier chapters built into several operating systems such as Windows and OS X. This is
included even in a Sony Ericsson phone. For this project that meant that the porting of
39
Bonjour to the SEMC platform only took two steps instead of three, and seemed even
easier.
14.4
The socket interface
The network functions of Bonjour are built on the BSD socket model that is standard in
most UNIX like operating systems today. BSD sockets follow the same logic as regular
files in a file system. They can be written to and read from, created and deleted using
tools for the purpose. A file on a UNIX system is represented by a file descriptor in the
form of an integer. If that integer is 0, then the file descriptor is empty and the file does
not exist. The same is true for sockets, only here the word is socket descriptor.
In OPA, the socket interface does not follow the same convention. Here the socket interface is called ISocket, and is a pointer type instead of an integer type. Although it rests on
the same foundations as BSD sockets, it does not have all options that the BSD socket implementation does, and it uses different names for everything. This means among other
things that some of the functions and socket options in Bonjour simply cannot be replicated on OPA since the socket interface lacks support for those options. Although those
options does not seem mandatory, omitting them might have a negative effect on the robustness of the implementation.
In Bonjour, there is a need for saving a socket in memory to know whether it is in setup or
non setup state. Later that socket descriptor might be evaluated based on its integer value
and the proper action will be taken. For this to work on OPA, some special structures were
created to store the ISockets in pointer format and at the same time support the functions
needed for Bonjour to work in correct manner. Other modifications include the definition
of common error constants and address groups for use with the sockets.
14.5
Modifying the select model
Bonjour is built to be portable, and one of the decisions that reflect that intention is the fact
that the mDNS Core is not multi threaded. It relies on the client platform for scheduling,
for instance by using a blocking select call to wait for events on a socket. OPA does not
use that approach, instead it relies on callbacks and subscriptions to events. Therefore it
does not even contain a select implementation.
Luckily there are other teams working on IP based technologies at SEMC, and one of these
teams encountered the same problem as me. I was able to use their solution for the select
model and that solved my problem in a rather easy way.
40
14.6
Registering and publishing services
To register a service and have it advertised all you really need to do is call a method.
Either that method is part of a rather intuitive and forgiving API that links to a library
as mentioned before, or it is a method that leads straight into the mDNS core in which
case you have to be more precise and careful about your parameters. In this case it is the
latter.
By calling the function mDNS RegisterService(..) you ask the core to take your parameters and turn them into a service with correct representation in memory and probe the
network for that service name to see if it is already taken. If so, a callback will return an
error code and you may choose to rename and reregister the service again. If the name
is not taken and no other errors occur, the callback could return with a no error status in
which case you would be happy. That means the service is registered and sent out on the
network.
This is where it gets really tricky. The platform layer is called from within the mDNS core
and any error in the platform layer will result in an unpredictable or non-working mDNS
responder. In this implementation, no callbacks are received and no services probe or
otherwise become visible on the network. My conclusion is that there is an error in the
platform support layer which is entirely done by me. I have been hunting that error for
the last 5 weeks of my thesis without success.
Since the call made to mDNS core does not give the expected result, one might argue that
the error could be in the core instead of the platform layer. This is a possible scenario
however unlikely since the core is unchanged and working fine on numerous other platforms and products. It is possible that there is something in the mDNS core that simply
will not work on a SEMC mobile phone without modifications to the core, but the code
in mDNS core is complicated to say the least and therefore beyond the scope of making a
small demo such as mine.
14.7
Summary
During the implementation phase, I ran into numerous problems that in many cases got
solved and in other cases got worked around. Mulitcast IP for instance, was a new experience for me. When you create a multicast socket you create an ordinary socket and
set a couple of socket options to tell the socket to listen on a certain network interface for
traffic on a certain multicast channel. When you bind the socket to your IP address, it will
bind nicely but it will never receive any traffic or send any traffic on the multicast channel
unless the address you bind to is of type INETADDR ANY (0.0.0.0 in ipv4). That took
some time for me to figure out, since the bind command and the setoptions commands all
41
return success and everything seems to be working fine.
Another multicast issue was when mDNS was not acting according to protocol. In standard operation, mDNS is supposed to probe three times for each name it wants to register
on the network. This is done to make sure that the name is not already taken. If no answer
is received, that address is assumed to be unused and an answer packet is sent as reply to
the own probe. This tells other listening clients that the name is in use. My implementation would probe one time, then answer one time, probe one time, answer one time and so
on. After a while it became clear that the reason for this was that my application was receiving its own multicast transmissions and answering them one by one. This was simply
solved by introducing a filter that blocked the own traffic from being processed.
The string format in mDNS is also worth mentioning. It uses a DNS convention standard
in which the first byte of a string determines the length of the string. E.g the string ”hello”
consists of 5 characters. If you think of the string as boxes with one letter in each box, it
might look like this: [h] [e] [l] [l] [o]. The length of this string is 5 and to make it work
with mDNS, it needs to look like this [5] [h] [e] [l] [l] [o] where 5 is the length of the string.
That caused me some hassle in the form of parameter errors before I realized how to use
it.
My goal besides the evaluation of Bonjour and its potential usage at Sony Ericsson was
to complete a working demo of Bonjour running on the phone. That demo has not been
completed. I was able to get 2 of the three steps in mDNS to work, but the service announcement and discovery step still eludes me.
The next step would be to complete the service announcement step. That requires a very
good insight in how the platform support layer handles the information requested by
mDNS core and also, how mDNS core interprets that information. I am convinced that
it is possible to solve, but regretfully my time has run out and I have to leave the matter
unsolved.
14.8
Conclusions
In the end, the real challenge for me was to understand how the creators of Bonjour
thought when they wrote the mDNS core. It is of great help to understand the flow of
data between the platform layer and the mDNS core when trying to find bugs that appear
to be situated in the platform layer. The core is written in very generic C and has numerous more or less mysterious macros and several big structs being passed back an forth,
and the lack of documentation makes it more or less difficult to follow.
Normally in this case you would refer to documentation and previous experiences recorded
by advanced users. These resources are often available on the Internet. In the case of Bon-
42
jour, that simply is not true. There are no forums discussing the development of Bonjour
on embedded devices such as this. In fact, there are no forums discussing Bonjour development at all. The only source of information besides from the comments in the code is
the Apple Bonjour mailing list for developers. It would be a grave understatement to say
that it gives answers in only a few cases.
Since Bonjour is open source, Apple does not support it by regular channels. The only
detailed documentation of Bonjour is the comments inside the code. Of course there are
published specifications of mDNS and DNS-SD published as RFC:s on IETF:s site, but
that’s just is not good enough when you need more specific answers about the code. Apple would have much to gain from supporting Bonjour in a more regular way.
The need for one or more forums discussing the matter is imminent. There are several
posts a week to the list that receive no answer what so ever. It would appear strange
to me if Apple does not act on this need and still wants to work actively to spread this
technology. Mac OS Forge is a new website by Apple for OS X open source projects and is
according to themselves ”dedicated to supporting the developer community surrounding open
source components specific to Mac OS X”. At present day, there is not a single forum on that
site. Perhaps that would be a good place to start, Apple?
43
15
Final words
Bonjour is a very interesting technology, both now and for the future. After all, it provides
what many of us want to have; a more user friendly experience when using networked
technical products and computers. The development of embedded devices such as mobile
phones in the last couple of years show that they will evolve into more and more sophisticated and connected machines. This will inevitably lead to higher demands on the users
technical knowledge.
Bonjour is not the ultimate solution for all network configuration problems or user frustration, but it definitely has the potential both to make things easier for the user and to
offer new interesting use cases for product and software developers. The next couple of
years will show if Bonjour has the ability to gain enough popularity to make it’s way into
our living-rooms and to survive the high demands that the market puts on this kind of
new technology.
In my opinion, it is time to realize that a person using a computer or a mobile phone no
longer is an engineer or a tech freak by default. The equipment, machines and mobile
phones with built in networking capabilities manufactured today has much to gain from
being made more usable not just to technicians but to all persons. User orientated development and an increased focus on usability design should be in the minds of all those
deciding the future of our technical products.
44
References
[1] Stuart Cheshire. Zero Configuration Networking - The definitive guide O’reilly 2005.
[2] IETF Zeroconf group. Dynamic configuration of IPv4;
http://www.ietf.org/rfc/rfc3927.txt
IETF May 2005.
[3] IETF Network working group. Domain Names - Implementation and specification;
http://www.ietf.org/rfc/rfc1035.txt
IETF November 1987.
[4] IETF Network working group. A DNS RR for specifying the location of services (DNS
SRV);
http://www.ietf.org/rfc/rfc2782.txt
IETF February 2000.
[5] IETF Network working group. Secure Domain Name System (DNS) Dynamic Update;
http://www.ietf.org/rfc/rfc3007.txt
IETF November 2000.
[6] Stuart Cheshire et al. Multicast DNS
http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt;
Internet Draft August 2006
[7] iTunes user count
http://www.macobserver.com/stockwatch/2005/10/17.1.shtml;
http://www.wired.com/news/mac/0,2125,69193,00.html
October 2006
[8] DLNA on UPnP
http://www.intel.com/standards/case/case dh.htm
November 2006
45
16
Appendix 1
Figure 7: The hierarchy of the DNS system
46