Welcome to the Apple Developer Conference. Thanks for coming to our Bonjour networking session this morning. Why are you here? You're here because you are the guys that make really cool networking software and networking hardware. And you want it to be reliable and easy to use without users having to type in host names and IP addresses and port numbers and nonsense like that.

You want to do screen sharing. You want to do file sharing. You want to print over the network. You want to access music and photos and movies and other media over the network. And Bonjour makes that reliable and easy to use. Thank you. Sometimes your client and your server or your communicating peers might not be on the same network. They might be on opposite sides of the internet. Sometimes there might be NAT gateways in the middle, rewriting the packets as they go through. Wide Area Bonjour makes that easy for you as well.

So I'll start with an outline of what we're going to talk about today. A lot of you here know all about Bonjour, but more than half of the attendees this year are first time at the developer conference. So we're going to have a quick recap of what Bonjour is and how it works.

Then Rory's going to tell you all about the really cool new stuff we have using Bonjour on iPhone and iPod Touch. And he's got some cool demos, which I think you're really going to love. We'll also talk to you about how Backs by Mac works, which is built on Bonjour. So Backs by Mac is not just for screen sharing and file sharing. Your applications can use Backs by Mac as well. We'll wrap up with some tips and reminders, cover some frequent mistakes that we see, that we want to encourage you not to make, and then we'll have time for Q&A at the end.

So summing it up in one sentence, this is what it's all about. We want networking with TCP IP to be as easy to use as plugging in a USB cable. And standing here today saying this to you, this doesn't sound too surprising. I think this idea has become accepted. But five, ten years ago, this was like heresy.

When you suggested that you would want to do things using IP networking, the reaction most people had was, you must be crazy, typing in IP addresses and subnet masks and default gateways and all that nonsense. I just want to plug my printer in the USB port. Well, in the five years since that, we've seen Bonjour get adopted in the marketplace. And now, for under $200, you can buy a network printer with Bonjour, and you plug it in, and it shows up in the print dialog just as easy as using a USB printer. And that's what we want to see more of. Some of you are probably thinking, but AppleTalk is really good for this. Well, we're here to tell you today, officially, AppleTalk is dead.

AppleTalk is no longer in Snow Leopard. And if you want to make a device, the only network browsing to discover printers on the Mac is going to be Bonjour. So that's what you need to be doing. This slide used to be the whole talk, now we've condensed it down to one slide to make room for other stuff.

These are the three technological legs that make the foundation of Bonjour or zero configuration networking. And Bonjour is not about this technology. What Bonjour is about is the user experience that we want people to have. This is not a protocol that we designed and then slap a user interface on top of it. We started out with the user experience we wanted people to have. But then to make that a reality, we had to build the technologies to make that work. The first one is link local addressing. DHCP is great. Nothing wrong with DHCP servers, but if you don't have one, the device shouldn't fall on its face and call for an administrator to come and help it. It needs to be able to get on the network on its own. So if you don't find a DHCP server, it's very simple. We looked at what AppleTalk did, and we applied the same principles to TCPIP. You pick a random address in a range reserved for this purpose. You send an ARP request. If somebody answers that, it means they have the address, and you pick a different one. If nobody answers, it's yours. So that's how devices can just plug into an Ethernet hub and all get unique addresses, which is great. but you need to know what the address is, and you don't want to be typing in addresses. So multicast DNS is the next layer of the three-layer cake.

In standard Internet applications, DNS is the name service that we're familiar with. And just like I said with DHCP, nothing wrong with DHCP servers. There's nothing wrong with DNS servers as long as you have one and you know how to administer it. But we want a lightweight solution. We want a safety net for when that's not available. So multicast DNS takes the same packet formats and the same names and the same record types of standard DNS but sends them over multicast. So every device has a little responder listening for these packets, and when it sees a query for its name, it says, hey, that's me, and it gives a standard DNS answer. So that's good. So now you can type in a name, something.local, and have that resolved by multicast and connect. But you still need to know the name to type. So the third layer we wanted, going beyond the traditional Internet usage model of 5 or 10 years ago, was being able to browse the network to discover what's there. I may not know the name of the printers on the network, but I know what I want to do. I want to print. So we have a functionally oriented discovery protocol. I'm not looking for devices. I'm looking for things that can help me perform my task. If I want to print, I'm looking for things that can print. And all the devices that have that property answer that query. The URLs there tell you where you can find more details and all the specifications.

So this is our architecture that we launched five or six years ago. It is the DNS service discovery semantics delivered using multicast DNS packets, completely zero configuration. But the day we launched that, we knew that the first question we were gonna have once it became popular was people would say, "This is great, but I want to scale it beyond the subnet."

So there's a reason we picked DNS packet formats and records and naming in the first place, because DNS is the world's largest scale distributed database. It scales beyond the enterprise to the whole planet. So using the same DNS service discovery semantics, we can perform those operations using wide area unicast DNS. So we register using standard DNS dynamic update to put those records on the name server. and we discover using DNS queries.

And those of you who've got your laptops out, if you look in Safari and look under Bonjour Bookmarks, you will see three pages that are being advertised here with information about the show. So if you forget the URL, it doesn't matter. You don't have to remember the URL. You can just look in Bonjour Bookmarks and find those.

Standard DNS is good, but there were some extra things we wanted to do. Standard DNS updates stay on the server indefinitely. So if you unplug your laptop from the Ethernet cable and walk away, nobody's going to delete those records. And we didn't want an administrator to have to clean those up.

So we added a lease mechanism. Just like when you get a DHCP address from a DHCP server, it's not permanent. It has a time on it. And if you don't renew it before it expires, then you lose the address and it goes back into the pool of available addresses. When we do updates on the server, we have an extension to the DNS protocol that puts a lifetime on those updates. And as long as the client machine is active and on the network and running, then it renews those records and keeps them live. But if you unplug and walk away, then when the records expire, they get deleted automatically.

Another reality of today's world is a lot of users are behind NAT gateways at home, and NAT gateways rewrite the packets so that you only have one public address. And roughly speaking, the client machine doesn't even know what the public address is. It doesn't know the packets are being rewritten. So we added support to Bonjour so that when your application running on Mac OS X or on Windows or on Linux registers its service, we detect if there's a NAT gateway and we talk to the NAT gateway. We set up a port mapping automatically so the users no longer have to do that manual port mapping that's very hard to explain. We find the public address, we get a public port mapping, and then we put that external information into the DNS so that you can run a web server at home, you can run photo sharing, you can run whatever applications you want. you Every five seconds, we'd get decent responsiveness, but it would obviously be horrible for the server. If we poll once an hour, it's not so bad, but then it takes a long time to discover things. So we had an extension where we can do the query to the server and say, tell me the list of printers or tell me the list of web pages here at the Apple Developer Conference and tell me if that list changes. So we hang out this asynchronous query and then we get notified immediately if the list of answers changes.

So that's what the protocol looks like. For most of you writing application software, you don't need to worry about the details of the protocol because you interact with Bonjour through the APIs. And there are three basic operations that we provide. The first thing is when you start up a service, so roughly speaking, if you have anything that calls socket, bind, listen, or receive from if it's receiving UDP packets, If you look in netstat and you've got an open socket, a listening socket in your process, then it makes sense to be advertising that service with Bonjour. Help the clients find it, don't make them guess. So the first operation is you register your service and Bonjour will send out an announcement packet on the network in case anybody was listening, waiting for that service. But apart from that, it's not continually announcing on the network. We take a lot of care about network efficiency. Now the user runs a client that's looking for that service, and the client browses to find the list of available services. So the client sends out its query, and the server says, "I'm one of those," and your server sends back a response.

This third operation is resolving. And it's very important that browsing and resolving are separate. There have been other service discovery protocols in the past that didn't make this distinction. So it's worth talking about it for a minute to explain why it's important. Browsing is something that the user does relatively rarely. And I'll use the familiar example of picking a printer. The user browses to find a new printer and set up the queue and pick that default printer.

Not very often, but they may print every day. So browsing gets you the list of names, but it doesn't get you the addresses or the port numbers or any information to actually use the service. It just presents the list of names for the user to pick. In a world of DHCP and linked local addressing, addresses can change.

So if our printing software were to take the address and port and store it in a preference file and say this is the user's default printer, then tomorrow if the printer gets a different DHCP address, that address is going to be wrong. So it's really important that when you store things in preference files and you record the user settings, what you store is the name of the service the user picks, not the address. And then at time of use, and every time the user uses that service before you connect, that's when you resolve to get the latest up-to-date address and port information for that service for the user to connect to. So those are the three operations, register, browse, resolve. Thank you.

We have quite a few different APIs now that let you access those three basic operations, register, browse, resolve. For those of you in the audience making hardware devices like network cameras, you will need to run the responder code on your device. You can run Apple's open source code. It's licensed under the Apache 2 license, which is an extremely liberal license.

It lets you do anything that GPL would let you, but without some of the viral properties of GPL. So you can use it in free products, you can use it in commercial products without restriction, and it also grants you automatic patent licenses to any Apple patents that may pertain to it as well.

But if you're writing software, then you want to concentrate on the three APIs because the actual responder is provided for you on Mac OS X. It's available as a download for Windows. We provide it for Linux. We provide it on the phone. So you don't need to worry about that.

You just need to use the APIs. guys. Cocoa programmers will probably want to use the NSNet Services API because that fits in with the programming model that you have. If you write core foundation code using CFRunLoop and CF Socket and things like that, then we have a layer that fits that programming model as well. And if you're writing straight C code, then we have the DNS SD.h API. You can use that with any scheduling model you want. You can use it with applications that use a bunch of threads. You can use it with single-threaded applications with a select loop or a KQ loop. And that's also the API that we have on Windows and we have on Linux. So if you're writing cross-platform C code, that's the API you'll want to use.

but for a lot of you in the room who are writing iPhone applications, the NSNet Services Cocoa layer is what you want to use. We also have APIs for Java, for Ruby, and for Python, so for those of you using those languages, we have that covered as well. So with that, I'd like to ask my colleague Rory McGuire to come up on stage and show you all the new stuff we've done in the last year on iPhone and iPod Touch. Thank you, Rory.

Thank you, Stuart. So what about the iPhone and the iPod Touch? You guys want to write great applications. You want to be able to transfer information between those applications. You want to write games that are networked. You want to be able to get information from your Mac to your iPhone or your iPod Touch. How are you going to do that?

Bonjour is the answer. If you want to get information from your Mac to your iPhone, you can't do it through USB, right? There's no sneaker net for the iPhone. You can't plug a USB dongle into one of them, transfer some files off of it, plug it into the other one, and transfer some files onto your next iPhone, right? You have to use Bonjour. That's the supported way to do it.

For most of you, you're going to be writing Cocoa applications. These are the same Cocoa APIs that we use on Mac, and they're available on the iPhone and the iPod Touch. On the server side, we use NSNet Service to register. As Stuart said, what that allows you to do is register your service and say, here's the port number that I'm running on. Here's the name that I want to provide to my users. Here's my service. I'm advertising it.

On the client side, we have NSNetServiceBrowser that allows you to browse for both domains, which I'll get into in a second, and for servers. And then once you've actually browsed and your user has selected one of these services, you'll want to use NSNetService to resolve it down to an IP address. One of the nice things about the Cocoa APIs is you don't even have to deal with IP addresses or port numbers when you're browsing. You can get an NSInputStream and an NSOutputStream directly from NSNetService that's already connected to the other side. So what does the code actually look like? So on the server side, you've created your socket, and you're listening on it, either through CF sockets or through the BSD layer.

When you create your SOC adder, if you put zero in the port number, the kernel will assign you an arbitrary port number. You don't have to worry about getting an assigned port number. You don't have to worry about talking to IANA or anything like that. Pass zero in, the kernel will give you the next available one, and then that's what you pass to Bonjour to advertise. Right? So your clients, they don't really care what the port number is because they can get it from Bonjour. Now the name here, we're using the empty string. This will give you the default name for the device. In Leopard, this is the name in your sharing pref pane. On iPhone and iPod Touch, this is the name that you give to the device in iTunes.

Now, keep in mind that the Cocoa APIs are all completely asynchronous. You're going to set yourself a delegate, and you're going to get these callbacks. When you actually publish a service, you're going to get the serviceDidPublish callback. This is where you're going to get the name that it actually gave you. So if you pass the empty string in for the name, you say, give me whatever name you think is the default name. This is where you can get the name to present to the user. But it's not just if you're passing in the empty string. If you pass in your own name, it might actually conflict with something else that's on the network. Bonjour will automatically rename it, because just like files in a folder on a file system, you can't have two files name the same thing.

In Bonjour, you can't have two services with the same type and the same name in the same domain. So you will get a callback that says, here's the new name. That's what you want to present to your user when you're registering a service. And of course, there's an error thing, but errors never happen, right? Did not publish. So what about clients?

Let me talk about domains. The iPhone is extremely mobile device, right? The iPod Touch, very, very mobile. Bonjour supports wide area, as Stuart explained before. You can actually ask Bonjour to give you the list of browsable domains. Those domains can be set up by your IT people. When you get a DHCP lease, you're going to get DNS servers. Those DNS servers can have certain records on them that will automatically tell Bonjour to add things to the domain list and to add things for browsing. If you don't know which domain to browse in, then how do you actually browse for things there? So as Stuart said before, if you're on your MacBook or your MacBook Pro, and you open up Bonjour Bookmarks in Safari, you're going to see three sites that the IT people here for WWC have put up.

But they've done that by adding what's called a default browsing domain. So they're automatically going to show up in Safari. But you can also ask Bonjour, give me that list of domains so that I can let the user hierarchically look through the domains to find the services that they want. So they can pick the local domain, which is the local network, the multicast network, or they can pick some other domain.

When you get the callbacks from browsing for domains, you're going to get one of two callbacks. You're going to get did find domain. You're going to get did remove domain. Now, remember, Bonjour is completely dynamic. We don't want to say, here's the list of domains. It's not going to change. It's ever-changing.

So especially on the iPhone and the iPod Touch, if you're using like a UI table view, you want to make sure that you update your table view as these things occur, as a domain comes or as a domain goes. If you plug into a new network, you might see new domains. If you disconnect from a network, those domains are going to go away.

That's what the more coming flag is for. More coming doesn't mean that there are no more coming ever. It means that there are no more queued-- or if it's true, if it's yes, it means that there are more queued up right now. So don't update your UI because we're gonna give you another update really soon. Right? So you don't have to flash your UI based on the more coming flag.

Okay, so what about browsing for services? Well, you've already browsed for domains, so your user has picked a local domain. So that's what you pass in here when you're browsing for services. You also pass in your type. In this case, it's Mood Ring, which is a sample from the Bonjour book, from the Zero Configuration Networking book.

Here are the callbacks from browsing for services. Very, very similar to browsing for domains. You're going to find a service, or you're going to remove a service. And again, you have more coming. Again, this is very dynamic. You want to make sure that you give your users an updated list as it happens. There's no need for a refresh button, because the list will automatically update.

So once you've browsed and once your user has selected the thing, maybe today, maybe right right now if you're, say, making a game, or maybe a little bit later if you're doing something like the printing example or the printing example that Stuart gave, then you're going to go to resolve. So you got the NSNet service from the did find service callback to browsing, and you set your delegate on it, and you resolve with a timeout. Now, we actually suggest that you use zero for the timeout. What this means is keep going as long as possible. This allows your user to make the decision when they want to stop resolving. If there's some problem with the network, let your user decide when they want to stop. Don't provide an arbitrary, like, five-second timeout, because for some users, that might not be long enough. For some networks, that might not be long enough. If you let it go for a minute, that might be too long, right? Let the user decide. Make sure you give the user some feedback, though, that something's actually happening. Otherwise, they're just gonna say, "Well, what's going on?"

Once you resolve, you're going to get the NetService did resolve address. Now, it's not on the slide, but like I said, there is in the NSNetService API a way to get the input stream and the output stream. Once you've resolved the address, you don't have to look at the addresses field or the port number field. Just say, give me the streams. And then you can just connect to the device or the service. So that's the iPhone and the iPod Touch through the NS APIs. Let's do a demo.

So here's an application called Bonjour Web. This, I believe, shortly will be out in the SDK on the developer page. So Bonjour Web is Bonjour bookmarks for your iPhone. We're looking in the local domain, and here I've registered the web service from my laptop here. Now this is the simulator, but this is exactly what it looks like on the phone. Opens it up in Safari, says here's my website.

Go back to Bonjour Web. We're in the local domain, but we can browse for domains, and here we have a table view that has the domains actually in it. So local is always there because you always have a local network, even if your machine doesn't have any connections to anywhere else. But RIT has also provided the DNS records to add apple.com and namespace.apple.com to the list of browsable domains. If I tap on apple.com, sure enough, I see these three things. I can go to the WWDC schedule. It'll ask me to log in.

So-- Good point. So we can go to the schedule, it'll ask me to log in, right? But we can see the schedule, we can see what's coming up. And again, your IT department can actually add these domains by adding some DNS records to the DNS servers that are provided to you through DHCP. But there's also a plus button. What if the domain that I want to browse in isn't here? Well, we can add a domain. dnssd.org, and sure enough, here's a bunch of services that are registered in dnssd.org, including multicast DNS. So if I don't wanna read more about multicast DNS, here it goes and it gives me the webpage.

Okay. Demo number two. Hopefully this one won't ask me for a password. So here's Ytap. Some of you may have already seen the Ytap sample on the developer page. I've modified this one a little bit to actually show you the name as you've registered and actually show you the other Ytap games that you can connect to. So I've got my iPod Touch here.

and I'm connected to the wireless network, and I'm going to start Y-Tap up here, and sure enough, my iPod shows up, right? I turn off the service on my touch, and it goes away. And R. McGuire shows up on my touch, which is what the simulator has registered. So if I attach here, it says go ahead and it's connected. And Y-Tap has connected me, so now when I tap on my iPod touch, you see the tap on the screen.

Disconnect goes back to here again, registers the service, shows you the name of the service, and shows you the other things that are actually registered and available. Right? This is how we suggest that you actually show these things when you're using Bonjour. You want to let the user choose the service they want to connect to, and you want to make sure that you provide the name of the service that you've registered so that other users can get to it. Right? I think that's it for the demos. So let's go back to the slides.

OK, so that was Bonjour on the iPhone and the iPod Touch. Now like I said, that sample code should be available shortly on the developer site. The Y-Tap sample might not have some of the UI elements, but it will give you some good pointers on how to use Bonjour on those devices. Let's go back to the wide area case. You've got your two machines, and you've got the cloud between your machines. But we don't live in a perfect world. Who's in the cloud? Bad guys.

How do we deal with bad guys? How do we secure information against both eavesdropping and tampering as it traverses from one machine to the other, especially over the wide area network? Now the answer, of course, is Bonjour with a lock. This is back to my Mac. Back to my Mac is enabled by Bonjour. So what does the architecture look like?

Here's the wide-area architecture from before. What have we actually added for Back to My Mac? We've added TLS to the DNS service discovery architecture. TLS stands for transport layer security. It's what secures things to secure web pages. It's what secures your email. It secures a lot of different transport layers in networking today. We've layered it so that DNS also is over TLS. But you need a server, right? This is wide area Bonjour. You have to have a server in order to do this. What server are you going to use? Do you have to set up your own server? Do your users have to set up your own servers? No. We're gonna use.Mac, or now this is called MobileMe. So your users have a.Mac account. They can use Back to My Mac. How do they do that?

Go to the.Mac pref pane, sign in. They'll get this.Mac sharing certificate and key. Now, I'm not gonna go into the details of this, but this is what file sharing and screen sharing use to actually authenticate you to the remote machine. This is why I threw back to my Mac, you don't have to type any passwords or anything other than just the-- just signing into.Mac. Now, if you're interested in this, you can go to the Kerberos talk, which is Thursday at 3:30 in this room. It'll allow you to understand how to do Kerberos authentication for your own applications.

Then they enable back to my Mac. It's actually enabled by default when you sign in to.Mac. But what does that actually do? Well, it also downloads this DNS T-SIG IPsec shared secret. This is the secret that's going to be used to secure the data in transit to the.Mac DNS servers and also from your remote machine to your local machine and back. The way that we do that is something called IPsec. That's IP security. Back to My Mac is not just set up a port mapping and run a web server on the outside of your NAT box. It actually creates on-demand, ad hoc, point-to-point IPsec connections between your machines.

Now, if you remember, I talked a little bit about domains. When you sign into.Mac and you turn on Back to My Mac, your member name is automatically added as a Bonjour domain. So if you browse for domains, that domain will be there. So this all seems really complicated, right? There's domains, and there's IPsec, and there's TLS, and there's all this other stuff. How do you as developers actually use this? What do you have to do to get this to work in your own applications? The answer is the same basic operations you use for local bonjour. Let's look at the code.

So here, we're looking at the registration code on the server side. Notice that the domain here is the empty string. Just like providing empty string for the name will give you the default name for your service, providing empty string for the domain will register your service in all the recommended registration domains. Typically, this is just local, but when your users are signed into Back to My Mac, this will also include their Back to My Mac domain. This will automatically register your service in the back-to-my-Mac domain. There is a little bit of a catch, though. If you notice, we're using IPv6.

IPv6 is required for Back to My Mac. The way that the ad hoc, on-demand, point-to-point IPsec tunnels are set up, the application is actually using IPv6. The traffic over the cloud is IPv4, but to the application, it's IPv6. Everything else happens under the covers, transparently to you guys. You don't even have to worry about it, except that your application has to support IPv6. So how does your application go to support IPv6? Well, we don't have time to go into the details here, but the simple answer is if you already have IPv4 support, it's really not that hard to add IPv6 support as well. You're gonna use the INET 6 protocol family and the INET 6 address family in addition to the v4 family and protocol-- the v4 families.

Now, when you register-- or sorry, when you create a listening socket in the kernel, if you pass 0 as the port number for your V4 socket address, the kernel's going to give you back a port number that's a V4 port number. That's the port number that you pass into the socket address for V6. That way, you'll get the same port number on V4 and V6, because you only get to pass in one port number to Bonjour. And that's it. That's how you use Back to My Mac. It's very simple. Just let the user sign in, support IPv6, and it should just work. Back to Stuart for tips and reminders.

Thank you, Rory. So I said the goal of Bonjour is to make networking with TCPIP as easy to use as USB. And there's a number of reasons we want to do that. It's not because we don't like USB, but TCPIP has a lot of benefits. The speeds are faster. These days, gigabit Ethernet is commonplace, and 10 gig is coming. The cable lengths are a lot longer. The number of devices are much higher that you can have. So if we could get the cost and the ease of use of USB with all the benefits of IP as well, that's a big win. And one of the things USB gives you is power over the cable. And the good news is that these days, power over Ethernet has become common and affordable as well.

So Bonjour gives you the ease of use, and power over Ethernet means you don't need lots of power bricks. So for those of you making little devices, I really encourage you to look at power over Ethernet. The cost of the chips to do that DC power extraction have really come down, and the cost of the equipment to drive it used to be three, four, $5,000 enterprise class gear. Now, $99 net gear will provide power to your devices.

If you're making Bonjour products, you can license the logo for free, just like the OS X logo and the QuickTime logo. You can get that for free from Apple. Put that on your packaging, on your manuals, on your website, because that tells your customers that you've got a good quality product that's going to be reliable and easy to use. You don't have to pay any money to license the logo, but you do have to pass our conformance test. And even without the logo, this is a good thing to run because it spots a lot of the common mistakes. So it helps you fix those bugs and make products better. And when you pass the test, you get to use the logo for free as well.

We say this every time, but it's worth saying again, this is not a Mac-only technology. We talked to a lot of developers who talk about doing Bonjour for the Mac market and for the iPhone market, and they talk about the Mac market share is growing, so they'll do Bonjour, and that's good, but If Bonjour is just AppleTalk version 2, then there's a risk it will end up suffering the same fate of AppleTalk. AppleTalk was very good, but it didn't get traction in the marketplace. We are working really hard to make this an open standard. We have the source code open source under a very liberal license. All the specifications are open. And we have Bonjour for Windows, which is installed with iTunes for Windows. So there are countless tens of millions of copies of Bonjour for Windows already installed on Windows machines. You can get the installer from the Apple website. You can license it to put on the CD in your packaging.

And when the user installs this, It adds a Bonjour icon to the toolbar in Explorer. Of course, these days we also have Safari on Windows. So if you're making a device with an embedded web page for configuring it, if you advertise that with Bonjour, then your users can find it effortlessly on Mac and on Windows. And that makes things very easy to use. The embedded web server has become the standard user interface for network devices, which is a great thing. 20 years ago the VT100 serial port was the standard user interface for hardware devices and you had to get the board rate right and the parity and the start bits and the stop bits and the 9-pin, 15-pin, male, female, DC, DTE. I remember having stacks of gender changes about this long before I got it right. Ethernet, fabulous.

With zero configuration, you plug the Ethernet cable in, you look in Safari, you see the device, you click on it. So you definitely want to be advertising your embedded web servers with Bonjour and either ship Bonjour for Windows on the disk or point your developers at the download. Point your customers at the download. And let us know what you're doing so that we can add them to Apple's product lists as well.

User interface. Remember I said Bonjour is about user experience more than it's about technology? And here's one example. In the days of Apple Talk printers, the printer was called LaserWriter. And something happened. Maybe we've got more geeky since then or something, but we see a lot of devices, not just printers, other devices, where the developers have got the idea from somewhere absolutely essential that these devices come from the factory with globally unique names and that's not necessary and it's not a good user experience and So I'm gonna talk through three scenarios which I think illustrate why that is the case.

Bonjour has name conflict management built in for you. If you try to register two instances of the same service type with the same name, then Bonjour will detect that the name is in use, and depending on the flags you pass when you register, it will give you an error and say you can't have this name, or by default, it will automatically rename for you. It will put a number two on the end and call you back and tell you the new name so that you can then present that to the user or take whatever action you want. On Mac OS X, it puts up an alert that says, "Joe's computer is already in use on this network. "Your machine has been renamed to Joe's computer 2." It tells you you can change it in sharing preferences if you don't like that. So let's talk about the scenarios. A home user has one computer. They don't need a 12-character Mac address at the end of it to know that it's their printer. They just need it to have, say, Brother or Canon or Lexmark or whatever the model of printer is, that's enough.

Consider a small dentist office. They have a printer. And a couple of years later, they buy another printer. Now they have two printers. Well, the new printer, when they plug it in, will name itself printer two. And everybody in the dentist office is going to be very comfortable with this. They have the old printer, which they've been using for a couple of years, and they've got the new one, printer two. The new one's number two.

Fine. Nobody's confused. Contrast that with the MAC addresses, right? You've got two printers with big jumbles of letters after them. Nobody's going to remember which is which. So in that case, having simple user-friendly names is more accessible and more helpful to your users. And consider the case of a larger office where they've got 10 printers. Well, people have said to us, 10 numbered printers aren't very useful. Printer 2, Printer 3, Printer 4, right? That's not very helpful to have to remember where Printer 7 is. And that's right. When you get up to that number, the sensible thing for the user to do is to use the web interface to configure the printer and start giving them meaningful names.

First floor, second floor, copy room. Give them names that mean something to the users. So all printers have somewhere in the UI where you can set the name. It comes from the factory with a sensible default, but you can go and edit it to give it a name that's meaningful for you. And again, let's contrast this with the alternative, which is 10 printers with 10 MAC addresses. Nobody's going to remember what any of those are. So in all three scenarios, having the MAC address pasted on the end of the name, it just looks ugly, and it doesn't actually help the user in any way.

Part of making this web operating solid is if you're making a hardware device, Mac OS X does this for you, but if you're building a piece of hardware, then after you get the name conflict, store that new name in persistent storage just the same as if the user had gone in through the UI and set it that way. Because that way, when the printer is turned on tomorrow, it's going to come back with the same name. The situation we don't want is where the two devices keep flip-flopping name randomly depending on which one is turned on first. So important part of this is make the name changes persistent because names have to be stable.

On the browsing side, you'll have noticed in Rory's demo on the phone, there was no refresh button. When he launched the app on his iPod Touch, it showed up on the simulator. When he quit it, it went away. Important part of the user experience model we want for Bonjour is that what you see on the screen is live. It is a view of the network out there. And I've seen other operating systems where when you look on the network, you see an animation of a flashlight sweeping back and forwards for 10 seconds. And then finally it finishes and it hasn't found what you wanted because maybe the cable wasn't plugged in. So you click refresh and you watch it again for another 10 seconds and it still hasn't found what you wanted. And this is very frustrating for the user. So, If you look at the Apple products, Safari, the iTunes sidebar, you look in Terminal. If you look in Connect to Server in Terminal, it will browse the network for Telnet, SSH, for things you can connect to. None of these have a refresh button. They all use the add-remove events from Bonjour to give you live updating. Thank you.

Following on in this theme, when we have a live view of a changing network, it's better to display that in a window with a list or a sidebar than in a pull-down menu. And in Leopard, you can update menus live, like the airport menu will update live. You can pull down the menu, and as networks are discovered, they will appear in the menu. But generally speaking, Users don't expect menus to be changing while they're trying to mouse over them, so it's better to present it in a window in a list view.

Another bug we've seen is developers who ignore the interface index. And a few years ago, it was rare for computers to have multi-homing. Now, with wireless networking, it's very, very common for machines to be on Ethernet and wireless at the same time. So this is the scenario that can trip up developers. Thank you.

Suppose your Mac is on airport and ethernet, and you've got some device you're connecting to or some service on another Mac that's also on airport and ethernet. When you browse for this, you'd find it two times. You find it on ethernet and you find it on airport. So you get two callbacks with a different interface index. Now suppose the user turns off airport. Well, you get a callback telling you that it's gone away on airport, but it's still reachable on ethernet. So we've seen applications with the bug where when that happens, They then delete the service from the list as if it's not reachable. Well, it is still reachable. It's still reachable on ethernet and you have to quit the application and relaunch it to see that. And that's worse than having a refresh button. So we don't want that bug.

One solution is to treat the name, type, domain, and interface index as the unique identifier. For that four-tuple, Bonjour guarantees that you'll only get paired add and remove events. You'll never get two adds in a row. You'll never get a remove for something that you haven't already got an add for. So there's an exact one-to-one pairing, one add followed by one remove.

The other way you can do it if you don't want to pay attention to the interface index is reference count how many adds and removes you've got. So if you get two adds and one remove, you've still got an outstanding reference count of one, so it stays there. And this applies to the C-level API. If you're using CF network, CF net service, or NS net service, then they actually do the reference counting for you so that that's handled. But for the C programmers or for people programming on Windows or Linux or other platforms, pay attention to that because that's a tricky bug that can catch you out.

Another bug that we've seen with applications that were written early on when we only had local Bonjour is they didn't really know what the domain was about, so they ignored it. And now with the iPhone and wide area Bonjour and Back to My Mac, your application is not going to work if it ignores the domain because the domain is not always local.

When you save the preferences, save the name and the type and the domain. You can, if you miss out the interface index, that's okay. You can pass zero and Bonjour will browse on all available interfaces. But you can't miss out the domain because it can't try to browse every domain on every DNS server in the entire world looking for your service. Thank you.

Well-known ports are pretty much dead these days for a variety of reasons. One is that there aren't very many of them and we're running out. So IANA is getting a lot stricter about handing out well-known port numbers to everybody who wants one. The other reason is that with so many users behind NAT gateways, you can have three computers at home and you can run personal web sharing on all of them, but they can't all have port 80 because you only have one external IP address and you only have one port 80. So when you map ports for the other devices, and when I say web servers, this could be something like a home security camera that has a web server in it for the way of viewing the video.

They can't all have the same port number. So when you talk to the NAT gateway to get a port mapping, you will get some dynamic randomly allocated port. This is why all those years ago, we put port numbers into the Bonjour Resolve API so that when you resolve, You don't just get the address to connect to, but you get the port number as well. So don't ignore that. We've seen applications that resolve, they get the port, they ignore it, they try the well-known port. It doesn't work with Back to My Mac. It doesn't work with any kind of port mapping. Third reason that you might not get the port you want is things like fast user switching. There might be three users running three copies of your application at the same time on the same machine, and the same thing applies. They can't all have the same port. So there are a lot of reasons to allocate ports dynamically, use Bonjour to register them and discover them.

If you look in Connect to Server in Terminal, if you set up a machine at home with SSH turned on and then you remotely look in Connect to Server in Terminal using Backs by Mac, you'll see that when it fills in the equivalent command line for you, it has dash P port number, and most of the time that port number won't be 22. It'll be some high-numbered port. God bless you.

If you have questions, you can contact our evangelist, Craig Keithley. You can find out lots and lots of information about the APIs and about how the protocols work on the web at the Apple site, developers.apple.com slash bonjour, and at the external site, zeroconf.org. A lot of this same information is also available in printed form in the O'Reilly book, which is a lot of the same information, but in a more cohesive form. And by cohesive, I mean can be read in the bathtub safely.

Tomorrow morning, we have the networking lab at 9 o'clock. That's when the Bonjour team will be here. There are three networking labs. One is right now. Obviously, we're here right now. And there's one on Friday. But if you want to talk, if you have Bonjour questions, then come along tomorrow morning at 9 o'clock. And if you're interested in learning how to use Kerberos to do authentication in your applications, then the session for that is Thursday. And that's important because Bonjour does some things for you, but it's not your application protocol. You still have to design your application protocol. You still have to have the appropriate security and authentication models for access control of which users are allowed to do what. So Bonjour solves the discovery part of your protocol, but it doesn't do all the work for you.

So, to recap, you guys are here because you're writing cool networking applications, and you want to make them reliable and easy to use. And that's what Bonjour does for you. Your applications might be separated across the Internet. There might be NAT gateways in between, and Bonjour solves that problem for you as well. And finally, you guys are now developing for iPhone and iPod Touch, and Bonjour gives you reliability and ease of use there as well. So, thank you. And on that, we'll invite your questions.