This is the Core OS Networking Session. I'm Brett Halle. I'm the Senior Director responsible for kernel and networking technology for all of our products. And today we're going to talk a little bit about what we've been doing in terms of networking for the various operating systems and I'm going to start first by reminding people of how we got here.

As us humans have been trying to communicate for it seems like forever and we've tried just about everything we can to transfer information back and forth. Back in the early 70's you may all remember of the days when really things got started with Unix and systems of that time. Those of you who were back in that era might remember for example a system called Plato which was probably one of the first network game experiences; I know I ever had the opportunity to experience, it's pretty wild.

But in the early gnarly days of networking BSD, Unix and BSD Networking, it was interesting times, a very difficult challenge of getting everything configured and set up but when it did it worked pretty well. And over the years we've evolved quite a bit. Obviously with the advent of the Mac, we brought into play things like AppleTalk and LocalTalk, to try and bring the experience of networking to mere humans; and along the years of course involved more and more capabilities with Ethernet and Wi-Fi and the experience has been pretty good.

But over the past few years, there's been an explosion. Obviously with the advent of the phone, the iPhone and with the iPad the experience of networking has changed pretty dramatically. It's gone from being a world that is based on very static to being very dynamic. Today we're going to talk about the Core OS Networking which is the fundamental networking technology that all of our systems are built upon as part of Darwin.

It obviously starts with Unix, BSD sockets and all the things that you have come to know and love over the years; and on that we build quite a lot of other technology. CFNetwork, the Foundation classes and other application services and frameworks, things like WebKit and services like that that all build on all of this technology of the system. It all starts down at the core and Core OS as part of the Darwin Foundation as where I represent.

And we'll talk a lot about the technology we've been adding to that core plumbing today. And it's important to note that this technology that we have exists on all of the platforms; it's the same networking technology whether it happens to be Mac OS X Snow Leopard or it happens to be iOS 4 it's all built on the same fundamental core and while there are some minor differences it's built using the same both engineering teams and source code and technology.

So we've added a number of things as part of iOS 4 you've probably already noticed, but I wanted to remind you and introduce them to you if you haven't experienced them yet. First and foremost is IPv6. So with iOS 4 we brought forward the capability of v6 and brought it in sync with the technology that we have in Snow Leopard; v6 you might wonder why is this important? Well I'm sure you of course all have heard that we are running out of IPv4 addresses and next time when we meet a year from now I would expect that we have just a little over a month left before we've exhausted the available v4 addresses.

But we've brought v6 onto the iOS 4 platform because we believe it's an essential technology moving forward not only for being able to deal with the challenges of running out of IP addresses, but the fact that is we move globally and we're dealing with different challenges everywhere we go in the globe. Some places such as China and Japan are extremely focused on moving forward to using v6 whereas here in the states we're lagging a little bit behind although there's some great progress with folks like Comcast and others who are moving forward to delivering v6 to the home.

It should be noted if you haven't noticed already that we've enabled v6 here at the conference. So if you happen to have the developer preview or you're running Snow Leopard on your laptops, v6 is available over Wi-Fi and on your developer preview for iOS 4, you can get a v6 address and we have v6 support all through the conference this week.

But as part of iOS 4 we've brought the stack from Snow Leopard 4 to iOS 4 and we've also added some additional capabilities. For example, we've added the initial support for DHEPv6, particularly the stateless support, meaning we don't get the IP address from DHEP but because we take advantage of router advertisement, the capability that's kind of a fundamental capability that exists as part of IPv6, but we get the other important information that's necessary to get a good connection experience such as your DNS server address, search domains and things of that nature.

If you're writing to the upper layers of the system to CFNetwork and above, chances are your apps are already ready to go as far as IPv6 is concerned. Certainly v6 support is available and visible at the stack level all through the socket interface, CFNetwork and above, and if you're using CFNetwork like I said you're probably already done.

All you need to do is test and make sure everything works as you would expect and you should be good to go. However if you're not using CFNetwork, you may have some work that you need to do and should certainly be aware and check your code, particularly if you've got older source code that you're incorporating into your projects, potentially open source or other things.

When you're writing for v6 after using the lower levels, there's some things to keep in mind-number one write your code to be address independent; you're going to be now getting different responses from your DNS servers. It's very likely that you'll get some combination of IPv4 and IPv6 addresses in response to DNS resolution. And if you're storing or displaying IP addresses, you need to make sure that you're using the right data structures and that you are not making dependencies on what an IP address looks like.

And frankly you shouldn't really be needing to display an IP address for the most of the users unless they're very sophisticated. But use the APIs that are available for independent hostname lookups, getaddrinfo in particular, and again be prepared for dealing with a combination of responses depending where you are at.

Also make sure you're using the right data structures again for storing your addresses; and if you're using a kind of a conventional allocate open a socket, resolve your DNS name and then do a connection, you need to rethink that process because what you need to do first is resolve your DNS name and from that you can determine whether or not you're dealing with a v4 or v6 address, then open the appropriate socket and then make the connection.

And there's some appropriate APIs to use and some good documentation that already exists as part of Mac OS X that can help you do this effectively. Also if your apps are listening on connections, you want to be listening really only on v6 sockets because we do the necessary work to be able to provide the v4 connection for you. So you don't need to listen on both. Listen on v6 only and you should get the right experience.

The other thing is due to the nature of the legacy; that is, BSD sockets interfaces and others, that there are functions and structures that are IPv4 specific and you want to be avoiding those. Again, you need to start moving forward taking advantage of the fact that v6 is here and it provides a lot of important capabilities.

Not just the addressability challenges that we're facing but frankly it's a much better experience as you're dealing with peer-to-peer connections; because you can imagine for example in a room like this where there's quite a large number of you allocating the four addresses for being able to do peer-to-peer connections can be a challenge and chances are you'll exhaust even that addressability, whereas the v6 address provides considerable more flexibility there.

Another feature that we've enhanced for iOS4 is our support for captive networks. We introduced this capability of supporting captive networks in iOS 3 and what is a captive network? If you go to Starbucks or McDonald's or to the airport or to a hotel, chances are you've dealt with the situation that when you go to the Wi-Fi they want you to either click OK to agree to their use terms or you have to put in a user name and a password and credit card information because it's some type of paid connection. This is a captive network. And what's interesting is that a few years ago when these came into being, most of the experience from our users was most likely a laptop, when their first experience when they opened their laptop was to go to a web browser.

And when they tried to open their first page, they'd get this UI that would have them enter user name and password or accept terms. Well the experience on these mobile devices is extremely different. It's very likely that you'll be connecting to something else other than your web browser first.

The user is most likely going to be running your app or checking stock ticker or news or something else, and the web browser is probably not something that's going to be their first connection experience. And the captive network support that we put in place detects when you have connected to a captive network so that what happens is at the point of detection, the UI is brought up for the user regardless of where they are as opposed to requiring them to go to the web browser first.

And it will automatically keep track of any user info for log information or other information so that the next time they can connect to that network they don't have to go through the experience again and again. In addition if you're dealing with carrier hotspots because one of the things that we've seen is given the extreme load on the 3G networks, that the carriers are more and more providing free Wi-Fi capability if you happen to be a user of their 3G service because they want to get the load off of their 3G backend; that they provide free Wi-Fi and we detect when you're in those situations and we automatically will connect you so then again the user gets the right experience. One of the things that's new for iOS 4 is that we intentionally make the Wi-Fi interface unavailable or as a secondary interface while we go through the process of authentication.

During iOS 3 there could be situations where if your app was up and running and trying to use the network that your app and our authentication process would actually collide until the network was truly available. The Wi-Fi experience is usually you go and you associate to the network and then our experience has been well then you can start moving backwards back and forth. But the really is in a captive network that there's one more step which is this authentication step and so what we've done now is make the Wi-Fi interface so that it's not primary and available until we've gone through and made it non-captive and properly authenticated.

We've also introduced some support for our hotspot management applications. There's folks like Boingo and others who may need to provide some advisory information to us to let us know that there are Wi-Fi hotspots or SS ID's that they have an interest in that maybe we might not want to try and authenticate because they have more information than we do. So we've introduced some initial support in iOS 4 to make this process better.

Another feature we've added in iOS 4 is SSL VPN and this is a combination of some significant new OS level plumbing that we put in place to allow our partners, Cisco and Juniper, to implement SSL VPN solutions. SSL VPN is interesting in that it's kind of the current and moving forward wave of enterprise connection to deal with the complexities that we are facing with more complex networks particularly when you're dealing with mats and double mats and other firewalls, IP sec and existing or older forms of VPN connectivity may not be able to very easily connect and deal with negotiating through those network channels.

SSL VPN arose as a way to deal with these challenges to use the one fairly consistently known path for being able to get a connection which is the SSL connection port. And so what Juniper, Cisco and others have done is create, albeit proprietary, but solutions for being able to deal with these kinds of connections in all these various situations particularly in mobile.

So we've added a considerable amount of plumbing to iOS 4 to enable them to do that and they've implemented solutions for the platform that are available via the app store. But it's important to you as the developers to know that now there are some even additional ways that your users may be connecting into secure environments. Probably one of the most significant changes in iOS 4 is support for multitasking.

And when you're dealing with networking in the multitasking situation there's some things you need to be aware of. In particular when your app is backgrounded your network sockets will persist for some arbitrary period of time; but if the system needs those resources back they will be reclaimed and those sockets will be closed.

Which means you need to deal with situations in potentially failure conditions that you may not have anticipated previously. We encourage you to respond to going to background notification because when you do that there are probably things you can do to shut down connections or preserve state so that you get the right experience when your user returns your app to the foreground. Probably the most important thing though is you really need to deal with new forms of errors that you may not have been testing for before and make sure that you respond to all the situations where you may be getting networking errors.

This is one of these cases where reading the documentation is going to be really important. There are also a couple of other sessions going on this week that we strongly encourage you to go to be able to get more information on how to deal with things. Certainly documentation in these sessions can help if you're developing VoiceOver IP solutions or background music demo service, things like that play services. I encourage you to go to the adopting multitasking on the iPhone OS Part 1 and Part 2 sessions, as well as simplifying network using Bonjour sessions.

All these sessions will talk in a lot more detail about the challenges you'll face when you're dealing with multitasking. As I mentioned early on these new devices have really changed the experience that users have now as far as how they deal with networking. In the old days and it's kind of humorous to think of it in those terms, most users' network experience was using the browser and checking your e-mail and maybe a couple of other things; but the reality is, is that a huge number of applications that are being developed now are network-enabled; and this is the experience our users want to have when they have these devices, that's the advantage.

They can move anywhere, they can get access to information on the fly, it's really, really a cool thing for them to be able to expect. And what it means though for you as developers is a real significant change in your mindset in terms of how you develop networking applications. The mobility is not the exception-- it's the reality, it's the norm.

Things used to be simple, big computers plugged into UPS's in the wall. If you are an old-timer like me, you know, an Ethernet cable was a big coax cable that was connected to the back of the computer, probably there was an assistant administrator involved for configuring everything, and your entire local networking environment was under somebody's control. I'm sure you experienced yesterday that local networking environments may not necessarily be easy to control anymore.

Nothing is static anymore. And although networking when it was originally designed assumed a lot of static-- pictures in terms of its design model. The reality is that this is no longer the case and that everything is dynamic and you can assume anything will change-- signal strength, cell availability, Wi-Fi ability, whether or not the public or private Wi-Fi environment, whether you're dealing with VPN connectivity or whether or not you have a whole bunch of people in the audience who have brought their own base stations just to make demos challenging. All of those things can come to play. From the user's perspective networking is scary.

It feels a little like smoke signals, they don't really know how it works, sometimes from our perspective it feels a little like cans with string between them; but the reality is this experience usually cannot even be as good as that because at least if you've got the string you know you've got a connection.

What we need to do though, everybody in this room, is we need to make sure that if you're a user that it really feels like it's a magical experience; that the right things happen that they're not having to think about what's involved and all the challenges that are involved with their network experience.

So with that I want to talk a little bit about what I call the Networking Top 10 the things that I encourage you to remember while you're writing the next great app. Starting with number 10. Don't assume the network is free. The reality is that usage is likely to be and it appears from recent announcements from AT&T that it's very likely to be charged by time or amount. That you need to be aware that the traffic that you're putting over this connection might be costing you user money.

So if you can avoid unnecessary traffic, retransmitting information, transmitting unnecessarily large things when doing the scaling down on the device, that that's a wise thing to do. If you can make sure that you're dealing with potentially data-appropriate information and can keep your connections down you'll cost the user considerably less.

Certainly your 3G or Wi-Fi situation may be fee-based. If you're in a captive network they again might be paying by byte, they might be paying by time; these are things that you need to consider and to make sure that you're not spending the user's money when they're not looking.

Obviously if you've dealt with 3G and you've gone overseas and have turned on 3G data roaming for example and manage to get one of those bills, it's kind of scary. Nothing like a few thousand dollar bill when you get back from your trip to wake you right up; so again we want to be very, very sensitive to the fact that those things cost the users money. And again cache when you can. Number 9, robustly deal with network errors. The reality is in this environment, in a mobile environment, you're going to be dealing with networking errors that you've probably never dealt with before.

Connections will go down-- it's a guarantee. Just plan for it. Know that those things are going to happen, check for error conditions in your networking code in all cases, and unfortunately it means a lot of testing and in different environments. You need to make sure that you've tried all the various flavors of Edge, of 3G, whether you've done the various flavors of Wi-Fi because I don't know if you noticed yesterday in the keynote, one of the phones worked and the other didn't. You may not be aware but the older phones do not have n capability where 80211n whereas the iPhone 4 does.

And that's a situation where those two phone environments were on an actually different Wi-Fi network bandwidth frequencies and those things can impact what your experience will be. Certainly n will provide you greater throughput capability but you need to make sure you've tested for all those variants. Packets are going to get dropped-- just the nature of the beast in a mobile environment. And timeouts are going to occur. You in particular need to be much more aware with iOS 4 of how to deal with backgrounding; make sure that you're dealing with it intelligently and close things down when you can-- it makes sense.

Number 8 networking is asynchronous by definition. It is the most asynchronous activity that will happen on your system; and you need to write your code this way and unfortunately the number of apps that I've experienced that put synchronous calls on the main thread is kind of frightening and sad. Do not, do not put synchronous calls on the main thread.

If you are for example trying to get host by name on the main thread and you happen to be in an environment where you've got a flaky connection, or the DNS thing isn't responding very quickly, you've probably experienced that your app is going to get shot. Frankly, as a developer I'm surprised your user hasn't shot you. It's really a bad experience for the app to go away for long periods of times and not be responsive or to just quit unexpectedly.

And the reality is that because of the asynchronous nature of networking, you don't want to be putting things in a situation where it's going to block the user experience. Use event-driven APIs to give a better experience. Make sure you take advantage of things like Bonjour and the Foundation APIs and with RunLoop event sources and other things to get the right experience. Put things on threads when it makes sense to do so.

But most importantly keep it off the main thread; don't block UI. But also realize that there are some calls in the system that also return information asynchronously. If you're for example trying to do a peer-to-peer connection or connecting to a local network using Bonjour, you will get data returned to you of services available over time as they are discovered and are made available on network.

And the user really expects that that's going to be the case so you shouldn't just grab what you happen to get in just the few first seconds or two and only show that information but realize that it's going to be updating potentially as their connection remains live. Your UI needs to reflect the reality of this asynchronousity. Number 7-- link quality is completely variable.

We again all experienced that yesterday. Wi-Fi, 3G and some things that I've certainly have seen or will be seeing more of layered networks. Some airplanes for example today are now providing Wi-Fi on board. But obviously you're not getting Wi-Fi back to a cable, back to the ground, that would be amusing.

The reality is that they're going through some satellite connection or through some other secondary transport which is a lot worse than your initial connection. So you can't assume just because you've got a great Wi-Fi connection all the bars are up and everything that that's going to be the speed of your communication. The reality is that you might be stocked behind someday.

Turns out we happen to have some commuter buses that we use frequently and there's Wi-Fi on the busses that's great, but they go through a 3G connection and so again while it may look like it's all a great connection, you're dealing with potentially a lot of aggregated traffic on a much slower link behind your initial connection. You need to expect changes in speed; you need to deal with latency delays and other challenges and again packet loss. Number 6-- deal with no network conditions.

There's going to be situations where your user's in an environment where there is no network at all. My wife happens to be a teacher and every time I go into her classroom I'm convinced I'm in a Faraday cage. There's absolutely no signal of any type for anything. And if I launch an application that happens to use the network and I might not even realize that it's network enabled at first but because it has some network behavior built into it, and the Apple all of a sudden doesn't respond at all the way you would expect.

One example of this is an app that might have a synchronous, an asynchronous call on the main thread, and sitting there trying to resolve DNS when I've got no network. Well, all of a sudden that app is effectively dead to me. You need to make sure that you deal with the fact that the network may not be there when you launch, and more interestingly may disappear as the user walks down the street or they move from one room to another.

You need to deal with that and there's a few ways, good examples that I've seen either caching information, but giving people reasonable feedback to know their network isn't available they may not get quite the experience that they would hope for. Your app needs to behave intelligently, it needs to be graceful. Again test for this.

Number 5-- Assume the network is insecure. You may be in a public Wi-Fi environment, a hotspot; you might be here at the conference. What's the chances are that you've actually connected to a spoof network that somebody has actually created to look conveniently just like the network that you're expecting.

That's very possible and our users are certainly nowhere near as sophisticated as you are and can easily get in an environment where they're either in a public environment or somewhere where they might be in a spoof network. You need to be careful about the kind of information that you're moving over the line. Again, it used to be you could assume if you were running a certain class of application that would only be run in an enterprise environment and of course it was their responsibility to make sure everything was secure.

The world's different now and you're going to be dealing with various forms of communications and connections and you need to be sensitive to it. Don't transmit user information in the clear. If you can, take advantage of things like transport-level security (TLS) or other mechanisms for making sure that users information is protected.

They're trusting that you're going to do the right thing and again they're not network experts. Number 4-- Make sure you're IPv4/IPv6 agnostic. The reality is that v6 is here and if you have an application that's global or you're dealing with different environments, you need to deal with v6 now. It's available on iOS 4 and certainly it had been available on our desktop, laptop products for a number of years.

It's here in our products for you to be able to take advantage of and it's used throughout the world. Make sure you're not making any assumptions as to the kinds of address types that you're using, don't assume things or before, be prepared for multiple DNS resolution responses, and make sure that you check your open source and older source code for v6 compatibility.

For whatever reason you can't completely support v6, at least make sure you're not doing anything foolish so your app doesn't respond badly. Because we can certainly assume while v6 gets rolled out more and more to the world, that it's probably a good chance that there'll be a combination of v4 and v6 connectivity that's available. You at least need to make sure you deal with that well and make sure that if you do get v6 responses that you again respond intelligently.

Number 3-- Use Bonjour to advertise and find services. It's a dynamic world, nobody remembers an IP address and if you haven't experienced a v6 address yet, I challenge you to memorize one. I certainly, for whatever reason been doing this many years, I have a whole bunch of v4 addresses that seem to be permanently burned in my brain but there's no way in the world I'm going to memorize one of these v6 addresses. And the reality is that the user should never have to deal with this.

So they should always be using obviously for Internet related connectivity you would expect that they're going to be using DNS and various URLs and such for their connections. But more importantly if you're creating a peer-to-peer solution where you're sharing information over a local network, take advantage of the mechanisms that we've built into the system; use Bonjour. You can advertise your services; you can browse and resolve. It provides all the plumbing and capability to it to get a great peer-to-peer experience. And if you're using Bonjour you'll actually get the support for being able to do Bluetooth connectivity for free.

On the desktop OS it's worth noting that we also have some additional capabilities if you are providing a service; for example, file sharing or some other service that if you're running on top of Snow Leopard, that we provide this capability called sleep proxy support. What this means is in order to create as truly a green environment as we can, we enable this ability so if you've got a service on a desktop or laptop environment, a laptop that's plugged into the wall power wise, that that service will be available even if the machine is put to sleep.

Because what happens at the point of being put to sleep is that any of that service information that you've registered with Bonjour gets sent to a sleep proxy server that's on your network. The sleep proxy server can be an airport base station, a time capsule, Apple TV, these are all devices that are always on and can be in a situation to listen for those services even though your desktop machine may be in full sleep mode.

And what ends up happening is when the user connects to that service; the sleep proxy intercepts that request and does the necessary wake on land or wake on wireless to make sure that the actual service providing system is woken up so they can respond. That way the device can go truly into its lowest power state.

But this is an important capability so if you're doing for example, users doing iTunes sharing or file sharing or you're providing some service so that you can get wireless connectivity when they come back into the house, the right thing will happen when using Bonjour and with the sleep proxy.

I encourage you to go to the Bonjour session later this week to get more information. Number 2-- Power is important as performance. Obviously everyone wants their apps to be snappy and responsive, that's the expectation that everybody has but power is critical in these environments; portability means batteries and battery means a finite power resource.

Don't power up the radios more than you need to. You're going "Gee, how do I power up the radio?" You power up the radio by creating network traffic. And so if you're doing network traffic, one of the things we encourage you to do is be bursty. Someone said it's better to group your requests and get a lot of communication done as a burst, than it is to dribble things out over time.

Because as you dribble those connections or keep those connections open and active over a long period of time, most likely you're keeping the radio active, whether it be the Wi-Fi, the Bluetooth or the 3G and that means you're draining battery. The radios are probably one of the more significant ways you can drain battery from these devices.

This is why we've done what we've done in terms of the background capability, the multitasking; because experience has been certainly as we've seen in other platforms, that if you keep a lot of things active in the background that battery is getting drained at a kind of a significant rate. So we've worked very hard to try and get the best battery life experience that we can for users. We need your help to make sure that that experience is as good as it can be. Take advantage of push notification.

This is the one of the more equivalents to the sleep proxy if you will. Allow the advice to go to its lowest state and get a delayed notification to be able to deal with various events. Take advantage of push notifications when you can because that's one way you can avoid keeping connections open more than you need to. And again on the desktop and Snow Leopard sleep proxy support does a significant job in helping.

And finally Number 1-- you've got to assume that there's going to be change at any time. This is no longer a static world. Anything and everything as far as your network behavior is concerned will change. Your available interfaces, it's very possible that in one moment you've got a Wi-Fi connection, then it drops because of connectivity; they've gone into an elevator but you've got 3G connection capability or any number of other combinations or 3G is down and all you can get to is Edge.

There are a lot of things that may change in terms of the network connectivity and experience. Your signal strength and quality can change dramatically just in a matter of feet or sometimes just standing there because of other interference, right? So make sure you're not leaving connections open longer than you need to.

The more you're prepared for this kind of change, the more you're able to adapt to this and not be keeping a lots of things open and active, the less sensitive you're going to be to these kinds of changes and the easier it's going to be to give a good experience to the users. So you want to think about obviously what you're connecting is the key part of your value proposition you're going to have to keep the connections open.

But think about do you need to keep all these connections all the time, are there more efficient ways to make these things so that you can deal with change? And if you are keeping them open what do you do when there is a change in network state? Can you behind the scenes change the connection to take advantage of whatever the now available interface is so that the experience is a good one? The other thing to note is like I talked about earlier, you've got to deal with situations where you may not have a network at all at some point, but the network is likely to come back and this is where good networking behavior comes into play.

Take advantage of the way the system is architected to help you here. Use the reachability APIs for example, help provide notifications when the network changes state. One other thing to note here though is the reachability APIs are not a preflight check. You don't use the reachability APIs to say can I make a connection to this service? No. Try and make the connection to the service first; if it fails use the reachability APIs to give you change notifications and other feedback so that you know when it might be a good time to try again or deal with some other change in network state. Change is probably our biggest challenge as network developers; and this is one of the things that you're going to spend most of your time dealing with whether you're testing or other things.

You need to provide an environment that you're testing in to anticipate all the various change conditions that you possibly can so the user is not the one who is being the guinea pig in these situations. I didn't say it was easy but this is important as far as a great experience. So with that I want to encourage you to go to a number of sessions that are coming during this week. There's a lot more detail obviously than I can provide here in this short session.

So certainly for Bonjour, for peer-to-peer capability, for finding services, please go to the Simplifying Network Using Bonjour session on Wednesday. There are also a couple of sessions on Network Apps for iPhone Part 1 and 2, Wednesday at 2 and Wednesday at 3:15. This will get you into the details around CFNetwork and other APIs and services that are available on the platform.

I also encourage you to go to a couple of sessions later today if you're looking at multitasking. The Adopting Multitasking on iPhone OS, Part 1 and Part 2. Part 2 in particular I believe has a considerable amount of detail around how to deal with some of the challenges of multitasking; and so I really encourage you to take advantage of these sessions and of course documentation. So I think it's important to note the world has changed over the past few years. The iPhone made a really dramatic change in the user's expectations of how to deal with mobility; that networked applications really add enormous value to our customers, your customers and ours.

And the more you can do to give them this connective experience, the better. But unfortunately it means for you there's a lot of work to be done to make sure you deal with all the challenges that are involved. It's no longer as easy as it was a handful of years ago when the environment that you were dealing with was static.

I'm really looking forward to seeing the apps that you guys produce, I've had the opportunity to play with a substantial number of apps that are out there today that provide really great network experience for users. And I think as we move forward we're just going to continue to see this explode. Out of the 225,000 apps that are currently up there we know that a large number of them take advantage of networking.

They may not be obvious to the user. Some of it is for games, keeping track of the high score lists and things that they don't experience throughout the connection and running and playing of the app, but they experience it at some point. Whether they experience it as the primary capability of your application or the secondary one, the experience that you provide for them is key and we're here to do what we can to help you make that experience as good as we can.