Good morning. Thank you for joining me this morning, bright and early. My name is Brett Halle. I'm the senior director of engineering, responsible for kernel and networking technology. Today I want to spend a few minutes and chat with you a little bit about some of the new features and capabilities we've put in Lion and iOS 5, as well as talk about some of the key principles that you'll need to be thinking about as you're writing the next great app.

So first, I think it's worth kind of putting ourselves in the right context that networking has really been part of the human experience for quite a while now. Whether you go back to something as archaic as the telegraph, you still dealt with many of the same challenges and problems. It still was never fast enough. You had to deal with compression of data. You had to deal with data loss. You had to deal with latency issues and being charged by the byte.

The problems were very, very similar then as they are now. Just the scale has changed. Certainly, networking from the perspective that we care about really started in the '70s, certainly in the creation of Unix and certainly BSD and sockets and other things. There was a lot of technology that came together at that time. but it was all based on a model where the computers of that day were big. They took up large amounts of room, big air conditioning, generators, and other things to help keep them alive, and a big coax cable coming out of the back that ended up hooking into the network. And there were lots of people who were involved in administrating it and making it all work and dealing with it when it didn't work right. It wasn't until the Macintosh, really, that networking became manageable by mere humans. Possible to hook up something very easily using Apple Talk and hook a couple of computers or a set of computers and printers and things together and not worry about things like IP addresses and domain name registration or any of that kind of stuff. It was all about just hooking the computers together and using them and taking advantage of the services that were there. It was really remarkably easy. Not terribly fast, but remarkably easy. Along came the iMac, and the real key advantage there was making the experience of getting on the internet easy. Remember the ads of the day? It was all about how quick you could get from the box onto the internet. And if you remember, the computers of the day, certainly in the PC world, you had to deal with going out and buying a networking card and dealing with configuring. And I think, gee, there were things like RRQs and all sorts of stuff that had to be configured and config files and all sorts of stuff.

But the experience that we have has always, of course, been about making that experience easy and something that user doesn't have to deal with. iPhone came around and fundamentally changed the way we deal with the network. Up until that point, things were remarkably static. But the iPhone has really changed the way we experience the network. People take the internet with them.

It's in their pocket. They expect that experience. And certainly with the iPad, not only do you get that experience, but you get a very immersive multimedia experience to go with it. The people expect the ability of streaming video and being able to deal with things that are very interactive. And that's all fine and interesting, but the scope of this has grown dramatically. We're now dealing with hundreds of millions of devices, moving quickly towards billions of devices. When we started this little exercise of networking, it was a few thousand maybe, hundreds or thousands. We're now talking hundreds of millions and billions of devices. And it really proposes some particularly interesting challenges. So today we're going to focus a little bit on the technology that all the networking capability of our systems are based on. We're going to talk about CoreOS networking in particular. This is where all the plumbing is for networking and all the core capabilities are. This foundation is common, is the same between iOS and Mac OS. It's actually the same source code base that we use, the same engineers. We all build the same technology in both these levels.

So the things that we're going to talk about here really apply across the board. certainly the principles do. So first, let's talk a little bit about what features we've been adding to Lion and iOS. We've not really added IPv6. We actually put IPv6 in back in 10.1, but you may have noticed, watched the news over the past few months, that we've somehow or another run out of IPv4 addresses, or at least kind of at the top level. The reality is it's not something to panic about at this particular point, but it is becoming a bigger and bigger issue that v4 address space is really running out very quickly and that v6 is becoming more important by the day. You may be aware that tomorrow, in fact, is v6 day, where a number of sites on the Internet will be turning on v6 capability, and it'll be interesting to see how well that goes, that experiment. Again, we added v6 back in 10.1 and added support in iOS for mobile devices back in iOS 4. But we've added a lot of updates to this code base with these releases coming up, particularly syncing up these code bases with the latest from Kame and BSD. There's an enormous amount of changes that came with that, support for a number of new features, things like RFC 506, which allows for using router advertisements to be able to get DNS information. as well as support for things like DHCP v6, stateful and stateless. Stateful is DHCP like you would expect for v4 where addresses are vended out to the device, and these are really only typically used now in enterprise environments where they want to manage their devices. We also support DHCP v6 stateless, which is just handing out of the ancillary information, again, like DNS and other things that are used to help configure the device. I For v6 configuration, for most people, is dealt through the mechanism of router advertising. It's an awful lot easier to deal with v6 configuration, but we've added ways to integrate better into the enterprise and other environments. We've also added support for temporary addresses. Those of you who are familiar with v6 may be aware that a v6 address typically is made up of your MAC ID that is part of your device, And certainly, you don't want that information going out over the internet and being tracked, and people can tell who you are. So we provide mechanisms when you're outside of your local area for access to the public internet that we generate temporary V6 addresses so that you get anonymous connections.

We've put a lot of work in the plumbing for the system to support v6. Basically, if you're using the CF socket stream APIs or above, we'll take advantage of actually picking the best route to use, whether v4 or v6, based on a number of different statistical analysis things that we do and performance analysis that we do for the connections so that we ensure that we get the best connection v4 or v6. We don't specifically prioritize v4 or v6 over the other, but rather actually look to see which is the best connection.

Why is this important? Because one of the challenges that we see in v6 adoption is that there are a lot of places where, while you may have local v6 connectivity, somewhere along the way, there's a tunnel or other mechanisms that are in place that aren't working very well. They're either very slow or they fail completely. And so using the mechanisms that we've put into the system now, we can ensure that the user actually gets the right experience, regardless of the fact that infrastructure might be broken.

There's also new APIs for additional socket capabilities if you're writing to that level of the system to take advantage of some v6-specific capabilities. And frankly, we're feeling pretty comfortable being completely ready for v6 day tomorrow. Certainly I encourage you to try out both Lion and iOS 5 for that. Another thing that we've been working on is something we call captive network support. Now, this is something we actually added a couple of releases ago to iOS, A captive network is something very similar to what you see when you go to somewhere like Starbucks, where you connect to the Wi-Fi, you open your web browser, and it comes up with a sheet that tells you to click OK to accept the terms, or maybe put in information in case it's a paid Wi-Fi hotspot or something like that.

These were designed for the experience of a laptop, where a business user would go somewhere like a hotel or somewhere of that nature, they'd open it up and the first thing that they would do would be to go to their web browser. The reality is with these mobile devices the web browser is most likely not the first connection point to the network. And the challenge with these walled garden captive network environments is that for the user, if they didn't go to the web browser, it would just sit there and wait for them until they did. So we added the capability into the system to detect when you're on a a captive network and automatically make the necessary decisions in terms of either automatically connecting or bringing up a web sheet so that the user can interact as necessary with the hotspot environment. We support a number of different protocols, Whisper as well as EAP-Sim and others depending on the environment that we're in. And the OS again is involved in detecting these particular environments and will remember captive networks that you've been to before and reconnect automatically the next time you go there. The support for this is now on Lion and brings parity between Lion and iOS. We also added support back in iOS 4 for SSL VPN. There's basically a significant amount of OS-level plumbing support to support this that we put in, and we now have a number of clients that are available on iOS, Cisco, Juniper, and F5 in particular. Each of them provides their own unique vendor-specific feature set, and their clients are available via the App Store. This plumbing is now available online as well.

We've added a number of other enhancements to the network stack. In particular, support for IGMPv3. This is a multicast protocol, the ability to be able to deal with streaming video and others to a number of concurrent devices. We've brought it up to v3. This is also used very heavily in the gaming space, where you're dealing with, again, a number of multi-users trying to get information at once. It's a very efficient way of being able to broadcast information, and this brings up to kind of current standards.

We brought support in for packet filter, otherwise known as PF. Built into the system today is a mechanism called IPFW, which isn't really being supported by the community any longer. Most of the energy is being placed behind a packet filter, or PF, and we've brought that adoption into the system. We've also added a lot of mechanism within the stacks to be able to deal with different types of traffic throttling. Again, kind of the historical way of looking at how people interacted with networks is it was fairly single purpose. You may have gathered from things that we talked about yesterday at the keynote that there's an awful lot of stuff that can be going on in the background in terms of making sure that the user's information is brought up to date, that things might be backed up and others. But the goal here is to make sure that the user's experience of what it is that they want to do at any particular moment is the best. So we make -- have provided both mechanism and incorporated it into a number of the services we have so that things like background processes on IOS get throttled, basically reduce priority for its traffic so that the user's experience takes priority. And that for things on Lion, things for example like time machine backups and others, that traffic is also reduced relative to any interactive or real-time traffic that might be in place. We've added support for basically now that we have both the SSL VPN capability and have brought to parity a number of the VPN capabilities in the system online, we now use the same profile mechanism online as we do for iOS. So again, in an enterprise environment where you're dealing with configuration challenges, both these environments now work consistently. We've added support for 802.1X to both auto-detect and auto-connect on wired Ethernet, and we've done a lot of work to deal with what we call scoped interfaces, when you might also known as multi-homed interfaces. When you're dealing with something like an iOS device where you have a cellular interface and a Wi-Fi interface, they can end up being on very different networks and a very different behavior. Again, historically, as you look at your typical home computer, while you may have Wi-Fi or a wired connection, typically they tend to connect to the same network. So DNS resolution and things like that are the same over the two. The challenge is that you're dealing now in situations where you're connected to radically different networks, particularly if you've got VPN or other things as well. The way you resolve DNS, the way you deal with routing and such really needs to be different on an interface-by-interface basis. So we've added quite a lot of infrastructure the system to deal with this complexity and to make sure that when a service is requested, the right DNS resolutions and things like that happen over the right interfaces. We've done a lot of work on Back to My Mac to improve the connectivity, particularly how we deal with NATs. One of the downsides of the V4 world that we're in and the fact that we're running out of IP addresses is that ISPs put in place a lot of NAT level infrastructure.

And unfortunately, NATs really weren't how the Internet was originally designed to be used, and it causes a lot of interesting challenge in terms of being able to make connections. So there's a lot of work that we've done in terms of how to navigate through the different double NAT environments in order to be able to ensure that we get connectivity.

But the area where I think that's most interesting and certainly applies to everyone here is in the tool space. We've added a number of tools for you to take advantage of to make your network experience and development better. One of the first ones is NetTop. So I'm sure all of you are familiar with using Top at the command line. You bring it up, and you can get a reasonably good idea of what processes are running on your system, potentially how memory is being used, how Mach ports and other things like that, resources are being consumed. We've ended up creating a tool for NetTop to be able to do that kind of analysis as well for your network experience. So you bring this up. It'll show you all the connections that are currently active. It'll show you a sense of what kind of traffic activity is going on, when the new connections are being established, so that you can see in real time what's going on during different kinds of operations. It can be very, very helpful to you to run NetTop and then run your application and see what's actually going on and that the things that you're expecting to get opened up and connected to are actually occurring.

Another very important tool is the network link conditioner. The link conditioner is a tool you run online, which helps simulate real world customer environments for networking. And what it does is it puts in place, basically in line to the networking stack, either delays, dropouts, other things to help simulate when the user is out in the real world. Typically, we all have great connections working in developing our software. Certainly at Apple, we have an awesome network. The challenge is that's really not the network our end users are dealing with. Most likely, they're in a situation, even like here, where there's a lot of people competing for a limited resource, where there may be bad connectivity or no connectivity. And that can be very difficult to deal with when you're writing your software, because you're writing in this perfect environment. The network link conditioner allows you to select through pre-built profiles things like DSL, Edge, 3G, and that the apps that then run during that will behave as though you were on that kind of network, either with delays and latency or again packet drops or other things so that you can make sure that your application does the right thing. If you're writing an iOS application, you can also use this particular tool in the simulator. It's a great opportunity to turn on the network link conditioner, simulate an edge or cell phone environment, run your app in the simulator and see what's actually going to go on when you have situations like packet drop and others to make sure that your app deals with those error conditions appropriately. Lastly, we have a tool that we've added for iOS which allows you to perform a remote packet capture. Basically, this allows you to run your app on your iOS device, hooked up to a Lion machine, and be able to grab the packets that your iOS device is seeing, and then analyze them with things like Wireshark and others, and to be able to, again, kind of deal with potential errors or other challenges that you might be seeing. Again, a very, very helpful tool for being able to get a better sense of what your application is actually dealing with. You can then capture all these packets, analyze them later, or analyze them again in real time with some of the tools that are available.

I encourage you to go to a session tomorrow, which is the Cross-Networking in Depth. This is tomorrow morning, where we'll be demoing these tools and giving a lot more information about how to take advantage of them, as well as a number of the other features that I've been talking about, additional support for v6, et cetera, that is part of both Lion and iOS. These devices, the iPad and iPhone and other portable devices, have been very transformative in terms of the way people deal with networks. It plays a very substantial role in really changing the way we think about interacting with the network.

When you couple that with the fact that there's, again, hundreds of thousands of apps out there, and the fact that the great news is that a significant portion of them are now network-enabled, that we have to deal with the change in the way we think about networking and realize that mobility is no longer the exception to the way networking is done, but it's the norm. It's the reality that we have to deal with every day. Again, just to kind of put it back in context, networking used to be very static. The original design of our networking stacks that we all know and love were built on machines that were big, that didn't get moved, where system administrators configured everything, where you had complete control of your networking environment. And also, you probably may remember that in that particular time, there wasn't DHCP. So when you added a device to your network, you had to find the guy who knew what the available IP addresses were and what all the magic numbers were that you had to put in your configuration files. At best, it would take you quite a few minutes to be able to put together a network configuration. But most likely, if you didn't know what the information was, you had no hope. Again, everything used to be static. Certainly wasn't mobile. You're not about to put a VAX in your pocket.

The reality is of today, though, that the network is no longer static. Nothing is static anymore. The configuration changes can assume to be changed at any time. Signal strength, cell availability, Wi-Fi ability, whether you're in a public or private Wi-Fi hotspot, or whether you're connected to VPN. These are all part of what we deal with now and what really poses the interesting challenges that we have to deal with. The goal for us, both us, Apple, and us as the community that provides applications and services to our collective customers is that we need to preserve this illusion of magic for networking. I'm sure you all are familiar with this particular quote, but this is the challenge that is before us. Our job is to make all that complexity of networking seem like magic to the user.

So let's talk a little bit about some key principles that you should think about and put into play as you're working on your next great app or you're making the next version for iOS 5 or Lion. First thing to consider, and particularly given some of the things we talked about yesterday with services for iCloud, is that you really want to write to the highest level APIs that you can.

You get an enormous amount of benefit by doing so, by effectively future-proofing your application. You allow the framework and those level of systems to deal with the complexities of the network itself. So one of the benefits you get, for example, today is that you shouldn't have to deal with whether or not you're on an IPv4 network or an IPv6 network if you write to the right level of the system, CF network or above, and you don't make any assumptions, which you shouldn't be doing, you'll get this automatically, and as the internet continues to make this transition, you'll get it for free. Don't depend on the internet.

Transport level details. The reality is that you don't know if the user is going to be connected to a Wi-Fi or 3G or on a laptop, whether they're on a wired connection or not. Don't ever assume anything about those particular interfaces. The reality is they may change. Or you may be fooled into what actually is going on. And I'll give you an example. We happen to have shuttle buses that are provided for us as Apple employees for getting around the Bay Area. And one of the benefits is there happens to be Wi-Fi on the bus that we can use, and it's all great. Well, from a device perspective, I'm connecting to a local Wi-Fi that's really fast.

What I don't realize from a device perspective is right behind it is a 3G connection. And all those people on the bus are sharing it. So if I made an assumption that I'm on Wi-Fi and I have a great connection, and what's happening is somewhere downstream I've actually got something that bottlenecks the connection, you're going to be completely fooled. Don't assume the transport means anything.

The other benefit of writing to the highest level API here is that you automatically get the benefits of the framework and the infrastructure improvements that we do. We did an awful lot in iOS 5 and in Lion. Believe me, we've got more on the plate that we are trying to deal with because of the way that this space is growing, and we want you to be able to take advantage of it, and writing to the highest level you can, you'll get a lot for free. We do acknowledge, however, that one size does not fit all, that you're going to have applications where you have to deal with low-level APIs and low-level connections. Be aware, though, that you're going to have to deal with some of the challenges and complexities that come with it. Thank you.

One thing to consider is don't assume that the network is free. These days, the user could be connected anywhere. So they're 3G, they may be roaming, they may be in an environment where they're being charged by either bandwidth or by time. The Wi-Fi certainly could be fee-based if they're in a hotspot environment. They could be roaming. So any number of these situations can occur. Don't assume that it's free, and therefore don't abuse the connection.

Take advantage of the fact that assuming that this costs money and that you should really try and narrow your usage model as much as you can, but still give a great experience. But also be aware that power isn't free here either, that when you use and make a network connection, particularly an iOS device, you're firing up potentially a radio that's consuming battery time. The network is also a limited resource. I'm sure people in the big hall yesterday or today where you're in a large room, We're all trying to share one wireless network in here, and the reality is it's a very limited resource. If everybody just assumes they own it all, they're going to be in for a nasty surprise and probably a pretty bad experience. So think about the fact that from the user that they're dealing in situations like this as well. Consider the ways you can compress your information, how you can take, instead of, you know, small packet, lots and lots of little small packets going out, how you can cluster your information in transmissions so that they're much more efficient.

You should also consider caching things intelligently. If you can, possibly don't reload, download the same information every time you connect to the server or you connect to a service. And really consider performance as a key part of the experience that you have for your applications. Particularly, understand the trade-off between bandwidth and latency. Depending on your application, frankly, I think in most cases, Latency is actually the most important thing that you'll want to deal with. Latency is about responsiveness.

It's how quick can I get the information there and back and be able to react to it. Bandwidth certainly is important, particularly when, for example, you're streaming media, other things. Certainly bandwidth is a great thing to be able to make sure that you can get the best experience there. But that is not what most of us tend to deal with. And so make sure that when you're running your application, you're considering the impacts of latency in your design model. And then beware of what we call buffer bloat.

What we're seeing in terms of the experience on the internet as things grow is that cascading buffers, basically it's really cheap to add a few K, a few megabyte of buffers at various levels of the infrastructure. Each of them add, frankly, add latency and other delay into the experience of the network.

And certainly there's not a lot you can do about that. And if you're interested, by the way, in learning more about this, I encourage you to go to bufferbloat.net and read up on it. But there are things that you can do in your application to not have the same experience. Buffers are great, but they are not the answer to your performance problems. Most of the time, you can over-buffer your applications and then end up creating increased latency and, again, reduce the experience, interactive experience that you get. One of the things that we've added to iOS 5 and Lion is mechanisms to optimally allocate buffers as far as your TCP connections for the best performance. We encourage you, again, if you're writing the higher-level APIs, you'll get a lot of this benefit.

But as well, when you're designing your network applications, think about the impact of putting lots of buffers between the user experience and your network experience. Deal with network errors. Again, back in the day when everything was very static, you know, things didn't change an awful lot and you could kind of get away with not worrying about this. It was a rare event. I can walk five feet down a hallway and my network experience will change dramatically. And the reality is that connections that I have are going to go down, packets are going to get dropped, timeouts are going to occur. This is just the reality of networking these days. So you've got to be able to deal with these cases intelligently.

Make sure as well, for example, that you're dealing with situations on iOS that you're backgrounding correctly because those will potentially create error conditions as well if you don't shut down things that you can. When you come back, or if you do come back, you may find your connections have been shut down for you in order to be able to deal with system resource issues. So from the user's perspective, they don't want to know about all these errors, except in the rare cases where they've explicitly made a request to do something and you can't deliver it. They shouldn't know about all these details. Hide problems in the network whenever possible. Deal with them yourself and automatically.

Let me give you an example of this. I'm sure you've all used mail. And there's situations where the network may not respond or may not even be connected. You can still interact with mail very nicely, whether there's network connection or not. And it's only to the point where you actually make an explicit request to send or to retrieve mail that the user is actually informed that there's an issue. But they can continue to use the app and do things regardless of the fact that there are other problems. So you want to make sure that that's the experience that your user gets when they're dealing with the network. Hide all the problems that you can. Most importantly, though, the way to kind of get to that point is test using the network link conditioner.

With this tool now in place, you can, as you're developing, actually simulate the kind of failure models and conditions that your users likely be dealing with. In fact, it's not really so much test using the network link conditioner. It's develop using the network link conditioner. Get in the habit from the beginning point of writing your application of working in situations where you're going to be dealing with failure. That way your designs are resilient and you're not dealing with them late in your development process. Then, of course, once you get to the point where your app is good and solid, make sure you take it out and get real-world testing. Go on a bus. Check it on a car. Find places with captive networks. Go to Starbucks. the various kinds of environments that your customers are going to be using and make sure that you're doing real-world testing as well. Networking by definition is asynchronous, which means you should not be putting anything that's networking related on the main thread because your UI is going to sit there and spin. Again, we just talked about the fact that you're going to have all these cases where things are going to fail. You're going to have timeouts. You're going to have performance challenges and others. And if you put code on the main thread that's dependent on responding instantly, the user is going to be very frustrated.

In an iOS, it's very likely your app will get shot. Make sure that your networking code is on another thread and is not blocking the UI experience. As well, take advantage of the event-driven APIs that are there. There's quite a few of them. Certainly Bonjour, a number of foundation APIs that all use run-loop event sources. These are a great way to deal with these asynchronous kinds of situations. Bonjour, for example, allows you to go out and browse for services that might be available. It's a very dynamic process. It's happening in the background. New information can actually continue to arrive over time. Assume that you are dealing in a network where this is the kind of asynchronous behavior you're going to get. And make sure your UI reflects this reality. Your information may change dynamically. So should the UI. Again, assume the link quality is variable. You're dealing now with Wi-Fi, 3G, Bluetooth, whatever. There's all sorts of things that can interfere with it. Even in a home environment, just going between two rooms in a house, you may find, gee, I'm only 15, 20 feet away. You don't know that in those walls are big chunks of metal or other things that are potentially interfering or someone turned on a microwave or there happens to be a phone or something else that happens to be overlapped in that same signal range. There's a lot of things that can impact the link quality. And as a result, you've got to assume that it's going to change. And what I mean by that is just because you make a connection to a link and you happen to get a certain level of performance, don't assume it's going to be maintained at that level. Assume, in fact, it will change. And, of course, deal with, like the example that I gave earlier, layered networks, situations where the local connection might be Wi-Fi, but the back end connection might be on cellular or something even worse, with a satellite or who knows what. And assume that there's going to be changes in speed and latency, and you're going to get packet loss. Most interesting, though, is deal with situations where you have no network. And this is a big one.

We're all in situations where the network is effectively non-existent or not there. Don't assume that the network is always available. That's the experience the user wants to believe is there, but we know the reality is that isn't always the case. And again, as part of keeping up that illusion of a great network app, figure out ways of actually making sure that your app continues to behave rationally, even in these situations. Again, consider that you're on offline mode. And I gave as an example already Mail. But there are a number of other apps on the system where you can continue to interact with them, you can continue to get good behavior, And it's not until as a user that I explicitly request something that absolutely requires a network connection that I have to let the user know that the network's not actually there. They don't need to know.

Again, cache your content. If possible, provide limited content visibility and access in situations where there's no network. If you're a game, for example, and then you happen to use the network to keep scores and things like that up, just because you can't get to the score server doesn't mean that the user doesn't still want to be able to play that game while they're sitting on the airplane or doing something else. So again, don't limit the value of your application just because you don't currently have a network connection. And definitely avoid bothering the user with annoying alerts. There's so many different cases that come up. If they continually, when they launch the app, they see, oh, it got no network, or these particular error conditions happen and they get another alert, they're not going to really enjoy using your application. One of the situations that we've seen that-- and again, it's making dependencies on link and other infrastructure conditions-- is we've seen a number of applications today that we've tested in a v6-only network. Interestingly enough, a lot of them, their natural response is just to immediately assume that there is no network and they pop up an alert. But once you click OK and ignore that, in many cases, it actually continues to work just fine. Again, don't make assumptions about what the link is. Don't make assumptions about whether the connection capabilities are. In the situation with v6, there are actually v6 to v4 bridges that are out there that can actually make the experience, again, seamless if you let the system do its job. Assume the network is insecure. And this is a really big one. Again, you can't assume that the users in an enterprise or at home on their own private network, Chances are there are these days 90% of the time where they're actually out in public or somewhere where, in fact, they don't have any control over the network, and you've got to assume that that network is not secure. They're on a public Wi-Fi, some hotspot.

They might even be in a situation where they're at an airport, and they think they're on ATT Wi-Fi, but it just happens to be Joe Smith down the way who's conveniently created a little private access point so they can snoop all their information. This is a real concern, and you should assume that any information that you transmit is going to get picked up. So please don't transmit user information in the clear. In fact, take advantage of things like TLS and other end-to-end security mechanism encryption tools to make sure that your connections are good because you don't know what the environment it is and you don't know what the experience of the user is going to be. I'm sure a lot of you have probably heard about this tool called FireSheep. It's a scary little plug-in that you can get for Firefox. You run it while you're at Starbucks, and you can get various people's cookies that they use for automatically connecting to LinkedIn or into Facebook or whatever. This is a really easy tool that's available today for being able to get to people's information and take over. That's an easy one to do. There are a lot of other tools that are out there.

Assume that people are going to do bad things with the information that you're transmitting. And again, I've stated this a couple times, particularly given the transition we see ahead of us, be agnostic to V4 and V6. and Write to the highest level APIs. You'll get a lot for free.

But if you have code that is written to low-level APIs, you need to make sure that you're not making assumptions about address types or sizes because these days you may get either or multiple. If you're dealing yourself with DNS resolution, be prepared for the fact that you're going to get multiple address responses back. You're going to get potentially multiple v4 and multiple v6 resolutions for a given DNS entry. and make sure that you're applying the right logic for determining them. Again, we encourage you to use the higher-level APIs, and we have other mechanisms that you can use to even make this experience a little bit better. But be aware that these are the kinds of things you're going to have to deal with. And if you have open source or libraries that you're dependent on that are network-based, don't assume that they're v6 capable. If they're code that you have, you may want to go back and look at them. Chances are they may be a library you've been using for years. The rest of your app may all be ready, but you may have one little library that you're dependent on that isn't. And this is something that you need to make a particular point to test.

And lastly, I really encourage you to actually build a v6-only network. And you can use, again, a number of solutions today to be able to bridge v6 into v4 backbone networks, but at least so that your current application is dealing in a v6 environment and that the right thing happens and that you're comfortable it's going to work when the user deals with those kinds of situations. Also, if you are providing a service or you're looking for services, Bonjour is definitely the way to go here. It's a dynamic world again. No one ever remembers an IP address, although I can certainly remember the time where I would have to memorize my V4 addresses. There's no way in the world I can possibly memorize an IPv6 address. They're big, gnarly, and there's just no way in the world you're going to be able to do that. So use Bonjour. Use the other DNS services in the system, but certainly use Bonjour for being able to take advantage of both service advertising, browsing, and resolution APIs to be able to get a great experience for finding services and for being able to make sure that peer-to-peer connections are the best that they can be. If you use Bonjour, for example, for doing a peer-to-peer connectivity, it'll take advantage of the fact even to being able to use Bluetooth for peer-to-peer, because Bonjour itself is agnostic to the transport.

And then on top of all of that, on Mac OS, you might want to be aware that there's this mechanism called the sleep proxy, which allows you to also be a good power citizen as well. If you have a service, for example, if there's file sharing or screen sharing, but if you have a service that you're providing for Bonjour, you can still allow the machine to actually go fully to sleep, and the sleep proxy mechanism is something that basically takes advantage of an Apple TV or an airport base station, to make note of the services that your device will provide and wake it up using wake-on-LAN or wake-on-wireless capability as needed when that particular service is requested. Again, not only make sure that the user can find things, but that we don't have to keep these devices running and hot 24 hours a day, which leads right into the fact that power is actually as important, if not more important, than performance.

It may be great that the user gets this great experience, but if the device only lasts a few minutes, it really doesn't do any good. One of the reasons that we've pushed so hard for the experience for things like, you know, the way applications are backgrounded and others is because the user expects that the device is going to last all day long, and we have to make sure that that experience is preserved. So the fact that you're dealing with a portable device means that you're dealing with batteries and that when you use the network, that you are very possibly either powering up the radio or radios or keeping them hot, and they certainly draw an awful lot of power. And that's fine if you're, again, the point here is to have a great network experience, but there are things that you can do to help. For example, don't trickle data out over time. Little bits of data spread over time means that you're effectively keeping the radio hot or active constantly. And if possible, burst your data together, reduce the amount of times that you need to bring up the radio. You really have no way of being able to control of when that happens, but you can manage the way you deal with your traffic and connections and such to help let the system do that better. Take advantage of push notifications.

Pulling the server every little bit is not always the right answer to do things. There are ways to do this completely asynchronously and not keep radios and things hot. advantage of things like sleep proxy on your desktop and laptop devices for services that you might be making available. But reachability APIs also play a big role here. There are ways that you can use that to determine both connectivity and stuff to make sure that your experience is good and to give hints to the system so that it knows how it's being used as well. This leads right into, again, dealing with the fact that change is going to happen. It's a reality of the environment that we're in. The number of the interfaces that are available, whether your cellular network is connected, whether your Wi-Fi is connected or whether both are, your signal strength and quality, these things are going to change. Assume that in your design space.

One thing that you can do to kind of help yourself here is because you need to assume that there's going to be a lot of change, don't leave connections open longer than you need to because it's very possible that the connection that you had is going to get dropped because the connection actually changed.

So long-lived connections can be a problem, unless you're ready to deal with the implications of a change. And again, use the reachability APIs here. It will help you and notify you when there are changes that are occurring in the system. When you've tried to make a connection to a particular service and that interface is down, it can let you know that the interface is now available, our connections are possible. So take advantage so that it's not, again, in the user's face and that your app just deals automatically with these situations. If you do things using the facilities and services that are in the system, you really, as an app developer, even though I've listed a lot of challenges, there's actually a small amount that you really should have to do. There's a lot that the system will do for you. Take advantage of that.

Let it do as much of the work as it can. The key to most of this is not making assumptions. The only assumption that you can make The only constant in life is change. It's all about networking. Everything that we do, the experience that we provide our users, is about giving them this sense of connectedness.

It's about being able to provide network services and capabilities as part of your applications and add value to your customers. They expect a connected experience these days, regardless of the kind of app that you have. So be prepared for dealing with the changes that are part of a highly mobile world. Write your app assuming that absolutely nothing is static when it comes to the network.

Assume everything will change. And then test. Take advantage of the network link conditioner while you're writing your code, while you're developing your application, to test during the design phase. Test in real world environments. And make sure that you create artificial environments that will test the kind of failures that you know are coming.

And it's all about, again, helping keep that illusion of magic for networking. We all know in this room that networking is hard. It's complicated, and it's getting more complicated, given all the challenges that exist. But there's a lot that we can do to keep this illusion of simplicity, and we have got to do it together.

So with that, I want to point you to Evangelist if you've got more questions, Paul Danbold, and certainly the various forms and services websites. But more importantly, there's a couple of sessions I really encourage you to go to. Tomorrow, there's a CoreOS Networking In-Depth where we'll get into some of the tools and new APIs in more detail and give you some demos. And as well, on Thursday, there's a session on Bonjour and how to take advantage of network discovery and connectivity. With that, I thank you for coming, and hope you have a great rest of the conference.