Good morning ladies and gentlemen. It's good to see you all here today. My name is Stuart Cheshire and I'm the architect of Bonjour. I'm going to be telling you today about Bonjour and related technologies and particularly about how it interacts with multitasking on iOS 4. Let me ask how many people are here at their first WWDC. Can I see a show of hands? That is amazing. That's more than half the room. And how many are here for the first time at a Bonjour presentation.

OK. Then I'm glad we have some overview because this is the first time for I'd say about 80% of the people in the room. In previous years, what I'm going to talk about is the overview would have been the entire hour-long presentation. We have a lot more stuff to talk about today so it's going to be very condensed but I hope it'll give you the flavor of what it's about and at least point you in the right direction for more documentation to find out more details.

Rory McGuire, my colleague will be telling you about some specific details of Bonjour on iPhone OS and will be talking about some other developments because Bonjour is not just a Mac technology. It's not just an Apple technology. We have Bonjour on Windows and there are many third party products using Bonjour as well. It is an open standard. The source code is open source under the Apache 2 license and all the specifications of public. We'll wrap up with some tips and reminders of common mistakes that which developers make so that you can avoid making the same mistakes.

So let's start with the high level goal. TCP/IP, the technology of the internet clearly won out against all the other wide area of technologies like DECnet and XNS, X.25, ISDN and it was a great achievement to build a global scale network. But where it lacked was ease of use and the canonical example I like to give is you take a USB printer, you take the cable, you plug it in. Nobody has to type addresses and subnet masks and configuration parameters to make that USB work. And there's no technical reason why IP can't be just as easy as that.

The only reason is that all the people working on it in the early days were so focused on the challenge of building a global network to rival the telephone system that they totally neglected worrying about the details of two computers connected with a cable because that seems so trivial in comparison. What we did with Bonjour and zero configuration networking is to go back and fill in that missing piece.

So when you're designing your application or your hardware product, if you have any doubts about a certain design decision, kind of mentally think, if I plug it into USB, what would I expect. We would like the same user experience with an Ethernet cable or with Wi-Fi or with IP or with Bluetooth.

So that's the goal. We want networking where you just plug it and it works. This is how we achieve that goal. And there are three legs of technology that make up the foundation for Bonjour, zero configuration networking and that foundation is what lets you developers write applications where you can rely on networking being present and functional and not have to worry about a lot of failure modes that you used to have and I'll start up with one of those failure modes.

DHCP is great. We are not competing with DHCP at all and if you have a DHCP server on the network handing out addresses, that's great. But if you don't, if you just have two devices connected with an Ethernet cable or some devices connected to a simple Ethernet switch, then there's no DHCP server. And in the past, most devices would just give up. So you can't find DHCP server and refuse to work until the user fix the problem.

Now for desktop computer with a screen and a keyboard, that's annoying but it's not fatal because the user can configure a manual address. But for devices that don't have a screen and a keyboard, for device like an AirPort Extreme Base Station where it's only user interface for controlling it is over the network. It has got to get itself on the network. Because if its network is misconfigured so it can't communicate, you have no way of communicating with it to fix that. So IPv6 has link-local addressing.

Every IPv6 device configures itself a link-local address on every interface which is not configured by the user. The user can't break that so you can rely on it to have an address and with RC3927, we have the same thing in IPv4 and you've probably seen this now. This is not new. Ten years ago when we're talking about this, this was new. These days everyone in the room is probably familiar with those addresses 169.254 and that means the machine picked its own address because it couldn't find the DHCP server to give it another address.

So this is a good start. We can have two or three or five machines all with self-assigned unique addresses but it doesn't really help you if you don't know what the address is and nobody likes typing addresses especially IPv6 addresses. With conventional IP, people are used to using DNS host names.

So following a similar principle that we want to stay as close as possible to our current practices, we use Multicast DNS which uses the same naming syntax, the same record types, the same resource record types and the same packet format of standard DNS but without a central server.

And every device on the network has a piece of software which is the Multicast DNS responder which knows that device its own name. And when the client multicast a query to every device on the network, the one that recognizes its name says, hey, that's me and it answers the query. Now that's good.

That's got us to parity with what people expected of the internet 10 years ago but you still have to know the name to type and if you type it wrong, it doesn't work and you don't really know why. So we wanted to go one step beyond that and that's the third item on this list of technologies and that's service discovery. Building on the Multicast DNS mechanisms, we can also multicast queries to the network. Not for specific host name but for type of service. Say, I want to print.

What devices out there can meet that need for me? What printers are out there that I can turn a printer up too that results in sheets of printed paper coming out. And that service discovery is the third leg and that's the level that you as developers will generally be interacting with this. Because the addressing is handled by the OS, so unless you're building hardware devices, you don't need to do that and the host name lookup is an OS level function.

But if you are offering services on the network and that means if you have a socket that's listening or if you're making connections on the network, you'll want to interact with the service discovery APIs that Bonjour provides on the Mac, on iOS, on Windows and on other platforms. So here's an overview. You have a piece of software that's listening for connections. That's great and you can make the user write down the port number on a post-it note but it's better to use the technology we have to advertise that fact on the network.

When your service starts up or when the machine wakes from sleep or when you connect the network, it sends out a couple of announcement packets to let clients that may be listening know that this service is now on the network. Now it's not continuously broadcasting its pockets because that would add up to a lot of wasted bandwidth but it does send out a few packets on startup.

Now suppose a client comes along and were looking for that service. The client will do a browse operation and these APIs were available in C and in Cocoa and in Java, in different languages, but they all have the common property that you browse the services and the server responds if it has an instance of that service type. So this lets the client build a list to present to the user so the user can pick which particular instance they want to connect to.

And then the second step is resolving that name service to get the current IP address and port number where that service can be reached and this is a very important point with Bonjour. Browsing and resolving are separate, other service discovery protocols didn't make this separation and the reason it's important is because, I'll go back to the familiar example of printing.

Browsing the network defined which printers are available and picking the one you're going to use most of time is your default prints out. It's an operation that people do relatively infrequently. Some people may only do it once a year. They pick a printer and then they don't change it at work. But with DHCP, with link-local addressing, addresses and ports can change overtime and if your printer preferences on your machine have stored the address and port number, that might not work tomorrow. But the names are stable overtime.

So by storing the name and then resolving on use, you get the current address information. So this is very important, we'll come back to this later. Browse to show the use of the list but then resolve a connection time to find the most up-to-date information. That was on the local network.

One of the questions we knew that would come up is, well this is great on the local link but what about across the internet. What if I'm behind the NAT Gateway and the answer is the same Bonjour APIs that work with link-local Multicast DNS also work with wide area Bonjour and the area where most of you are probably most familiar with this, is this is the underlying technology between Back to My Mac in MobileMe.

So when you're using screen sharing and file sharing to access your machine across the other side of the country, it's wide area Bonjour and the standard Bonjour APIs that are doing that for you and if you have an application that registers with Bonjour and browses with Bonjour, then your application will work planet-wide using Back to My Mac as well. It's not just screen sharing and file sharing. It supports all of your apps as well.

This is the API architecture. On top of the kernel, we have a daemon called mDNSResponder running and clients talk to that daemon to advertise services and browse the services. There are three main levels of API here not counting Java and Python and Ruby and some of the other languages. There's the dns_sd.h which is the low-level C programming API. That's available on Mac, Linux, Windows and on the iPhone.

The next level up is core foundation CFNetServices and the highest layer is NSNetServices which is the foundation layers used by Cocoa. And for most of you in this room doing iOS development, you'll probably be working at the NSNetServices layer but they are all available on the iPhone. So if you got existing code, you can still use that.

So Bonjour started off as replacing the AppleTalk Chooser to define what's on the local network. But when you use the Bonjour APIs you get a lot more than that. I've talked about discovering local things. I've talked about discovering remote things by Back to My Mac. I'm going to tell you about discovering devices that may be asleep. This is the new feature we introduced with Snow Leopard, we talked about last year. I'll give a little recap of that now.

And we keep inventing new communication technologies and they come along with their own sets of APIs and their own addressing syntax and their own model for how they work and that can be a burden for developers to have to keep supporting whatever the new thing is. So one of the great things I was very excited about last year with iPhone OS 3 is peer-to-peer Bonjour over Bluetooth. So you don't have to pair Bluetooth.

You don't have to configure it. You don't have to set up the Bluetooth panel, configure the IP addresses. You just use the Bonjour APIs and when you're resolved, we will actually bring up an IP network over Bluetooth on demand and then connect you to the other device. And this is what's used by the Game Kit on iPhone. But it's actually implemented as a Bonjour function so all of your Bonjour apps get this for free as well.

So let's talk about the sleeping case. Suppose I've got a USB printer plugged into my Mac with printer sharing and this is great because I can print remotely. I can be sitting on the sofa with my laptop and I can print. But not if the computer is asleep.

Back to My Mac, similar story. I can get to my computer remotely but not if it's asleep. Apple TV can access music and movies and photos of my iTunes music collection on my iMac but not if it's asleep. So on the one hand, customers want to put their machines to sleep so they're not wasting energy but on the other hand, we keep providing useful services to them that mean they want to keep the machine awake and we wanted to resolve this tension and make it so that you can have the best of both worlds and that's the Bonjour Sleep Proxy. The Bonjour Sleep Proxy runs on AirPort Base Stations. It runs on Apple TV because that's the device that's always on, on your network and doesn't take very much power. If you're running internet sharing on your Mac, then that will also act as a sleep proxy.

Basically, any device that doesn't take much power that's always on is a great candidate for a sleep proxy. It's open source so anybody can make these but for most of you in the room, I'm guessing your AirPort Base Station is going to be your proxy. When the Mac goes to sleep, it takes its Bonjour service records and ships them in a packet to the proxy.

Because those service records are a compact representation of its role on the network, what its name is, what its address is, what services it offers, what ports it's listening on, it takes all that information and ships it to the proxy and says this is me, I'm going to sleep now, wake me up if anybody wants me.

The iMac goes to sleep and the proxy sends out some proxy out packets to say, I am now temporarily responsible for this IP address because I'm proxying for the device that's asleep. Now on my other machine, I have a document that I want to print. So it looks up the address and port, find the Bonjour result and it opens a TCP connection and that TCP SYN goes to the proxy. Because the proxy is currently the owner of that IP address.

The proxy inspects that packet and decides that this is something that warrants waking up the sleeping machine. So it sends a wake-up-packet and the machine wakes up. It reclaims its IP address, TCP in the normal course of operation will retransmit the packet which now goes to the newly awakened machine and the document successfully prints.

Many of you may have had this happen without even realizing it because like all good networking technologies, it's frequently completely invisible. You notice it when it fails. If you hit command-P and the document doesn't print and you kind of curse, oh my, My Mac has gone to sleep, let me get up and wake it up, then you notice it. But if you hit Print and the page comes out, you may never have even realized that your machine was asleep.

It woke up to print the document and then it went back to sleep. And this is really rewarding when networking technology works that well. It can also be a little bit disappointing that we're doing all this work to make this magic work and nobody even notices.

So it's printed the document, my machine goes back to sleep.

That was in the case where the client already knows about the printer because I've set it up as my default printer but because of Bonjour service advertising, a friend could come and visit my house with a laptop computer and they've never been on my network before. They've never used my printer before but when they do Bonjour browsing operation, the proxy responds on behalf of the sleeping machine saying there's a printing service on this network and it does that without even having to wake the machine.

So unlike other Wake-on-LAN technologies that have been around for a few years, you don't need manual setup in advance to configure this. You can walk into a network you've never been on before and still discover services even on machines that are asleep.

Bonjour sleep proxy works with any application that uses the Bonjour APIs. So we use it for printer sharing. We use it for Apple TV accessing iTunes.

Even outside the house, if you want to get back to your Mac at home and the Mac's asleep, the base station will wake it up when an incoming connection comes in. With command-line ssh, this is not something that normal users use but the developers tend to love this.

You can be logged in to a machine with ssh and when you're finished doing what you're doing, type pmset sleepnow and the machine will go to sleep without losing your TCP connection. Sometime later, you type in that window, first keystroke, the machine wakes back up, does what you want, put it back to sleep again.

You can keep your connection open for days or weeks at a time to a machine that will sleep and wake on demand and it doesn't have to awake consuming power 24 hours a day bust because you've got an ssh log into that machine. And for all of your applications that advertise services with Bonjour, if you advertise your service, we can transfer that data to the sleep proxy. If you don't advertise the service, we don't know about you and we can't tell the proxy about you. So with that, I'd like to invite Rory McGuire to come up on stage and tell you some specific details about Bonjour and multitasking in iPhone OS.

Thank you Stuart. My name is Rory and I'm here to help you learn about Bonjour on iPhone OS. Specifically, we're going to go over three things. First is peer-to-peer networking, something that Stuart talked about a little bit. I'll go into a little bit more detail. The second is a new API in iOS 4 called DNSServiceSetDispatchQueue.

It's in our low-level C API and it allows you to use GCD queues with Bonjour. It'll make things a lot easier for you, I'll get into that. And the new hotness for iOS 4 multitasking and what that means for Bonjour and networking in general. Let's get to it.

Peer-to-peer, this is something that we introduced last year with iPhone OS 3. You may know this as being used by Game Kit. Well, what does it actually do? I'm sure we're all familiar with this Wi-Fi selection UI, Wi-Fi network selection UI. Which network do I pick, right? Let's say for example that you're in a room with 576 MiFis.

If I wanna use my game or use my service, which one of these things do I pick? Well, we're going to solve that with no configuration. How are we going to do it? Bluetooth. But wait a second. This is the Bonjour session, what are we doing talking about Bluetooth? Well it's Bonjour over Bluetooth.

Again, like Stuart said, there's no manual pairing. Bonjour will automatically make the devices connect when you do a resolve. Again, this is used by Game Kit but it's not required that you use Game Kit. You only really have to use the Bonjour APIs. So if you already have the Bonjour APIs in your app, you will get the Bluetooth stuff for free. How is it the same? Exactly the same APIs, NSNetService APIs, CFNetService APIs and the dns_sd low-level C API. Your code will just work.

How was it different? Well, Stuart talked a little bit about how Bonjour actually separates browsing from resolving. This really worked well for us to implement this over Bluetooth. Resolves may take a little bit longer because that's what actually tells Bonjour to bring up the IP connection, the PAN connection between the two devices.

So one of the things that you're going to want to is make sure you use ResolveWithTimeout.0. It's going to take a little bit longer than a connection, a resolve over Wi-Fi. Let the user decide when they've waited long enough for this thing to come up. That's about it.

So, let's go to little more detail about the separation between browse and resolve. Browsing gets you a little bit of information about a lot of service instances. It gets you the name of lots and lots of service instances. Resolve on the other hand gets you a little bit of info or gets a lot of information about one particular instance.

And in the case of Bonjour over Bluetooth, it also brings up the Bluetooth PAN connection which is kind of a heavyweight operation. What you don't want to do is resolve every single service that you find in the browse because that's going to fill in the whole table and it's going to be very costly.

Don't browse continuously because that also has some power and performance implications. Don't resolve every service. You can get a little bit more information about the services by querying for the TXT record. There are APIs at the NS and CF layer to get the TXT record for the services that your browses return so you can display a little bit more information to the user. But let your user decide which service they want to connect to.

Don't just go off connecting to every single service because you're going to be telling Bluetooth to go off and connect to these different PAN connections if the thing was discovered over Bluetooth. You don't want your app to be known as the one that drains the user's battery. Not to be outdone, the Wi-Fi guys are actually working on something called Wi-Fi Direct.

This is currently scheduled to have Bonjour in it. Alright, it does some exchange with these people to actually have this work as well using Bonjour. What that's going to mean for you is that you'll just use the Bonjour APIs. Just like over Bluetooth, it's just going to work. But of course, it's not out yet.

Next topic, DNSServiceSetDispatchQueue. This a new API in iOS 4 and it's actually quite nice. It's very, very simple. You have a DNSServiceRef and you tell it, this is the queue I want to put it on. Before this API, when you use the low-level C APIs for Bonjour, you would have to create a CF socket run loop source or you would have to have your own kqueue loop or your own select loop. You'd have to call DNSServiceProcessResult or all these things you had to do in order to get it to work with the C API.

Now, however, it's going to be just one line of code, right? You start up your browse like you did previously, but now instead of creating and putting something in your select loop and calling DNSServiceProcessResult or creating a CFRunLoop source, all you have to do is call the SetDispatchQueue with your DNSServiceRef and the queue you want to put it on. In most cases, it's going to be the main queue.

Now if you're new to iPhone development or actually you're just new to iPhone OS 4, to iOS 4, GCD is seriously the coolest thing since sliced bread. I love GCD. There is the GCD on iOS session immediately following this one in Russian Hill. I invite everybody to attend that, please. That's it for that API.

It's really simple. Now on to the new hotness, multitasking. So we're going to go through a timeline here. What happens when your-- a standard multitask in your app. Now, there's some other kinds of apps you can be. You can be a VoIP app. You can do some things with locations, things like that. I'm not going to cover those. Those are covered by the multitasking sessions.

I'm going to talk about general networking in applications that are not VoIP and not doing audio streaming and things like that. The first thing that's going to happen when the user hits the Home button is that you're going to get the applicationDidEnterBackground callback on you application delegate. At some point after that, your code is going to stop running.

Now, you can request a task completion and that'll extent the amount of time that you get to run but not really all that much, right. At some point, your app is going to be not be scheduled anymore by the kernel. There is no indication when your application actually stops running. The only indication that you get is that your application did enter the background.

Some point after your application stops running, your Bonjour operations may be canceled. In order for us to do very efficient and effective multitasking, the system is going to reclaim resources. Not necessarily always but it does this so that the other applications that are in the foreground can actually get a much better experience. The other thing it may do is reclaim the actual networking sockets. Now, it's not actually going to close your sockets. It's going to do something much more akin to a shutdown and you don't know it's happening, right. Your application is not actually running right now.

You're not scheduled on the processor so you have no idea that this is going on and that this happened. And again, it doesn't always happen. This is when the system decides to reclaim some resources. So at some point in the future here, your code is actually going to resume running. But again, you don't really get any kind of notification this is happening. You're just going to get scheduled again and your code's going to start running.

What's important to note here is this is when you should deal with the aftermath of these things happening, right. This is where you need to be robust to errors on your networking sockets, errors in you Bonjour operations, all these things, because this may actually happen depending on scheduling before you get applicationWillEnterForeground. Do not use applicationWillEnterForeground as a notification that you need to clean up your world. Your world may be dirty before that because your application actually started running on the processor before you got this callback.

Now, in general you should be robust to network issues, right? This is not just multitasking. I can walk across the room and now I'm closer to this set of MiFis so my networking is going to be busted, right. So just the usual walking around might have effects on networking. So be robust to networking issues, right including things that happen when you get resumed after multitasking, after going in the background and coming back up.

So merely building with iOS 4 gets you this behavior, right? Your application will go into the background, it will get suspended. After a resume, all your Bonjour networking may be broken for your app. You'll no longer be advertising anything. You'll no longer be discovering anything. Your network sockets might be closed.

Detect and fix that broken state or the user experience with your app is going to be worse than it was with iPhone OS 3. This is very, very important, right? There's no UI for users to go exit your app, at least no UI that they're really going to understand, right. There's no Quit button. There's nothing that says I want you to relaunch my app from scratch.

If your app doesn't clean up the first time it resumes, your app is going to be dead in the water. When the user switches back to your app at anytime in the future, you don't want it to be host, right. You want it to work again. So be robust to these kinds of errors even if you're not getting a resume.

You might get networking errors for other reasons. So if you're using the NSNetService or the CFNetService APIs, you'll get called back with an error code. When you get callback with that error code, restart your Bonjour operations if that's where you are, if that's where you want your user to be. Again, you shouldn't be browsing all the time. You should be browsing or resolving when the user actually wants to because there are some power implications and things like that.

With the lower-level C APIs, if you're calling DNSServiceProcessResult yourself, check for the return code ServiceNotRunning and then restart your Bonjour operations. If you're using the new SetDispatchQueue, it will call all your callbacks with ServiceNotRunning because again you're not calling DNSServiceProcessResult yourself. You're letting all the cool dispatch stuff take care of that for you. When you get ServiceNotRunning, restart all your Bonjour operations.

If you're using the low-level C APIs, we highly recommend that you use the new SetDispatchQueue API because it allows for us to do future improvements, right? In the future, we could automatically start all the things back up for you and you will not even get errors when you resume. And the last thing is you can actually opt out of this behavior by adding this thing to your info.plist. And now back to Stuart.

Thank you Rory. So, in other news we just released Bonjour for Windows 2.0.2 and this brings Bonjour on Windows to feature parity with Bonjour on Mac OS 10.6, Snow Leopard. It's installed with iTunes on Windows, with Safari. Now with Bonjour Print Services which lets Windows machines share printers on your Mac.

There's an SDK for developers which gives you additional tools and the header files, the documentation. One of the key new things which you will be happy about if you're a Windows developer is we have the new shared connection mode. And I'll talk in a minute about why that's useful. We have some stuff code to do weak-linking. I'll explain that. And it also supports Sleep Proxy just like Snow Leopard.

You might ask why does Apple do Bonjour for Windows? Well, we want a world where network products talk to each other effortlessly. And a lot of you guys are making applications for the iPhone and a lot of those applications may want to synchronize data with information on the user's home computer. And we don't want you to have to do one set of things for Macs and something different for Windows. So, you can use the same network protocol, a very efficient, mature, robust service discovery protocol and have that available on Windows as well.

On Mac OS X, adding event source to your run loop is very easy and every Bonjour operation in the original API stands alone as its own event source. The feedback we have from Windows programmers is that it's not so easy on Windows. The way you typically program on Windows is you make the list of sources you're waiting for then you tell Windows to wait for something interesting to happen with one of those sources and then when it returns you process the events.

But having-- creating a new operation while you're waiting means you've got to break out of that loop and make a new list and go back into it. And it's possible to do. Many people have done it but it is extra work. So, we have this new mode which is also available on Snow Leopard and iOS which is where you make a shared connection and then you can add new Bonjour operations to that one shared connection which means on application startup you make a single Windows events source, put that in your WaitForMultipleObjects list and then you don't have to keep adding and removing event sources.

The way that works is first you call createConnection on startup and then you copy that DNSServiceRef and do a new operation passing the shared connection flag. You can make another copy of that service ref and start another operation. Each operation can have a different callback function to handle the events or as in this case, they both have the same reply function but they have a different context pointer which is how the reply function knows which particular event has just happened relating to which operation. Typically, this context pointer would be a pointer to your object or structure or something else defining the state of that operation you're doing.

I always like to show things at the developer conference which are not made by Apple because this is an open standard and I'm always interested to see what the other developers are doing with it. RealVNC is now using Bonjour in their Windows and iPad products. I am going to show you that.

Their server for Windows advertises with Bonjour and their client on the iPad uses Bonjour to discover servers. RealVNC is using the weak-linking capability that I talked about. On the Mac, since the day before OS X, we had this concept called weak-linking. You could write an app that linked to some feature that was new in Mac OS 10.6 and if the user ran it on 10.5 they wouldn't get a DLL link error. The application would still launch but its functions would be effectively like null function pointers.

And you as a developer could know that and check those functions were not null before you called them and that way your application would still run. It just might miss some of the new functionality but it's not going to fail to launch. It came as a surprise to us that Windows doesn't have that.

So, that means developers have to roll their own functionality and again this was feedback we heard from developers and in Bonjour for Windows 2.0, we do that for you. We have helpers to help you link in your library and it does the DLL calls to see if Bonjour is installed and if it's not installed then when you call the function you get an error and so it uses that so you don't have to have Bonjour installed to use their server and if it's not installed, their server will try to advertise the service and get an error and it will continue and run correctly. But if Bonjour is installed then the server will advertise with it. So let's see if I can show you that now. Okay, so, I have my machine here running Windows and I have my iPad.

I will-- this is the RealVNC VNCViewer and I can run this and this is the out of the box configuration. Let's see what's available on the network. And without typing in any configuration information, this has used Bonjour to find a couple of VNC servers it can talk to. This version displays the IP address.

You wouldn't do that in a normal application but one thing you will notice here is those addresses say 169.254 and I'm pointing that out because I'm not connected to any of the network here. This is just on my laptop here. I created a wireless network and on the iPad I joined it. There is no DXUP server.

This is a TCP/IP network with 2 devices on it. They pick their own link local addresses, they use Multicast DNS. They've discovered each other and this is a common developer mistake to say wait, I better use the reachability APIs and make sure I can talk to the internet and oh no, I can't.

I'm going to put up an error messages and refuse to work. You don't need to talk to the great mainframe in the sky to do useful networking. Quite often you may have a device that you just want to set up and VNC could be a great way of doing that and talking to that.

The reachability APIs are a great way to notify you. If you try to connect and you fail, you can use reachability to get a notification about when the network environment has changed. So it might be good time to try again. But there are terrible preflight checks because they can only ever make things worse. If you just try to connect you will either succeed or fail. If you use reachability as a preflight check before that it can't ever make a failed connection succeed.

A connection that would have failed will still fail but it can make you not try in a case that would have succeeded. So general lesson here and I highly recommend going to the sessions this afternoon at networking on iPhone OS, two parts. They cover a lot of details about dealing with networking in a modern world, particularly networking on mobile devices. I recommend those. And let's see what happens when I connect to this.

And so, with zero-configuration I have just discovered and connected from an Apple iPad device to a Microsoft Windows machine and you saw how easy that was. For any of you guys who've set up things like network cameras and tried to configure IP address and things. You know it can be something that you planned half a Saturday afternoon for. With Bonjour you just connect and it works, so let's move on.

So I have-- this is not a shipping product yet but I'm very excited. Oh I'm sorry, I'm getting ahead.

So, you all know that the iPhone uses WebKit as its HTML rendering engine. And I'm sure you know that Palm devices and Android phones use WebKit as well. And you know that iPhone OS uses Bonjour for its service discovery. Well I'm very happy to say that last month at Palm's developers conference they announced that Palm will also be supporting the Bonjour APIs and you can already get Android apps that use Bonjour by embedding a Java implementation of Bonjour but by the end of the year, I'm told that Android OS will have Bonjour APIs itself so that every app doesn't have to embed its own copy. So, you could use the same HTML 5 on all these mobile platforms and you can use the same Bonjour service discovery on all these mobile platforms.

Now I'm sure many people in this room have probably experimented with the technology called X10. For those of you who don't know, it's a power line signaling mechanism that's been around since the '70s, I think. And the idea is great. You can have a little module that you plug into the wall and you plug your table lamp into it.

And then you could have another device, a switch connected to the power lines that's not mechanically switching the power on and off. It's sending signals over the power line to tell that module to turn the lights on or off or brighten or dim. And this is a great idea for being more flexible about how you control things in your house.

But the protocol is slow and unreliable. There's no acknowledgment. There's no retransmission. So, for a lot of people it's a very frustrating experience. The promise is there but the reality doesn't really live up to it. And time is long overdue I think for something that is like X10 but works a lot better.

These products and they are not on sale yet so I'm not going to give the company name but look for these in the shops by Christmas, I hope. This is little module you plug in the power outlet and they have Wi-Fi in them and Bonjour and there's an iPhone app which uses Bonjour to discover all of these modules wirelessly, not over the power line over Wi-Fi.

And from the iPhone app you can tell it to turn on or off or brighten or dim but the difference because this is Wi-Fi is you don't press brighten 4 times and two of the packets got lost so you have to press a few more times to reach the right brightness. That kind of worked when a human is doing it but when a computer is controlling things, it can't tell how bright the light is by looking at it so you really need something reliable.

So, you can send commands to the module to turn on and turn off and brighten and dim. That circle on the front is actually a push button so you can override it. So, if you don't want to dig out your phone you can press the button to turn it on and off.

And because it's all software controlled when you press that button, it can signal back to the app on your iPhone or your computer that the button was pushed which you can use as a trigger to turn other things on or off in the house. These things also have a power meter in them.

Some of the people in this room have probably bought power meters because they are curious about how much power their television and their computer and their printer take. Well, these have power metering built into them. So you don't need a separate box with an LCD display. Just on your iPhone screen, you can see the amount of power that's being consumed by each device plugged into these things and even chart it overtime to see the refrigerator compressor cycling on and off.

And you can use that as a trigger for events so that when you turn the television on it senses the increased power draw and sends messages to other modules to tell them to turn off the lights and turn on the amplifier and you can build all of these things that communicate with each other and automate things in your home over Wi-Fi using Bonjour.

So, the whole Bonjour team is very excited about this and we're going to be first in line to buy these as soon as they go on sale. This was exactly the kind of thing that I hoped to see happen when we started the Bonjour effort ten years ago.

Bonjour is not just about desktop Macs and PCs, although it's certainly good that we make those easier to use but where it's critically important is devices like this where you can't hook up a screen and a keyboard to configure them. They absolutely have to be bullet proof and self configuring and you can't afford the tech support costs of people calling up trying to work at how to configure them. You have to just have them plug in and work.

So with that, I'll get to our tips and reminders. You've heard this in other sessions and I'm going to repeat it here. Make sure your applications work with IPv6. IPv4 has link-local addressing but it was kind of an add-on after the fact to IPv4. IPv6 has had it built-in from the start and the API supports it more elegantly. So, we wholeheartedly recommend IPv6. We use IPv6 in our own base stations, that's how you configure AirPort Express is with an IPv6 link-local address to communicate with it.

You'll hear this message in the iPhone networking sessions. Networking is asynchronous. Things don't always in the real world like they might work in your lab. Here's one example. If you do asynchronous blocking DNS call on your main thread and the DNS server happens to be not responsive for that user, the standard DNS time matches 30 seconds. Well, your app will get jettisoned after 20 seconds if it's not responsive.

So, your app dies. People say why don't you just make the timeout shorter? But that really isn't the answer because even having your app unresponsive for 5 seconds is not a good user experience for the user. And 5 seconds may not be long enough for a slow DNS server.

So, the answer is not synchronous blocking calls and trying to get the time out right. The answer is to embrace the fact that networking is asynchronous. Do things on a background thread or even better, do things in an event driven basis using CFRunLoop or using the new libdispatch Grand Central Scheduling.

Some that we see sometimes in Windows applications is a Refresh button and we don't want to see that in Bonjour applications on Mac or Windows and if you think about the iChat Bonjour Buddy List think about the sidebar on iTunes, think about the Safari Bonjour list, there's no Refresh button. The list should always be fresh. So, the Bonjour APIs make this very easy. You start to browse you get out and remove events for the lifetime of that browse.

You don't have to have a timer the way you do when you browse every minute to see what's changed. We've seen applications that do a browse for 10 seconds and then stop and then another one and then-- That's actually harder on the network than just leaving the browse running because the browse settles off to a low query rate and then just pays attention to the events on the network.

Generally, we recommend using the window so when the user wants to connect to a service you may have a UI today where there's a field where they type in the host name. Well, you can still have that but next to that you can have a Bonjour button which brings up a browsing list. And for the time that list is on the screen it should be live. And then the user closes it and you stop the browse.

We prefer a window to a pull down menu because while the APIs exist from modifying a pull down menu while it's on the screen, it's disconcerting to use this. They're not really used to pulling down a menu and seeing all the things jumble around and change. So we recommend using a window not a pull down menu.

The way your client will discover instances of your service and not other services is that every service has a unique name. You don't have to pay to register this. Just go to dns-sd.org and make sure you register a unique identifier for your service. We often see in the wild on networks like WWDC here, we look at the services that are being advertised and we always see a few that aren't on the service type list. So, save yourself headaches by just going to that webpage, send the email, register your service type.

In the first version of Bonjour many years ago we had a domain parameter. And it was there for future expansion but it wasn't used at the time. Now, that we have wide area Bonjour and Back to My Mac, don't ignore the domain parameter. When you do a browse you get back name, type, domain, and the interface index and you need to store all of those or at least name, type, and domain and pass those three unchanged to the resolve call. We have seen bugs where people ignore the domain or they just hard code local and that works with local Bonjour but you're losing the benefits of Back to My Mac if you do that.

Don't ignore the port number. Historically, networking has had the concept of well-known ports. Port80 is the web server. Well, you can only have one port80 on a machine. So with fast user switching, if there's multiple application and multiple copies of the same application running they can't all have the same port number.

There are a lot of bits to software today that use a webpage as their configuration UI which is great but again, they can't all have port80. When you've got multiple computers at home behind the NAT Gateway, they're all sharing one IP address. There's only one port80 on that IP address. So, we knew this was going to happen and that's why the Bonjour resolve call gives you back the port number. When you create your service, you can specify 0 when you bind and the kernel will pick an unused port for you.

The register API has a parameter for you to say what port number you're listening on and that goes into the network packets and the resolve call will tell the clients we have seen applications. They do the resolve. They get back the address in the port. They ignore the port and try to connect to the well-known ports and that only works if you get lucky.

The first copy of the application may get the port at once but all the others won't. So, this creates situations with Back to My Mac or with other wide area Bonjour things where you can only connect to one thing at the group but the other ones that aren't on the standard port don't work when they connect to the wrong thing.

For your marketing materials and your packaging and your webpages, if you use Bonjour then you can license the Bonjour logo for no cost just like the Made for iPhone and Made for iPad logos to let your customers know that they can expect a painless, trouble-fee experience with your products.

If you're using the Bonjour APIs on Mac and Windows then you are good to go. If you are building pieces of hardware which we love to see then we have a Bonjour conformance test which you can run to help you find bugs in your implementation and if you pass that test then you can also use the Bonjour logo on your packaging. And I encourage you to run that test because it does help you find bugs that might cause trouble for customers in the field.

If you are doing something where you want a component that runs on Windows you can license Bonjour for Windows and that is also free with iTunes being on so many machines. There are a hundred million copies of Bonjour for Windows already out there so you may not even have to install it but if you want to include that with your software you can license that for no fee.

Safari on Windows has the same Bonjour browsing that Safari on Mac OS X does. So to wrap up, especially with things like peer-to-peer over Bluetooth on the phone, having an app that's constantly browsing all the time in the background has a toll in battery life. So, when the user hits the button to bring up your browsing list you start the browse and then leave the browse live so they're getting live information but when the user dismisses, it stops. That's what we recommend. We know that not all apps from Apple set the best example here.

iTunes has the sidebar that's browsing all the time but particularly on the phone, we recommend browsing when the user is actually actively looking for stuff but otherwise, don't be browsing all the time. And in the same vein, don't resolve everything you find because that could be very expensive. You're triggering a whole bunch of mechanism by resolving there that you really don't need to trigger until you're actually ready to make a connection.

Embrace the fact that networking is asynchronous. It can seem like a pain if you're used to non-network programming where the computer is in charge where you say do this and then do this and then do this and you'll write nice sequential programs the way we all learn to program. But networking like graphical user interfaces is one area where you are not in charge. In GUIs, the user is deciding what button to click next and in networking, the environment around you is deciding what's going to happen next. And fighting against that is really unproductive.

Pay attention to the multitasking issues that Rory told you about. You have to pay attention to the network sockets being broken because otherwise when your app resumes, it may not work and with no easy way for the user to quit it, we don't want to be in a situation where users end up rebooting their phone because they don't know how to fix the broken apps and use the Bonjour logo. This is the contact information for our technology evangelists. We have documentation on the webpage.

In the interest of full disclosure, I was co-author on this book. This is the O'Reilly Zero Configuration Networking book which is a-- I'd like to say it's a more cohesive form of documentation in the sense that you can read it safely in the bathtub. Later today we have the iPhone OS networking sessions which I highly recommend, the Core OS Networking overview, you can watch on video and the Multitasking on iPhone OS is going to be repeated on Friday.