Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.
Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.
Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and learn more about it. Thanks for reading, and for making the site better!
Startrek.com Shutting Down
People go outside?
agent dero writes "Zero Configuration, more commonly known as "Bonjour" (formerly known as Rendezvous) is a reasonably well known technology but a commonly misunderstood technology. Stuart Cheshire and Daniel H. Steinberg's "The Definitive Guide" aims to walk a user from one end of the spectrum to another, starting with explaining what Bonjour is and isn't, and ending with brief introductions to the C, Cocoa, Java, Ruby and Python APIs for including Bonjour functionality inside an application. In another fantastic "Definitive Guide" from O'Reilly, Cheshire and Steinberg not only explain how the technology works, but reasoning behind some of the design decisions, lessons learned from other technologies (AppleTalk primarily), and how Bonjour truly is one of the tools we didn't even know was missing from the modern networking toolbox.
Stuart originally sent me the book after reading about some of my (primarily) experimental forays into using Bonjour for more than just iTunes sharing. While not too many developers, power-users, or even end-users are familiar with how Bonjour works, they no doubt have seen it in action, whether it be iChat Bonjour Messaging, iTunes Sharing, or the quick setup of their new network-capable printer. The book dives right into explaining what exactly Bonjour is, and the problem Bonjour intends to solve with a common problem even my grandmother can understand, if you set two laptops on a table, why can't they communicate right off the bat with one another? From the end users perspective, they can "see" both of the computers, why can't the computers "see" each other then? It is to this hypothetical naive individual this book seems to be written, as it is equally as frustrating for a software developer as it is for an end user to struggle with some of the issues the ever growing proliferation of networks has presented them. The duo [Cheshire & Steinberg] start to walk the reader through the dark ages, the forlorn days of "platinum" user interfaces, AppleTalk, and the venerable "Chooser."
Early on in the book, the authors cover the primary distinction between Bonjour and previous technologies, citing how it builds on lessons learned from Bonjour's predecessor: the AppleTalk Name Binding Protocol (NBP), where the devices on any given network are of no interest, but the services that those devices provide are. The concept of "late binding" is also borrowed from the AppleTalk Name Binding Protocol; as networks increasingly rely on either link-local addressing, or DHCP leases, there is no guarantee a host will retain an IP address through the duration of its connected life-span. The concept of late-binding is a relatively familiar one, as it is used with the standard DNS system as well, when we browse to slashdot.com, we must resolve the name for a meaningful IP address, but the IP address is not saved and used for subsequent connections, instead, the name will be resolved for its IP address the next time we need it, and thereafter. After the brief introduction to what Bonjour is meant to do, what it is not meant to do, and a bit of historical perspective thrown into the pot, Cheshire and Steinberg discuss the three pieces of the Bonjour puzzle in the remainder of the first half of the book.
When in doubt, link-local
Most reading this are undoubtedly familiar with DHCP, or at least manually assigning their own IP addresses on their home networks, but what happens with the router croaks, you plug one machine into the other, or you are a member of an ad-hoc network? Some way or another a computer needs an IP address to work with before it can really be effective on a network. To explain this, the authors start a common theme that persists throughout the duration of the text, presenting a real-world analogy to the situation, explaining it thoroughly, and then claiming "analogies between computers and day-to-day life generally should not be taken too literally." The analogy presented to explain link-local addressing is of a 65,000 seat auditorium being used for a networking lecture (this must be a joke, as finding a 65,000 seat auditorium is quite difficult, but not nearly as difficult as finding 65,000 people to attend a networking lecture). If each attendee were to choose a random seat number before entering the auditorium, using a keypad outside to validate that the seat number is empty (choosing a new number if it's taken), then the attendees more or less "choose" their own seat while avoiding conflicts, much in the same way that link-local addressing works. Link-local addressing is not often utilized, but as the authors put it, it acts as a good "safety net" for the other components of Bonjour to fall back on if no other IP address is assigned to the machine.
mDNS, surround-sound DNS
Short for "multicast DNS", mDNS is another building block behind Bonjour, and just like regular old boring DNS, allows users to effectively lookup one another's network address. Cheshire and Steinberg discuss most aspects of mDNS, from the basics behind multicast DNS to the structural differences behind conventional DNS messages and multicast DNS messages. The duo also walks the reader through the host name selection process (as it declares its name on the multicast group) including some of the conflict resolution functionality built into Bonjour, preventing two hosts from bickering endlessly over a single host name (Computer.local, for example). UTF-8 is also mentioned, explaining how multicast DNS is designed to use UTF-8 to allow for descriptive, and accented host names such as "Bücherei Kiosk.local" providing greater flexibility for those seeking to break the shackles of the ASCII character set.
Service discovery, it's like bologna
If multicast DNS were to be the bread in the sandwich that is Bonjour, not only would link-local be the plate, but service discovery would be the meat of the sandwich. Finishing up the initial half of the book, the authors take their time explaining the important facets of service discovery, ensuring that the reader understands what "service discovery means" in the context of Bonjour. The common example used in the book is of the Internet Printing Protocol (IPP), whose service type is _ipp._tcp. Using it [_ipp._tcp] as an example, the authors expend a good amount of effort explaining how and why Bonjour's service discovery is built on top of DNS, instead of tangental to it. Building on DNS gives services a fully qualified DNS name, i.e. "Sales._ipp._tcp.example.com" (or most likely, Sales._ipp._tcp.local). The reasons for building on top of DNS become far more apparent later on in the book, when advertising static services, and some of the components that are behind "wide-area Bonjour", such as DNS Long Lived Queries (DNS-LLQ) or Dynamic DNS Update Leases (DNS-UL). The chapter spent enumerating service discovery and advertisement beyond the local link is aimed more at system administrators, or those more technical, who might be daring (or curious) enough to implement wide-area Bonjour on their networks. For the majority of the book's audience, advertising and discovering services on the local-link (i.e. your local area network) is what's primarily important.
Monkey see, monkey do.
From chapter 6 onward, the book starts to cover the more applicable aspects of Bonjour, whereas the first five chapters covered the Zero Configuration infrastructure and essentially what happens behind the scenes, the latter half of the book covers using the technology (for fun and profit). Before diving into code, a tool that is sure to prevent hours of frustration further down the line, dns-sd, is introduced. The dns-sd utility allows you to advertise, resolve, browse and proxy service advertisements all from the command line. After introducing the budding Bonjour developer's new debugging tool, they dive right into developing a simple Bonjour-capable application using the C API, detailing registering, resolving, and advertising a service from within the asynchronous model that the C API adheres to. Developing with Cocoa, CFNetwork, MFC, and Java are also covered in detail to give the reader the knowledge needed to build a Bonjour-capable application utilizing any of the aforementioned toolsets. There is brief mention on how to perform some of the same browsing, advertising, etc using the Ruby and Python bindings, but the extensive detail afforded the sections on using Cocoa's Bonjour classes, or the standard C API simply aren't existent when covering Bonjour in Ruby or Python, leaving the reader to turn to the internet to find information or give up and use C (my case).
Overall I found the book to be quite informative, finding a nice middle ground between "A Complete Moron's Guide to Bonjour" and hundreds of lines of plain-text RFCs. If you are already familiar with developing with Bonjour, either in Cocoa or C, then the first half of the book will be more than enough to give you (the underpaid over-worked developer) a good insight into what's happening behind your service queries. For most other readers however, reading the book cover to cover will serve them well, carefully introducing the reader to Bonjour and its components with quasi-real-world examples (65,000 seat auditorium? network lecture? pah!) using a healthy mix of technical jargon, and layman's terms to bring across some key concepts such as multicasting queries, building on DNS, etc. For the rest of the readers who have no interest in Bonjour/Zero Configuration, the book has a pretty bird on the cover, and like most O'Reilly books, its liable to at least make you look smarter just by keeping it on your bookshelf."
agent dero has no journal entries.