Imagine a scenario where in you go with your laptop to your client's place and want to use a printer there. How would it be if you just connect your laptop to the local network and your laptop shows you the list of available printers? Say you want to play a network game with your friends. As soon as you connect to the network and open the game you see your friends name on the screen. All this happening without you having to know the IP address and the port number of the host/service you wish to connect to!! All this happening without centralized allocation of network addresses, without name server and without a centralized repository of available services. This simple and reliable way to configure and browse for services and choose one from the list instead of having to know each service's name or IP address in advance is exactly the capability that Bonjour provides.

Bonjour Operations

The Bonjour technique has to accomplish 3 fundamental operations

1. Allow a host to advertise it's service - Publication
2. Give a provision for other hosts to browse for desired services - Discovery.
3. Translate the service name to IP address and port number - Resolution.

Publication

Consider a hypothetical device or a host that can share music over the local network. Let the underlying transport protocol be UDP. Let the name of the application protocol or the service type be 'music' and instance name of the service be 'Hindustani-classical-music'. Any host that queries for a service named 'music' gets back 'Hindustani-classical-music' as one of the instances (there may be similar devices in the same network under the service type 'music' but with different instance name)

Once this device is plugged in to the network a series of operations take place.

1. Address Selection: The device selects randomly a link-local IP address 169.254.170.30 from the IPv4 link-local range 169.254.0.0 with a subnet mask 255.255.0.0., and announces it to the network. If it gets no response to the announcement, it takes the address as it own. If the IP address is unavailable, it should assign itself a new one.
2. Name Selection: The device starts up its Multicast DNS responder to cater to the client's queries, requests the host name Hindustani-classical-music.local., verifies its availability and takes the name as its own. If the name is unavailable it should find a new name. A service record is created by the name Hindustani-classical-music._music._udp.local. This record holds the IP address of the device and the port number on which the service is running. Any host querying for the service 'music' gets the device and service information from this record.
3. Service Startup: The device starts up a music sharing service on UDP port 1125.
4. Service publication: It publishes the service of type _music_udp under the name Hindustani-classical-music in the local domain.

Discovery

Now consider a client application browsing for music sharing services. The client issues a query for service of type _music_udp in the local domain. Every Multicast DNS responder on the network hears this request, but only the music sharing device responds.

Resolution

The resolution begins with a DNS query asking for the Hindustani-classical-music._music._udp.local SRV record. This query returns the host's name Hindustani-classical-music.local., and port number 1125. The client now sends out a multicast request for the IP address. This request resolves to the IP address 169.254.170.30. The client can then use the IP address and the port number to connect to the service.

In iOS

Publishing a service

To publish a service on the network, NSNetService class is used.
The presence can be advertised on the network by publishing a network service when the application has finished launching (application:DidFinishLaunchingWithOptions:).

NSNetService class: netService = [[NSNetService alloc] initWithDomain:@""
type:@"_Music._udp."
name:@"Hindustani-Classical-Music"
port:1125];
The first argument specifies the domain for the service. @"" is used to denote the default domain. The second argument indicates the service type and transport layer. In this example, the name of the service is Music and it uses UDP as the protocol. The service name and the protocol has to be prefixed with an underscore(_) and the protocol ends with a period(.) The third argument specifies the name of the service. Finally, the port number on which the service is published via the fourth argument.

To publish the service, publish method of the NSNetService class has to be used:

netService.delegate = self;
[netService publish];

netService:didNotPublish: method is implemented so that in the event that the service is not published successfully, appropriate alert can be displayed to the user.

When the application exits (applicationWillTerminate:) or goes into background mode
(application DidEnterBackground:) publishing the service has to be stopped:

Browsing for Services

An instance of NSNetServiceBrowser class is created and used to search for the services.

For example,

NSNetServiceBrowser *browser;
browser = [[NSNetServiceBrowser new] autorelease];
[browser searchForServicesOfType:@"_Music._udp."
inDomain:@""];

As services are discovered, the netServiceBrowser:didFindService:moreComing: method will be called. In this method, the discovered services can be added to a mutable array :

The IP address of the discovered service can be resolved by calling the resolveIPhonedress: method. The resolveIPAddress: method uses the resolveWithTimeout: method of the NSNetService instance (representing the service that was discovered) to obtain its IP addresses:

If it managed to resolve the IP addresses of the service, the netServiceDidResolveAddress: method is called. If it did not manage to resolve the IP address, the netService:didNotResolve: method is called

When services are removed from the network, the netServiceBrowser:didRemoveService: method is called. Therefore, in this method the services from the mutable array can be removed.