Good morning ladies and gentlemen, it's good to see such a packed house here for Bonjour today. As always, my name's Stewart Cheshire and I'm here to tell you all the exciting things that are going on with Bonjour. I'm going to start with a recap of what Bonjour is about. Many of you in this audience know exactly what Bonjour is about, but more than half of the developers here at WWDC this year are brand new to WWDC, first time. So for your benefit I'm going to give a brief background on what Bonjour is about.

Then we're going to talk about the big news this year, which is the Bonjour Sleep Proxy, which is new in Snow Leopard. And I'm going to talk about Bonjour over unpaired Bluetooth as used by the iPhone game connection kit. We have some other news to tell you, we have tips and reminders for developers. I'm going to finish up with a couple of really cool demos to show you of new hardware, and new iPhone interface.

What is Bonjour about? Bonjour is about making IP networking as easy to use as USB. And when I say that today, that's less heretical than it was a few years ago. But when we started this eight years ago, suggesting that IP, suggesting that plugging in an Ethernet cable could be as easy to use as USB, seemed very strange to people.

You have to type in IP addresses and subnet masks, and gateway addresses and DNS server addresses and things. And there was no technical reason that IP needed all of that, so if we could solve those problems we could make Ethernet as easy to use as USB. And now that you can have power over Ethernet, we also can share that benefit with USB as well, that you can make devices that are powered over the USB cable. AppleTalk did this, so clearly it was possible to make easy-to-use networking.

We want to do the same thing with IP. How do we make this work? There are three simple technologies that make this work. In previous years I've give a whole hour long talk about this, now it's condensed down to one slide. So I'll give you the overview, if you want to find out more information you can read documentation on the web, you can take a look at my O'Reilly Zero Configuration Networking book. So the overview: first layer you're not going to do much IP networking without an IP address.

Now DHCP is great, we have nothing against DHCP. But if you don't have a DHCP server we need devices to still work, and we do this very similar to the way AppleTalk did. The device picks a random address in a special range, it sends an ARP request, if nobody answers that address is yours; very simple.

That gives us addressing. The next level is naming. Now DNS is great and if you run your own DNS server that's great, but many people don't. So what we want is something that gives us DNS-like semantics, but without the overhead of running a server; and that's multicast DNS.

Every device on the network runs a little responder, when it sees a query for its name, it answers that query. Applications get DNS-like behavior but in a distributed fashion, not using a single central server that you have to run. The third layer is service discovery. Typing in host names and resolving them to addresses is great, but we want more than that. We want the user to be able to browse and discover what's on the network and not have to know what to type in.

That's DNS service discovery. At a software API layer, you use the Bonjour technology through three basic operations. The first one is advertising a service. If you have a socket that you bind to a port so you have a listening socket waiting for incoming TCP connections or incoming UDP packets, then don't keep that a secret. Register that service with Bonjour so that other clients know about it.

When you register the service, the machine announces its presence on the network, so any clients that are looking for it know. But it doesn't continuously announce like some discovery protocols. It sits there quietly and only answers if it's asked, because we do a lot of work to make the protocol not chatty.

On the client side, you may have clients today where the user types in an IP address or a host name, and if you do that that's fine. You can carry on doing that. But you can also offer them the option of browsing using Bonjour to discover what's available without typing it in.

Your client browses for services of the type that it can use, and Bonjour sends out a multicast query, and the service that implemented that service responds. And this gives your user a list of name services on the screen. Just names, not addresses, because in a world of DHCP and link local addressing, addresses can change.

When it's time to use the service, of course a name is not enough. You need an actual address and port to connect to, and to get that you resolve the named Bonjour service to its address and port. In typical usage, browsing is an occasional operation and I'll give you an example. The user may browse occasionally to look for printers. They pick one, they set it up as their default printer. They don't do that very often, but many times a day they may print a document.

So browsing is something that you do occasionally at setup time, resolving is something you do every time you print a document. And what this means is in the world of dynamic addresses, DHCP and link local addressing, it doesn't matter if your printer changes it's address because your computer hasn't stored the address of your default printer, it stored the name; and it resolves that name to its address on demand every time you print. So these are the three basic operations of Bonjour that you will use in your applications, regardless of which programming language or which API you use.

What do you do if the machines are not on the same home network? What do you do if they're separated across the Internet? What do you do if one of them is behind a NAT gateway? The answer: it's the same thing, just use the Bonjour APIs and we will handle the details for you automatically. Wide-area Bonjour and with MobileMe, Back to My Mac, will negotiate the NAT gateway, port mappings, will advertise the public address in DNS, handle all of this for you, and your same code will work.

This is what the software architecture looks like. The kernel provides the IP multicast capabilities we use, and on top of that the MDNS responder daemon is a background process that runs on every Mac and iPhone to manage the Bonjour services that you need. You can access those services in three different ways.

If you're writing low level C code and this is the same if you're writing Windows code, or Linux code, the dns_sd.h API is our low level C API and it's cross platform. If you're writing Mac specific code using CFRunLoop and CFSocket and the Core Foundation abstractions, then the CFNetServices API will be a better fit for your programming model. And if you're writing iPhone applications you'll be using the Cocoa programming idiom and you'll want to use the NSNetServices API.

So now onto the big news, the Bonjour Sleep Proxy. You will have heard about this at Simon Patience's Core OS State of the Union presentation. And I say here, saving the world half a billion dollars, there are 25 million OS X machines in use today and let's say one in five of those, 20%, are left turned on all the time so that people can access services over the network.

And let's say that costs about $8 a month, say $100 a year in electricity. Depending on the model of Mac you have and depending on how much you pay for electricity, it might be a lot more than that, it might be less. But let's say $100. That adds up to half a billion dollars a year in electricity that we save with the Sleep Proxy service. So let's give some examples.

I have an iMac at home with a printer attached, running printer sharing. My daughter has an iMac, and she wants to print a document. But my Mac is asleep so the printer manager will not be there, and the document doesn't print. I'll give you another example. My iMac at home is running iTunes, and I have an Apple TV connected to my television... but my Mac is asleep so my Apple TV can't get access to my music, and my photos, and my movies that are sitting on my iMac.

Another example: I have an iMac at home, and I have a Mac at work... that's Simon's office. I have a Mac in my office at work, and fortunately I have MobileMe so I can get to my Mac at home but, and you know this by now, not if it's asleep.

So we're rolling out more and more services that let you do useful things over the network - printer sharing, media sharing, screen sharing. But at the same time, the world is sending the message about environmental consciousness and saving energy, and these two things are in conflict. How do people solve the problem of not being able to get to the sleeping machine? Right now they have very a powerful solution, they just burn a lot of power. And that's not what we want. We want to enable people to use these services remotely over the network without burning a lot of power.

We want a power saving solution, and that's what I'm going to tell you about now with the Bonjour Sleep Proxy. So let's look at this same situation of my iMac at home with printer sharing, but I also have an Apple AirPort Base Station. And now when the Mac wants to go to sleep, it transfers its Bonjour service records to the AirPort Base Station before it goes to sleep. And after my Mac has gone to sleep, the AirPort Base Station broadcasts our pronouncement packets, claiming ownership of that IP address.

Now when I have a document that I want to print, the printing client opens the TCP connection, and because the AirPort Base Station now claims ownership of that address, it gets the TCP SIM packet; and it examines that packet and deems that this is something worth waking my computer for.

So it sends the wake up packet, my computer wakes up, my computer reclaims its IP address, and in the normal course of operation without the user or the application doing anything special, TCP will retransmit to cope with packet loss, the next packet goes to my iMac, the connection completes, and the document prints - all without the client knowing that anything special went on here. Let's look at a similar scenario. My Mac goes to sleep and a friend comes to visit. Now this friend has never been to my house before. He brings his laptop, he doesn't know I have a printer, but he needs to print a document.

So he browses with Bonjour, sends out his multicast query, the Base Station because it knows all the services that my Mac offers, it answers that query. Bonjour is the key to making this work, because when the machine goes to sleep it needs to transfer a compact description of its role on the network to the Sleep Proxy.

It needs to say what its name is, what services it offers, what ports it's listening on, and the Bonjour records provide us a perfect compact representation of what that machine's role is on the network. And we ship those across in a DNS update packet to the Sleep Proxy so it can announce on our behalf. And here it answers my friend's laptop, and he discovers that I have a printer.

And from that point on, he can print just like I did. There are other people working on paramanagement solutions that require you to set up the client in advance while the machine's awake, and store information on the client so it knows how to wake up the server. But Bonjour is supposed to be easier than that, it's not supposed to be about knowing special rules that you have to follow to make things work. So that's why we made it work this way. You show up, you do the normal operations, and it doesn't matter what's asleep or what's awake.

Everything just works the way you'd expect it to. So let me recap. When your machine is ready to go to sleep, it finds a Bonjour Sleep Proxy on the network. Using Bonjour of course to discover it, it registers its records with that Sleep Proxy using a DNS update packet, and then it goes to sleep.

Next the Bonjour Sleep Proxy will answer multicast DNS queries on behalf of that sleeping machine, without waking it. It will also answer ARP requests on behalf of that sleeping machine, without waking it. And because it answers those ARP requests, it gets possession of all the network traffic destined for that sleeping machine, so it can inspect those packets and when it sees one worthy of waking the machine, it sends a magic packet to wake it up.

It can the machine a few seconds to wake from sleep, so your TCP connection may take a little longer than usual; and this is another reason for the advice that we always give developers, which is don't hard code network timeouts because it may be true that normally your connection completes within two seconds, but now it might take four or five. And if you've hard coded a two second timeout in your application, that's the one thing that will make it fail now.

So the advice we always give is don't have programmatic timeouts, put up UI that tells the user you're connecting, have a Cancel button so the user has the option of canceling when they decide that something isn't working, and let the user wait as long as they think is necessary to wait.

Put the decision in the user's hands, not in the developer's hands. Why do we do this? I've shown you examples of printer sharing, media sharing, screen sharing... one that I think a lot of the developers in this room will like is command line SSH. You can now SSH to a machine and it will wake up on demand.

And of course, of interest to all of you in this room, is all of your services that are advertised with Bonjour get this functionality for free. How do we make this work? We build upon an old technology called Wake on LAN, or Magic Packet. This has been around for 10 or 15 years, it's very stable, very mature.

I'm sure many of the people in this room know how Magic Packet works, they could probably even draw the packet format. But I'll bet that almost nobody in this room has actually woken a machine using Magic Packet. We all know how to do it in theory, but in practice the hassle of making it work just isn't worth it.

So what Bonjour Sleep Proxy does is it takes that underlying tool that everybody has, and it automates it so that everybody gets to use it; without configuration, without effort, without any thought, it's just automatic. So I've talked about Wake on LAN, there's another underlying technology which is Wake on Wireless, and that is a lot newer than Wake on LAN. Wake on LAN has been around for many years, it's very mature and reliable.

Wake on Wireless is brand new with Snow Leopard, it only works on our currently shipping Mac models, not on older ones. So that is a brand new technology, and is less mature, less well tested than Wake on LAN. Now I'm going to talk about the participants in this process. The first participant is the server that's going to go to sleep. There are two requirements there: it has to be running Snow Leopard because this is a new feature in Snow Leopard, and it has to have some Bonjour advertised services.

One thing in particular that this means is that pinging a sleeping machine will not wake it, because ping is not a Bonjour advertised service. And this is something that we do by design because a common test that people do to see if a machine is asleep is to ping it and see if it responds, and if we wake it up every time you ping it, it kind of invalidates that test to see if the machine's asleep. So we don't want to interfere with people's expected behavior, so ping for a sleeping machine will still do what it does today, and not get a response.

But for Bonjour advertised services, will wake the machine. The Bonjour Sleep Proxy has to be on the same physical link as the sleeping server. You may read on the web that you can do wake up packets remotely, but it actually doesn't work reliably. There's no way to make that work reliably. The only way to do it reliably is to have a machine on the same physical link, or subnet, sending the packet. Any low power device that's always on is a good candidate for this.

So that makes the AirPort Base Station a natural place to put the Sleep Proxy capability. Any device on the network could do it, but the AirPort Base Station is a low power device, it's always on, and generally speaking the user is unlikely to unplug it and walk away with it. So that makes it an ideal candidate for this.

If you don't use an AirPort Base Station, then a Snow Leopard machine running internet sharing will also offer Sleep Proxy service on all of its advertised interfaces. This is code is open source, so we hope and expect that other developers will make this available in their products too.

The third participant is the client, and there's nothing special about the client. The client doesn't need to be Snow Leopard, it doesn't need to know about Sleep Proxy, it's any machine that does TCP/IP - Mac, Windows, Linux, iPhone, whatever. And that machine can be anywhere; it can be on the local network, it can connect to services using Bonjour, or it can connect to them by typing in an IP address. To wake a machine, its services have to be advertised with Bonjour so that the Sleep Proxy knows what they are. But the client doesn't need to connect using Bonjour, once the Sleep Proxy knows the services the clients can connect anyway.

So by name, by address, by Bonjour browsing. The client kernels will wake it from anywhere on the internet, not just on the local network. As long as the machine is reachable today, when it's awake, then with Bonjour Sleep Proxy it's reachable and wakeable when it's asleep. And what do I mean by reachable? If you have a Global routable IP address, which not many people do these days, but if you have one of those the machine is reachable and wakeable remotely. If you have a NAT gateway, a lot of people configure a default DMZ host to be their server. If you do that, then the server is wakeable.

You can make manual NAT port mappings, you can make automatic Map port mappings using NAT-PMP and wide area Bonjour. And of course if you're using MobileMe, Back to my Mac, we automate all this for you and make the automatic port mapping and register your address records for you. However your machine is reachable today when it's awake, with Bonjour Sleep Proxy it'll be reachable when it's asleep. Let me focus on the precise details about what will wake a machine.

A unicast UDP packet to an advertised service will wake the machine. A random port scan to some port that's not open on the machine, doesn't wake it because there's nothing listening for that packet, so what's the point of waking it? We don't wake for multicasts and broadcasts, because multicasts and broadcasts are typically used for service discovery applications, and if you send a broadcast and wake every machine on the network, that's kind of inefficient and well Bonjour does service discovery for you anyway. So you really don't need to be having different ad hoc service discovery mechanisms. For TCP we wake clients for new connection requests.

Right now we made a conscious decision not to wake sleeping servers for data packets on existing connections, and the reason we do that is a lot of applications today, when you put the server to sleep, they don't close their connections. And they just expect the connections to timeout. Well if the device at the other end is sending packets saying "are you there", if the server keeps waking up to say "yes I am" then it kind of defeats the assumption that those connections would timeout.

So we want to be conservative and not be waking up machines furiously all the time, so we wake them up only for new connections with one exception - which again is for the developers in this room - for SSH connections we will wake up the machine for any data packet, and that's just because it's so cool to be able to SSH to your machine at home.

When you've finished what you're doing, you don't have to wait for the timeout, put it to sleep right now, with pmset sleepnow it goes to sleep. You can leave that window open. You want to do something else? You type LS, you hit return after a few seconds, it wakes up and you get the listing. You do what you want, sleepnow, put it back to sleep again. So you can have an SSH window open for days or weeks at a time to a machine that goes to sleep when you're not using it, without losing the TCP connection.

One of the things you need to know about Bonjour Sleep Proxy is maintenance wake. Every couple of hours or so a sleeping server will wake to do routine maintenance of its network state. It doesn't light the screen, it doesn't power the audio, but disks and fan spinning up maybe audible. If this is a Mac in a school classroom where a teacher is accessing it over the weekend remotely, I'm sure nobody cares.

If this is a Mac on your bedside table when you're trying to sleep, depending on how sensitive you are, the noise of the fans and the disks might bother you. So if it does bother you, you can go into Energy Saver preferences and turn off wake for network access. There were some USB mice that were covered with lights to make them pretty, well when we power the bus the mice lights up for 10 seconds every two hours.

This can be a bit disconcerting if you don't know why it's happening. The reason we do this, people ask why doesn't the machine just go to sleep and stay asleep? What's this maintenance wake business? Well the reason is because on the global scale, if you expect 100% reliability out to the internet, you're going to have a fragile, brittle application that doesn't work reliably. On the global scale it's not a question of if failures will happen, it's a question of when and how often. Let me give you an example.

Say I put my machine to sleep and it registered with the Proxy, and then there's a power outage or my Base Station crashes, or I update the firmware of my Base Station, if you've rebooted it... it's forgotten about all of its clients that it's proxying for. If the sleeping server stays asleep forever, expecting the world to remain perfect all around it, it's now off the network for good and nothing is going to wake it again because nothing knows that it's there to be woken. If this server is up at your vacation house in the woods that's eight hours drive away, having to drive there to manually wake it up to fix it is a big inconvenience.

So we need network devices to be self-healing. Outages can cause some destruction for a time, but we need things eventually to heal. We could debate whether it's five minutes or five hours or 50 hours, but it does have to self-heal at some time if we want this to be a useful service. Failures can happen the other way as well.

Say my laptop registers with your Sleep Proxy, and then I yank the Ethernet and walk away and leave your house. You don't want your Sleep Proxy advertising a phantom service on your network indefinitely, forever after it's gone. So the Sleep Proxy works a bit like a DHCP server.

A DHCP server doesn't give you an IP address forever, it gives you a lease and says here's your address for 4 hours, if you don't renew it after 4 hours I'm claiming it back. And the Sleep Proxy does the same thing, it says I will proxy for you for a certain length of time, but if I don't hear from you again I'm going to assume you're gone. So in both directions does this periodic just checking in, yes I'm still here, everything is still fine.

If this seems a bit odd to you, I think it would be helpful if I explain how this is the first step on a path to more fine-grained power managements. What we're looking at doing long term is getting away from the current monolithic view that your Mac is asleep, or it's awake.

Historically before we had laptops, computers are always on. And then we had laptops and we had these mechanisms to put them sleep, and it was kind of a forcible thing. The idle time expires and you whack the thing on the head and knock it unconscious and you hope it stays down. Well as time evolves and we're all much more savvy about power management on laptops and phones and even desktop computers saving power. It's time to reverse that model. The machine is not awake unless there's a reason to go to asleep.

The default state is asleep unless there's a reason to be awake, and we have a set of reasons. The user has moved the mouse in the last five minutes might be a reason to be awake. I'm currently printing a document with printer sharing, is a reason to be awake. I'm serving iTunes music to Apple TV is a reason to be awake. You take the set of reasons to be awake, when that set becomes empty there's no reason to be awake anymore. So you go to sleep immediately, there's no need to wait for an idle timeout.

We're not there yet, but I'm just showing you a view of where we're trying to go in the future, and the maintenance wake is just the first step along that journey. And I talked about having a set of reasons to be awake, we want to do that not just on a systemwide basis, but on a per component basis. We have a set of reasons for the disk to be awake, a set of reasons for the screen to be lit. Printer sharing or iTune sharings are not reason for the screen to be lit. So this fine grained power management becomes on a per component basis.

On an 8-core machine maybe you only need one core powered on. So if we succeed at this the question "is my machine asleep or awake" will no longer be a well defined term, because each component in the system will always be in the lowest power state it can be to meet the user's needs, and maintenance wake is the first glimmer of that future plan. I need to tell you about some limitations.

We don't support USBs in that... on the MacBook Air right now. Wake on Wireless is only on currently shipping machines, and because it's so new it requires an Apple Base Station, none of the third party base stations support Wake on Wireless yet. The sleeping server must be on AC power, you can use a laptop but not if it's on battery because we don't want remote access to run your battery down.

And similarly laptops need to have a screen available, and this is a requirement enforced deep in the power management code, that we assume for you to wake up a laptop you must either have the screen open or you must have an external display. And in the future we may remove that limitation, but for now in Snow Leopard that's a limitation. So if you want to access your iTunes collection on your laptop when you get home, put it on your desk, connect the power, open the lid, and then you can walk away. But if you leave the lid closed, it's not wakeable.

And our last limitation, which we hope to fix but we didn't quite get to it in time for the Snow Leopard seed you have, is the proxy does not capture IPv6 traffic. So if you want to do the SSH trick, use SSH-4 to make a v4 connection because if you make a v6 connection, which it will by default on the local network, then the proxy won't capture those packets and won't wake the sleeping server.

So what do you need to do as developers to get the benefits of this great technology? I think you know the answer - just carry on using the Bonjour APIs and you get all of this for free. So with that, I'd like to ask Rory to come up and tell you about Bonjour over Bluetooth as used by the Game Kit.

Thank you Stewart. Thank you all for being here this morning. Peer-to-peer, I'm sure all of you have heard about this. In the Keynote you may have even been at the Game Kit session just before this one. What is it? How does it work? You probably already know that we use Bluetooth now.

Peer-to-peer on iPhone OS 3.0 is implemented using Bluetooth. But do you need to know about the Bluetooth APIs? Do you need to know how to tell the Bluetooth radio to send your packets to advertiser services to do any of that? No, you just use Bonjour. But let's take a step back. What did Stewart say at the beginning of the presentation? Bonjour is to make IP networking over things like Ethernet and Wi-Fi, as easy as USB.

Bluetooth typically you have to do things like pairing. On Wi-Fi networks you have to know which Wi-Fi network to be attached to. If I want to play my Wi-Fi game, or my Bonjour enabled game on the iPhone OS right now with you, we both have to be attached to the same Wi-Fi network.

But which one do I choose? There are so many to choose, we have to make sure we choose the right one, it's a difficult problem to solve. So Bonjour is now going to take this a step further. We're going to use unpaired Bluetooth so that you're users don't have to worry about pairing. The normal Bonjour APIs are what make this possible, because of the things that Steward said about separating, browsing from resolving. We'll get into that in just a second. How is it the same? We use the same APIs.

NSNetServices, if you're using Cocoa Touch, CFNetServices if you're in the Core Foundation layer, and you can use a dns_sd.h APIs if you want to get all the way down to the C layer. Your code will just work. If you have Bonjour code right now, it will just work. In fact when we were developing this, we used the WYTAP sample to make sure that it worked.

How is it different? Resolves might take a little bit longer now. Bonjour actually automatically brings up a Bluetooth PAN connection, that's Bluetooth personal area networking. It's an IP connection over Bluetooth. Bonjour is designed to make IP over Ethernet as easy to use as USB, and now we've extended that to Bluetooth. Your existing IP services can now use Bluetooth on iPhone OS 3.0.

But the PAN connection takes a little bit of time to bring up. The Bluetooth layer has to negotiate, has to bring these things up, so you might have to wait for the resolve to take a little while. So back to something Stewart said earlier, let the user decide when they're done waiting. Use ResolveWithTimeout:0.0. This is the NSNetServices API. This will allow your user to decide when they've waited long enough, tell them that something's going on but let them decide; and that's it.

Let's talk about browse versus resolve again. Bonjour is designed specifically to separate browse versus resolve. When you browse you get a little bit of information about a lot of services. You get the name of all the services. With Bonjour over Bluetooth, this is done before the PAN connection comes up. We get you the names of the services and potentially the text records, if you want that extra information, before the IP connection comes up.

Once you resolve, Bonjour gets you a lot of information about one service; the host name, the IP address, the port number. And it also brings up the Bluetooth PAN connection, the act of resolving brings up the Bluetooth PAN connection. But it's a little bit heavyweight to bring up the Bluetooth PAN connection, so you don't want to resolve everything you get back when you browse. Over normal Bonjour, that's inefficient. Bonjour over Bluetooth, it's even more inefficient because you have to bring up the PAN connections to all the devices that are around you that have the services potentially that you're looking for.

In general, do the right thing. Browse is distinct from resolve. Don't resolve each service, don't connect to each service, let you user decide which service they want to connect to, and connect them to that service. Resolve that service, it'll automatically bring up the Bluetooth PAN connection, it'll automatically get you the IP address for that Bluetooth PAN connection, and you can just use it.

In fact the NS APIs, if you look at the WYTAP sample, it uses the Get InputStream OutputStream method to get you the input stream and the output stream, that will automatically bring up everything for you after you've resolved. So some of you might be wandering whether to use the Game Kit, or the Bonjour APIs? So the Game Kit does provide a nice UI.

The Peer Picker UI in the Game Kit is a UI that's standard from Apple that you can use to do Bonjour over Bluetooth. It will also ask your users if they want to enable Bluetooth, and it'll warn your users if they're using a device that doesn't have the capability to do peer to peer over Bluetooth.

Game Kit cons - it's Bluetooth only, no Wi-Fi. The Bonjour APIs, especially the CF layer and the NS layer, don't care whether it's Bluetooth or Wi-Fi, it'll find you services on both. Bluetooth is also not available in the simulator, you have to use two devices for testing the actual Bluetooth connectivity. So which devices are actually supported? So Bonjour over Wi-Fi works on all the iPhone OS 3.0 devices. Bluetooth is not supported on the iPod touch first generation, or the iPhone first generation.

But it's supported on the other three. Now there are some coexistence issues. There's only room in the device for one antenna. So the Bluetooth and the Wi-Fi hardware use the same antenna, and there's a bit of a coexistence issue. If Bluetooth wants to use the antenna and Wi-Fi wants to use the antenna at the same time, you might have some issues.

The general advice on this... you don't have to do a browse or an advertise, unless your user actually wants to do that. If you're running a game or something and you're actually active in the game play, we suggest that you don't leave your advertise running, and don't leave your browsers running in the background.

You don't have enough UI to show them what you found over the browsers anyway, you don't have enough real estate to do that typically, you want to use the whole screen for your game, for your application, whatever it is. So we suggest that you do not browse and advertise while you're actually in your game play, or while your app is doing things, specifically because of some of these coexistence issues. Now we are working to make these coexistence issues better, but we wanted to make sure that you guys know about it when you're developing your cool applications right now. With that, back to Stewart.

Thank you Rory. We have a couple of little tidbits for you. One is negative answers. In the original design of multicast DNS 10 years ago, we had this model that there are no negative answers in multicast DNS, there are only positive answers. When you multicast a query on the network saying "are there any printers out there?" the things that are printers can say positively "yes I'm a printer". But there's no entity out there that can say authoritatively "no there are no printers." That logic seemed to make sense, and it does make sense except for one little detail and that's IPv6 addresses.

If a device has claimed ownership of a host name, it has that host name, it has address records, but it has no IPv6 address records because it doesn't have IPv6, then it is in a position to know authoritatively that if somebody queries for that host name, for the IPv6 records, it can say "no this is my name and I know I don't have v6", so don't retransmit, don't keep asking, don't timeout, I'm telling you now - there are no answers for that question.

So in Snow Leopard we now have a way of encoding that on the wire, we use DNS NSEC records, so you can now get negative answers without timing out, you can get an immediate authoritative negative answer. And if you want to get those new results, pass the ReturnIntermediates flag to tell the API that you want the new results. If you don't pass that flag, you only get positive results as before, but if you pass that flag you'll also get informed of negative results.

The other bit of news is... mDNS responder, the Bonjour daemon, is now the systemwide DNS resolver for the whole system. And the reason we did this is because in older versions of Mac OS, there were different bits of code on the system doing DNS lookups. There was lib.resolve, there was directory services, there was Bonjour doing its own wide area Bonjour unicast DNS queries, and there were different caches.

And the caches could potentially get out of sync. One way they could get out of sync is if the IP address of your machine changes, then Bonjour will multicast announcements to all your peers saying this is my new address. And Bonjour on those peers will see those announcements and update its cache with the new data, but directory services won't. So depending on which API you use, you could get inconsistent results. Well in Snow Leopard we've fixed that. One resolve of the system, one cache, consistent results, no matter which API you use.

What this means is if you disable mDNS Responder, you don't just lose Bonjour now, you lose systemwide DNS as well; so don't do that. Tips and reminders for developers, these are things I'm going to talk about. Use asynchrony. Don't do blocking calls. Networking is frequently unreliable. In your lab on Ethernet it may be perfect, but in the real world, especially with wireless devices, it's frequently not perfect.

And the user just staring at a nonresponsive app is very frustrating. And because of that, on the iPhone if your main thread doesn't respond to events for 20 seconds, your app is killed. Interesting bit of trivia here, the DNS timeout is 30 seconds.

So if you do a blocking DNS call on your main thread, and your user is in a place with spotty network connectivity, which they all will be at some point, your app dies. You don't want that. Use some of the asynchronous models, use CFHost and schedule it on your run loop.

Use DNSServiceGetAddrInfo header info if you're using the low level APIs and put that on your select loop, your kqueue loop, use Grand Central Dispatch. We have many asynchronous mechanisms. You can even schedule a separate thread and do a block and call on that, although we don't recommend that because threads are expensive to have big stacks.

Our other asynchronous call mechanisms are much more efficient and lightweight than making a whole thread stack, and especially on a device like the iPhone, you want to be lightweight and efficient. Creating lots and lots of threads on the iPhone is not a way to make your application work well.

A lot of other browsing UI's with other technologies have a refresh button. Don't do that with Bonjour. The Bonjour user interface paradigm, the list is always fresh. The user doesn't have to refresh it, and think about the Apple apps Safari, iChat, iTunes. There's no refresh button. The list is just always live. You unplug the Ethernet, the list gets empty. You plug it back in, the list repopulates. The list is always up to date. Just do your browse and handle the add/remove events.

We've seen apps that do a browse for 10 seconds, cancel it, show the list. There's no reason to do that. As long as the user is looking at the list, keep updating it live. In the same vein, we prefer lists in windows than pull-down menus. There are APIs for modifying menus in place, but it's confusing to the user. They don't expect to be pulling down through a menu and having items jumping around.

And of course don't do the worst thing, which is display the menu and don't update it, because that way if the user doesn't find what they're looking for the first time, they have to dismiss the menu, look again, dismiss the menu, look again. That's like having a refresh button, but even worse because there isn't even a button to click, it's even more clumsy. Every service on the network needs a unique service identified. This is the language, this is the vocabulary that we use to identify what we're looking for. If two applications use the same service type, the clients might think they found things that aren't what they think.

So doesn't cost anything to go to dns-sd.org/ServiceTypes and just register your 14 character unique identifier. Originally Bonjour, when we first shipped it, was local only. But we had plans for wide area right from the start, which is why the browse call returns to a domain parameter. We saw some applications ignore that parameter, and then when they resolve they pass local because they assume local is all there is. If you do that, your application won't automatically work with Back to My Mac. Think this is not hard? When you get the browser result, you get Name, Type, Domain.

Store all three and pass all three unchanged to the resolve call. Similarly don't assume well-known port numbers. In the original Bonjour APIs the resolve call gives you a port number, and there's a couple of reasons for that. With fast user switching, if you've got three copies of your application running, they can't all have the same port. If you are behind a NAT gateway using NAT port mapping, then all the machines, they can't all have port 80 so some of them are going to have to have different ports.

The Bonjour resolve core handles this for you; it tells you the port to use. We saw some applications that ignored the port and just used the well known port, and those applications don't work with fast user switching and with wide-area Bonjour. Those are programming tips. Some business tips - License the Bonjour logo, it doesn't cost anything. Put it on your packaging, on your documentation, on your website, on your literature, it advertises that your product is easy to use to your customers.

If you're building a hardware product, then if you run the conformance test and pass it, you get to put the logo on your packaging for your hardware product; and it is the sign of an easy user experience, not a frustrating Saturday afternoon trying to get something to work. And even regardless of the logo, the conformance test is a useful thing because it helps you find common programming mistakes that we've seen in addressing, naming, discovery.

If you're selling a hardware product that you sell to Windows customers as well, you can include Bonjour for Windows which will install the Bonjour system service and the libraries, and of course you all know Safari for Windows has the same Bonjour browsing as Safari on the Mac. So if you have a hardware device with an embedded web server in it, like pretty much any network printer does today, Windows users can use Safari to discover that and configure it without having to type in IP addresses; and there's a plug-in for Explorer as well for the Windows users who like Explorer. So now I'm going to show you a couple of demos here.

This is a new piece of hardware I got just last week, from a company called ZeroG Wireless. They make very low cost, low power, Wi-Fi chipsets. And this is a microchip development board, and this little daughter card here is a ZeroG module. This is built so, in something like a $50 children's toy, you can put a Wi-Fi Bonjour advertised web server into it and control it from your iPhone. There are other companies making low cost, low power Wi-Fi. It's becoming a big area, but this is the first company to actually include Bonjour support in their developer kit. And this is brand new hardware, I got this last week, and there's a lot of wireless around here.

But let's see what happens with this. So... I'm running an application here called Zeroconf Spy, which is actually more or less just Apple's Bonjour web sample code which you can download. But to save you having to build it yourself, if you search on the App Store for ZeroConf Spy then you can just... right now you can download it and install it, and this uses Bonjour to discover Bonjour advertised web service.

So this is not an example UI I want to show, but if you're building hardware, this chip has a bunch of inputs and outputs, so these are the LEDs and if I click one of these LEDs you can see back on the device it's lit up that LED.

So for the hardware developers in the room, you're saying "I want to make a device". Like can you imagine a home thermostat where you're feeling a bit chilly, you pull out your iPhone and you hit Zeroconf Spy, thermostat UI, up a couple of degrees without even getting off the sofa? Your iPhone becomes the universal remote control to every device in our house. And this is not a good example UI, so I want to show you something that I think is a nicer UI.

Let's go back to Zeroconf Spy, and... this is a bit of software called Indigo, which is home automation software. This runs on a Mac, it advertises with Bonjour, but it advertises an iPhone friendly UI. So when you connect to this, you get something that doesn't look like a webpage, it looks like an iPhone app with shaded buttons and

I'm going to wait for this to go away and we'll try again. So let me reconnect that wire. See what I mean about no refresh button? You disconnect the wire, it goes away. You plug it in, and in a few seconds we should see that appear.

Alright well it looks like we're going to have to move on there, but they have a nice UI and the thing that's nice about this is writing iPhone apps is great, and if you want to write an iPhone app to control your device I encourage you to do that.

There's lots of things you can do with a native app, but if a customer's got a house full of devices, installing a different app for each one may be a bit cumbersome. And the nice thing about this is you can make a pretty slick UI using just Ajax and a webpage, and it looks like an iPhone app except there's nothing to install. The user can just discover it and connect to it.

So I want to tell you, I just want to show you the things. So ZeroG Wireless is the hardware board. Perceptive Automation is the company that makes the Indigo software, and the Zeroconf Spy iPhone app you can just search the Zeroconf from the app store and download that. For more information, Craig Keithley is our evangelist. You can email him with questions. We have documentation on the web, both Apple documentation at developer.apple.com/Bonjour. And the external IETF or enter information at ZeroConf.org.