In the first blog about our new Bonjour Gateway, I wrote about why the feature was special. Many of those advantages come from the hard work of building a robust Bonjour foundation for protocol-level intelligence.
Why did we build so many protocol smarts into this feature? After all, Bonjour is easily described at the IP layer. Advertisements go to the multicast IP address of 18.104.22.168 on a well-known port. It is possible to simply take all the multicast DNS traffic and flood it through the network. Early in the development of the Bonjour Gateway, we considered taking the easy way out and just flooding multicast frames.
The advantage of simple multicast flooding is that it’s easy to implement. Every service is available on every network. The disadvantage of simply forwarding multicast advertisements is, well, that every service is available on every network. During the research phase for this feature, I visited many customers. For fun (and valuable data points), I measured the number of services advertised with Bonjour on each network. On one network, there were over 400 Bonjour services visible!
Now, having 400-plus services on a single VLAN isn’t a problem. After all, that network was running fine. It’s having 400 services on the first VLAN, another 400-odd services on the second VLAN, and so on. If you blindly share everything, you will give an appropriate meaning to the word “flood” as your network drowns in multicast. (Many switches need to handle multicast frames with the main system CPU instead of in the powerful switch fabric.)
What services are important? Well, I can’t answer that one for you because it depends on what the network is used for. In many networks, AirPlay, the video streaming service offered by an Apple TV, would be considered frivolous and unbusiness-like. However, many schools are using AirPlay to allow teachers to send their display to classroom video display units. Companies are using AirPlay in customer briefing centers to easily switch presenters without fiddling with display cables. Those are part of the core mission, not frivolity.
The announcement that AirPlay is being built into MacOS definitely makes AirPlay an important service across all kinds of customers. Here at Aerohive, we have more Mac users than PC users, and I will not admit how many meetings are delayed to search out a stupid display dongle. Once we can screen mirror using AirPlay from Mountain Lion, we’ll start meetings much faster, and changing who gets to project is even easier.
All this is a roundabout way of saying that knowing what services to share is a critical attribute of our Bonjour Gateway. If you want AirPlay devices visible, you can do that. If you don’t want AirPlay devices visible outside their immediate network, you can do that. If you want only certain AirPlay devices visible, you can do that, too. (If you really want to know, you can write regular-expression style filtering rules to determine what to share with the rest of the network.)
As with the first blog on the Bonjour gateway, this one also comes with a video. You’ll want to watch the previous video first for information on the network setup. Then, you can come back here and watch the video below for a relatively short demonstration of service filtering. (A condensed overview of our Bonjour videos can be found here.) Because the Bonjour Gateway is a full protocol implementation, we can easily screen out unimportant services from being shared with the network: