Good morning. I'd like to welcome you to session 803, the Mac OS X Networking Overview session. I have the privilege of introducing this session. I'm pretty satisfied that the room is filled pretty well out here. This session is one of the more famous sessions during WWDC, at least over the past several years. We've had some great questions come up in the session, and I'm sure today will be no exception to that. So let me introduce Vincent Lubet, who is the manager for CoreOS Networking. Thank you.

So here's what we're going to go through. So the overall architecture of the networking in Mac OS X. There's been quite a lot of new things in the years since we introduced Mac OS X last March. And also we go through a good deal of the session will be about the APIs.

There's a large set of APIs you can use, and some hints and tips. So here is the overall architecture. So the basis in the core ways of the networking stack is in Darwin, and all of that can be taken advantage by that. So the application environment where they have higher level APIs.

So it's the same. I mean, those are our ongoing goals. It hasn't changed since last year when we did the presentation. So ease of use is very important. We'd like to have the networking as transparent as possible. Performance is very important for us. Both in terms for end user experience, but also because that's the same stack that is used by Mac OS X server. Extensibility, we'd like to extend the, I mean, to allow to extend the function of the stacks, and compliance with standards, going through new, embracing new standards as they come up.

So that's kind of summarized what the features we have. So we have both TCP/IP and Apple Protocol stack. For the link layers, we support Ethernet and PPP, and also PPPoE. Mac OS X also comes up with built-in firewall and NAT daemon. Also, it allows for dynamic configuration, so it ties into the ease of use.

You don't need to restart, or we try to reconfigure the system as dynamically as possible. And also, we have new, this year in fact, is the full set of zero-conf protocol that are supporting the support, the basis for Rendezvous. So, the core networking, which is mostly in the kernel, and also some BSD layers at the library level. So it's based on FreeBSD.

The API at this level that can be used by applications is the Socket Level API, which is more or less equivalent to the Open Transport APIs for Mac OS X. So the benefit of that is that it's easy to port Unix applications. So it's not necessary that we encourage new development of new applications to be based on the Socket API, but it allows for easy port of applications. What's new in Jaguar? So we, since last year, the networking stack was based on the FreeBSD 3.1. It was starting to show its edge, and so we did a complete overhaul of the stack.

brought in a number of bug fixes, which are always welcome. We also updated the firewall and NAT daemon. But the big pieces were the inclusion of IPv6 and IPSec. They are based on the implementation from the Kamei Consortium in Japan, where IPv6 is very important. And also something new in Jaguar is the support for PPTP as a basis of a VPN client.

So in addition to The networking stack in Mac OS X is not exactly the same implementation as FreeBSD. We did some, I mean, the Darwin kernel is multi-threaded and preemptive, which is so we have some different ways of protecting, for example, the critical section in the kernel. Also, the mBuff network buffers are implementation.

I mean, it's different from FreeBSD and allows for...

If some of you came to the Darwin presentation yesterday, you have heard that we, I mean, developing in a kernel comes with a lot of responsibility, so we'll talk a little bit in this session, in the session 8 or 9, about what are the constraints.

But, I mean, if you really need to write an NKE, we encourage you to work with us because the current solution is, you know, I mean, the implementation certainly will change of the kernel, and so we need to work with you if you develop an NKE so that you can be ready for change.

PPP also. So PPP is built in in Mac OS X. It's based on the PPPd, which is the open source. I mean, one of the most popular open source implementation of PPP. It's based on PPP, but again, we've added a number of enhancements so that it's not the same implementation. You cannot just build your own PPPd and just replace it.

So, Apple Enhancement is our implementation of PPPoE for DSL. It supports CCL script, the same modem script that you used on Mac OS 9 are supported in Mac OS X. For an API, currently the only public API to control PPP is in Open Transport. So, we support the OTPPP API set, and in Jaguar we fixed a number of bugs too, so that it's more useful. And the most important difference between the standard PPPd is that it's integrated with the system configuration that provides dynamic configuration. And so, a new injection... In Jaguar, also the important new feature in Jaguar is the PPPd client that provides VPN connectivity with Windows.

So, those were the, I mean, we did also a lot, we fixed a great number of bugs. The other day I looked at it, I think it's in the order of 300 bugs were fixed. So, we improved performance. I think that now we can easily saturate gigabit links with TCP traffic.

We also provide for, in Jaguar, we allow for detaching of network interfaces. That means that if you have, for example, an Ethernet device in a USB port, I mean, an Ethernet USB device. Now you can, when you unplug it, the stack will clean up all the reference to this device so that you can effectively attach and detach it.

And it was not possible up to Jaguar. Also, we've updated many, many main pages, which is one of the primary source of documentation for a lot of the APIs we have at the socket level. We also fixed the implementation of the NDRV protocol family. NDRV is Network Driver.

It's not the same as the... The NDRV graphics drivers. So it allows for to develop a user and protocol stack. So for example, it's a way to, I mean, you can take advantage of that instead of implementing a protocol as an NKE. If it's just for specific and protocol specific for an application, you can use those socket types.

And also new in Jaguar, and it was also something that a lot of people asked Apple to provide, is SNMP. So it's based on the NetSNMP open source implementation. And it has both console and agents implementation and supports the basic MIBs, MIB2, and things like that. So network configuration, so it's a cornerstone of the ease of use of the networking in Mac OS X. So certainly you know about the network preference panel and where you can see a set of-- Oops.

The Mac OS X is a set of services. Services provide the configuration for a network interface, if you wish. So, for example, for Ethernet, PPP, and others. So, more than one service can be active at a time. So, that's why we support Mac OS X, support multi-homing, and also new, I think in Jaguar, we support also the configuration of one service.

I mean, at least one network interface can be configured to have more than one IP address. So, it's multi-link, multi-homing that we support in Jaguar, right at the user interface level. So, the configuration is dynamically updated. That means that there's a daemon that watches for the status of the link.

So, that's where that supports the plugging and plugging, joining airport networks, and things like that. And all this is managed by the system configuration framework. So, that has implementation of the mechanism, but also APIs that you can use. So, different set of APIs. So, one, so access to the configuration, that means the stored information. So, something you can read and write.

Which is, so the current state of the configuration depends on the, for example, the status of the link, and also if you have, for example, the IP address can be acquired dynamically with DHCP. So, it's the second line, the state of the network, you can have dynamic information.

So also, something that has been, I mean, also that a lot of application who wants to behave correctly before issuing, opening a socket or network endpoint will, to prevent automatic dialing of PPP, we recommend that those applications first check for accessibility so that they prevent unwanted dialing. And there's a replacement for the Open Transport, the Mac OS 9 TCP will dial, and that's also part of the system configuration framework.

We have also a notification mechanism in system configuration so that you can be notified when something changes. And that's the basis also of the dynamic. The dynamicism of Mac OS X networking. So, all those APIs are available in, have been available since Mac OS X 10.1. And DTS came up with a very good sample code called MoreSCF that allows you to understand how to use those APIs. It's a rich set of API, and that's a very good guide to them.

Rendezvous is new in Jaguar. It's based on the ZeroConf IETF and the NRC, so it provides for, I mean, it allows for networking, local networking that always works a little bit, just like Apple Talk, in fact. So, but it's based on TCP IP standard. Most, I mean, it's as much as possible rendezvous and zero-conf re-users, already established standard like DNS and DHCP, with very small tweaks. So-- So it makes really, that's the, I lost for, Just plug and play networking.

And there are certainly ways you can maybe take advantage in your application if you provide the service. It's very easy to just register your service and make it available on the network. And to know more about Rendezvous and Zero Configuration networking, you should check session 811 where they go in deeper details.

Okay, now in a year we've learned, I mean in many years, we've learned a great deal about what are the best practices and how to write for networking and also Mac OS X. So solutions that used to work well, for example, with Open Transport on Mac OS X, don't necessarily work well in Mac OS X.

So for example, one of the big, I mean the biggest problem and the thing that can affect the most performance and also the user experience is polling. Polling uses, so all the CPU and Mac OS X, which is a multitasking system, it hurts, you know, other processes. So there are many system services that are just... implemented in user land, not in the kernel. So they run barely at... Just the priorities of those processes is not very much higher than a normal application.

So, and there are many ways to, many solutions. I mean, we have all the APIs out there that allows you to either to block. I mean, that's the typical problem. A lot of Unix tools, that's what they do. They block or you be event-driven. And certainly what you can use is to use, for example, at the socket layer, you can use the select system code to wait in a thread, for example, and block for network, wait for network activity.

And it's not,

The Open Transport stack was more tolerant about what size of buffer you're using. So you have to find a good compromise between two large and two small buffers. Because if it's too small, you have a lot of context switches. So the pathological case is reading or writing one byte at a time, for example.

And if you also use two large buffers, I mean, I've seen applications trying to use megabytes of buffers to pass through the socket layer, read or write. That's not, I mean, it doesn't, it just puts more overhead on the overall system, but doesn't get any better throughput if you want.

So you have to find, you know, I mean, a good... So the question is, what is a good value, and that depends. But certainly something in the order of, you know, a few, I don't know, something like 1010 to 40k, 60k, is something that is good for TCP, for example. What you want to try to achieve is streaming. And so something you have to watch for, so two things you have to watch for is the size of your socket buffer.

So by default, I think they are in the range of 32k. And... And also the other parameter is the size of the buffer you read in and out of the kernel. There is something also we've seen some pathological case where In the BSD implementation of TCP/IP, the socket buffer really corresponds to your received window size.

So if your application is not fast enough, for example, and doesn't empty the socket buffer size, the advertised window will shrink. And that means that you will see the hiccups in the stream of data. So that means that your process should be responsive. And use, I mean, when it receives data, doesn't try to receive data.

For example, there's one flag you can use in the socket, which is the message, "Wait all." You shouldn't wait for all the data necessarily. You should, as soon as you can read a few K, you should try to empty the socket buffer. And we'll go into a little bit more detail in session 809, which is Advanced Networking.

Also, something that is very important for applications is that, and let's say some of the Unix-like, now it's more the Unix side of the network applications, is that Mac OS X is a very dynamic system. We have portables, we have airport, everything you can plug and unplug. So, applications should be aware that there's not a single IP address, that the IP address changes over time.

And for example, servers should, I mean, there are very few cases where servers should know about which IP address it binds to. So they should just use any IP address. And the same for clients. There's no real good reason to bind to a specific address or port number. If you don't specify one, the TCP stack will choose one for you, an ephemeral one.

Vincent Lubet, Becky Willrich And also, you have

Finally, just a word about the Socket API. So that's the native API, that's the lowest level API we have in the system for applications to use. There's a lot of open source code available that you can learn about it. There's a very good book, Unix Network Programming by Richard Stevens, which is kind of the bible for us.

Because we have the Socket APIs, I mean, we really, really encourage all Carbon applications that still, a lot of Carbon applications have, in fact, were ported maybe from Unix or maybe Windows, and they have a layer, an emulation layer of Socket, so that calls Open Transport, and that was fine on Mac OS X, but if you run this Carbon application on X, you have, so you have the pseudo-Socket layer that calls Open Transport, which is itself called the Socket layer, so you have two layers of emulations where you lose performance and also correctness.

And, but the Socket-level APIs can be complex, and Mac OS X has a rich set of higher-level APIs, a little bit provided with more abstractions, and allows for...

So Vincent asked me here today to talk some about the APIs that are available to you above the operating system level. Hmm, I think I'm holding this wrong.

So what I'm going to talk about is what APIs are available to you, and then we're going to look at each API, or at least the largest APIs in depth. And for each one, we're going to talk about what that API does, what strengths it has as an API, what its limitations are, when you should use it, and what's new with them since 10.1. There they are. Nice long list. In Carbon, we have URL access and Internet config. In Cocoa, NSURL and NSURL handle, as well as the new NSNetService and NSNetService browser.

At the core services level, we have CF Network, Web Services Core, a number of pieces from Core Foundation, that's CFURL, CF Socket, and CF Stream, and then finally Open Transport. So how does that all lay out? Looks more or less like that. You can see where each of the pieces are.

The important thing to notice here is that everything is built on the solid foundation provided by BSD Sockets. Everything I'm talking about works through Sockets, works through TCP/IP by and large. The other important thing to notice is that anything in the core services layer is available to any application. It's also available to most any daemon.

So with that, let's just start with the APIs. I'm going to go pretty much from the top of the stack down to the bottom. So I'm starting the furthest away from Sockets and moving down into the basement. So at the very top we have URL access. URL access provides basic APIs for up and downloading URLs. It's basically intended as a convenience API that's totally focused on just fetching the URL. You don't want to look at the URL, you don't care about the network configuration, just get me the data.

As such, it's going to automatically pick up any system settings that are on the computer. But it also provides relatively few options based on the scheme. So if you need to do some tricky piece of HTTP, this is probably too high level for you. Out of the box, it supports HTTP, HTTPS, FTP, and file schemes. And it is part of the Carbon APIs providing source level compatibility back to Mac OS 8.6.

So its strengths are its simplicity, really. You don't have to know much about what's going on with the URL. Just go get it for me. It provides a number of options for extra processing, including, for instance, populating a file or directory. There are also flags for things like UI display and for automatic decompression. And of course, one of its big strengths is it provides source compatibility to Mac OS 9.

Okay, so what are its limitations? First one is there's no way to add any support for new schemes. If we don't provide it, there's no plug-in model, there's no way you can supply it. Also, the API is beginning to age. It did start in the OS 9 days. As such, you will see some ties that hook in directly to, for instance, the Thread Manager. Those are no longer really meaningful in the Mac OS X world.

In Jaguar and on Mac OS X, there are some unimplemented features. The most notable I've called out here so that you can know to avoid them. Progress Bar Display via either URL upload or download is not implemented. Automatic Decompression, also not implemented. Also, as one of the older APIs, there are some issues around Pthreads and cooperative threads coexisting. It did start as a cooperative-threaded API, so it still carries some of that legacy.

So when should you use it? Well, you should use it if you need a strategy that has to work on both OS 9 and OS X. You should use it if you need a scheme agnostic strategy that's based in Carbon. And you should use it when you want that simplicity, when you don't want to know anything about the details.

We have done a fair bit of work with URL access since 10.1. There have been a lot of bug fixes. We've got progress display working now from inside URL open. We do a better job of scrubbing failed transfers off the disk. Redirection is working. There's better event handling and notification throughout. In particular, system events are coming through cleanly now to your callbacks. And there's better error handling throughout.

The other Carbon API I'm going to talk about some is Internet Config. You probably all know what Internet Config is. You've probably all used it. It holds basic networking settings of a variety of kinds. So included in that are web proxies, instructions on which helper apps should be used for downloading which kinds of URLs. There's an elaborate type database that maps MIME type to type creator into extension.

Some people have used Internet Config to store app specific preferences as well. And you will see a handful of user preferences in the Internet Config database as well. It is primarily a legacy Carbon API that was created on Mac OS 8 and 9, and that we have carried forward as part of Carbon.

Its strengths are precisely that it is of such long standing, it's well known and well understood, it's your only option on Mac OS 9, and it provides compatibility with Mac OS 9. On the other hand, on X it has a number of limitations. The implementation on Mac OS X is not as efficient as it was on IX. You can mitigate this somewhat by using ICBGN and ICN. There's an excellent tech note on this if you want to look that up. If you just bracket your calls-- bracket subsequent calls with ICBGN and ICN, you'll see a noticeable performance increase.

Some of the settings inside Internet Config are dated and insufficient. There are, in many cases, there's only a single setting provided, where in the modern world you might expect several. Some settings are completely obsolete and no longer meaningful at all. GetConfigFile and all of its friends are a good example of that. And it's no longer the final authority. It's no longer the repository for many settings. So when Internet Config fetches some of those, it's going to have to go through a translation layer, and there's a performance hit with that translation.

Also, for what it does, it's going to force a higher level linkage that's really warranted. You're going to be linking at the application services level, where all you're really doing is fetching a bunch of data, and you might want that at a lower level, like core services or possibly even the OS.

So at this point, we're recommending that you only use Internet Config if there's truly no other choice. Look instead for other frameworks to provide your needs. The two big ones to be aware of are System Configuration, which provides all the information about your proxies and about the current network setting.

Or Launch Services, which knows how to open files and URLs and is maintaining that database for you of mapping types to type creator to application. If you have used Internet Config to store your app-specific preferences, stop it. Internet Config is a shared resource on the system. Every preference you put there is a burden to every other Carbon application. Instead, use CFPreferences. Keep your preferences in their own space.

So, nothing new here. We haven't done a thing with Internet config since 10.1. With that, I'm going to move on to the Cocoa APIs. I'm going to start with NSURL and NSURL Handle. These are sort of the Cocoa equivalents of URL access. This is the convenience API. Here's a URL.

I don't know nothing about it. Just get me the data. Unlike URL access, NSURL and NSURL Handle exist below the UI layer, so they do not have integration with some of the higher UI elements. But that also means they don't force you to link against a full application framework to get it.

Two classes, NSURL and NSURL Handle. NSURL just represents the URL. It's bridged to CFURL, which you've probably used. NSURL Handle, on the other hand, is the piece that actually performs the download. It's the piece with the state engine in it. It's the piece that actually knows how to build the network connection. These two classes together were designed primarily as an infrastructure for handling URLs, much of the same as Java Net URL is and its associated classes. However, out of the box, we do provide support for HTTP, HTTPS, FTP, and file.

So NSURL handles strengths are really its integration with the surrounding frameworks. In particular, it's well integrated with the run loop, which means you're going to have an asynchronous API which nonetheless is not spawning any additional threads. It's easily extensible via subclassing. It's designed to be extended via subclassing.

And it's well integrated into all the Cocoa APIs. So, for instance, the NSImage class, as I'm showing here, can be initialized from the contents of a URL. Well, NSURL handle is what's actually doing the work. So if you extend NSURL handle, NSImage is automatically going to know how to initialize itself from the new kind of URL you've implemented.

We're also seeing extremely good performance under load using NSURL handle. And as just one example, the mail application on Jaguar downloads all of the HTML mail, all of the HTML images using NSURL handle, all on the main thread. And we're not seeing any kind of a delay in processing user events.

So what are its limitations? Many of the extras that you get with URL access are missing. In particular, there's no UI integration. We live below the UI level. And there's no way to do things like automatic decompression, content handling, automatic population of files, all of that kind of thing.

The documentation for NSURL and NSURL Handle is not complete. There is some there and it will get you started. There's also some good examples on the CD. And many of the Cocoa APIs, which all started as file-based APIs, have not made the full transition to accept arbitrary URLs.

So when should you use it? Use it when you want a simple download abstraction and for whatever reason you don't want to use URL access. Keep in mind that although this is a Cocoa technology, we've reached the point now where it is not a large burden for a Carbon application to link in foundation.

So as a Carbon application, an NSURL handle is available to you. It's also the only API on the system that will allow you to automatically extend and add your own handling for particular kinds of URLs. You can add your own scheme handler, it will automatically be picked up by the Cocoa APIs.

We've made a lot of changes and additions to NSURL handle since 10.1. We've added support for FTP. A lot of the bugs have been shaken out. We've moved to an asynchronous domain name lookup, so you'll no longer block waiting for us to get the answer to what the IP address is for a given host. And we have integration with system configuration planned for Jaguar. That's not on your CD, though.

Okay, I'm going to touch briefly on NSNet Services. NSNet Services is brand new in Jaguar. This is Rendezvous, or ZeroConf. This is the Cocoa API that makes it possible for you to register and discover other services out there on the net. Two classes, NSNet Service and NSNet Service Browser. They're implemented on top of CFNet Services inside CFNetwork, which I'm going to talk about in a little bit. But I just did want to highlight that this is a Cocoa API available to you.

So that's it for Cocoa, and now I'm going to descend into that green bar in the architecture diagram, the core services bar. And I'm going to start with CF Network. CF Network was first introduced in 10.1, and it provides a number of low-level abstractions for some basic networking concepts. Now, CF Network is often confused for being a library like URL Access or NSURL that's focused on URL download. That's not true. That's not the intention behind CF Network.

The CF network provides APIs to allow you to directly access and manipulate SSL or TLS socket streams. You don't have to get involved in the details of managing that. It also provides a full HTTP 1.1 engine, and it provides the new Net Services APIs that provide access to Zero Conf Rendezvous.

The primary focus of CF Network as a piece in that core services layer is on high performance but small footprint. And we use it throughout the stack ourselves. It's used by NSURL Handle, Sherlock, Software Update, iPhoto, Web Services Core. It's also used by iChat, which you saw demoed in the keynote. We use it pretty heavily in-house.

So what are CF Network's strengths? It provides complete exacting control of the HTTP transaction. You can manipulate the request directly in terms native to HTTP. If you understand the spec, you can use CF Network very easily. It has full support for HTTP 1.1 that includes pipelined persistent connections and digest authentication. There's full integration with the run loop, so you can use the HTTP engine and the socket streams in an asynchronous fashion, again, without having to fork threads.

And it gives you the best performance you can get from a networking API in the Mac OS X stack without dropping into BSD sockets. And in fact, our measurements show that as far as throughput, CF Network will give you the same bandwidth, the same performance as raw sockets, if you do so much as hit the network card. The only time we could see a performance difference between CF Network and raw sockets was in hitting the loopback address.

Limitations. Well, the limitations are sort of the flip side of the strengths. This is not a convenience API. It's not simple the way URL access and NSURL are simple. No FTP support in CF Network, and it's brand new, so the documentation is pretty scarce. So when should you use CF Network in preference to some of these higher level frameworks? Use it if you know your transport is HTTP and you want control. Use it if you want a simple SSL encrypted socket and you don't want to get involved in the details of SSL, don't want to figure out an SSL library.

Use it any time you want more control than the higher level APIs provide. As just one example, the higher level APIs are going to dictate the threading model to you. NSURL requires run-loop integration. URL access requires spawning threads. If that doesn't fit with your model, drop to CF Network. It will accommodate the threading model you want to use.

Use it anytime you want to avoid linking with higher level frameworks. Maybe you have a piece of code that needs to work with both Carbon and Cocoa. Maybe you have a piece of code that is going to run in a high performance daemon and you don't want the hit of linking high. and use it anytime you need features that are only available in CF Network. The big example of this is Rendezvous. If you don't want to link in Objective-C, CF Network is your option for accessing Rendezvous.

So what's new since 10.1? Well, we've moved up to full persistent connections in the HTTP engine. We've added the Net Services and Service Discovery APIs. We've added support for SOCKS proxies, that's v4 and v5. We've added digest authentication to the HTTP engine, and we also have added an asynchronous hostname lookup.

Now I'm going to briefly touch on Web Services Core. This is also a new API, brand new with Jaguar. Web Services Core is a client framework for accessing web services like SOAP or XMLRPC. Brand new in Jaguar, based on CF Network, and as such, it exports new CF types, and it's friendly to run loops and run loop integration. It does have support for authentication options, but in Jaguar it's for HTTP, HTTPS posts only.

All right. I'm going to move on down even lower. Now we're going to look at Core Foundation, which provides what the basis that CF Network builds on itself. There are four interesting CF types when you talk about networking support in Core Foundation. CFURL, you've probably used, simply represents the URL string. Allows you to parse out the different pieces, examine the URL, but has no knowledge of how to actually fetch the URL built in.

CF Socket allows you to take a Berkeley socket and manage it directly on the run loop. That's where NSURL, CF Network, NSURL Handle are all getting their basic support for receiving socket data on the run loop. and CF Readstream and WriteStream represent one-way byte streams to and from any of a number of different sources.

Files, sockets, or memory are the three I list here. There are also some dirt simple functions inside Core Foundation for fetching a URL, but they are dirt simple. If you're doing anything at all complicated, they're probably not what you want and you need to link a little higher.

So the strengths of what's in Core Foundation are here. CFStream provides a simple single abstraction that hides away the details of what the source is. When you work with a CFStream, you do not need to know whether you're talking to a file, talking out over the network, talking into memory. Provides very good, strong run-loop integration. This is where all the frameworks above it inherit the run-loop integration from.

and it supports a variety of threading models. CFSocket provides support for arbitrary socket configurations. You can do a bunch of things with CFSocket that you cannot do with CFStream. In particular, you can work with UDP sockets as well as TCP, and you can set up server LISN sockets as well as client sockets.

On the other hand, you are so close to the OS that at this point the API is very thin to guarantee that there's no performance hit. You're going to be, if you're working with CFSocket, you're going to be configuring your socket using the BSD APIs. And you're going to need to go to higher level APIs or descend to sockets to do any of the more complex configuration you need to do.

It's not extensible, streams are not extensible, there's no way currently to create new kinds of streams. And again, because much of this is so very new, there's little documentation available. So when are you going to use Core Foundation? Use it when you're perfectly comfortable with BSD sockets and all you want is run-loop integration. You're perfectly content to manage the socket yourself, you just want to know when the bytes are arriving.

Use it if you need some type that's going to abstract away the source or the destination of the data. So you have some piece of parsing code that really shouldn't care where the bytes are coming from. Or you have some code that's writing out data that really shouldn't care where the bytes are going to. You can use a CFReader write stream to represent that. and use it anytime you need to use another API that's going to consume or produce a read or write stream.

So what's new since X.1? We've added CF read and write stream set property. This is the way you configure the stream and change the way it behaves. CFSocket has callbacks for write now. It used to be that you would get your callback only when data had arrived. Now you can also receive a callback telling you that there's room to write in the buffer. There are some more options controlling exactly when your CF socket callback is going to fire.

Better event dispatching from CF Stream. The event model's been cleaned up considerably. Asynchronous host name, domain name lookup. This is where everybody else is inheriting from to get this functionality. Socket streams are now errored out properly as the network changes underneath it. And we suppress SIG pipe on socket streams.

So last in the core services bucket is Open Transport. Vincent talked some about Open Transport already. You know that it's a compatibility API, back to Mac OS 8 and 9, and that it exists on X primarily for easy migration up from code bases that were designed for 8 and 9.

However, on Mac OS X it's going through an emulation layer. And as such, there's a hit in a lot of threads and context switches. There's no access in OT to the IPv6 or the IPSec APIs. And at this point, we're recommending that no new Mac OS X networking code be written to OT. Use BSD sockets instead, or use the higher level APIs when possible.

All right, so that's it for the APIs. I want to just take a moment to go over where we stand with IPv6 in these different APIs. At the bottom, CF Socket is IP agnostic. You're going to provide CF Socket with a SOC adder. That can be an IPv6 adder, it can be an IPv4 adder, but it's still up to you to choose what flavor you want.

On the other hand, all the upper pieces, CF Stream, CF Network, NSURL Handle, URL Access, they're all working with domain names or with URLs. So we will end up doing the IPv6 work for you when you write to those APIs. I'm not going to tell you all the work is done there, but a lot of it is. And on the CD you have, you'll see a lot of the IPv6 connectivity in place already.

And then I just want to highlight one thing. Some of you have noticed that CFURL and NSURL have not yet adopted the IPv6 addressing string, the one that looks like this. That's not in the CD you got, but it is planned for Jaguar. And that's it, and I'm going to ask Vincent to come back up to close out the session.

Okay, so I'm just going to wrap up here. So what's next? Certainly it's for you to take advantage of all those APIs, certainly move away from Open Transport and learn the new APIs in Mac OS X. As always, we cannot make any product announcements or tell what we are going to deliver when, and we don't know, but that's kind of the list of things we're going to work on. So, a lot more integration of IPv6. For example, IPv6 in Jaguar, that's the first foundation we have, is just the layout of the protocols.

We're going to bring up more IPv6 features up to the stacks and many applications, but a lot more things that we may end up working on. And also, provide a brief roadmap. So, yesterday there was already the Darwin roadmap that shows, for example, what's the core networking, where it fits in the story.

So, 803 is this session. At the same time, there was, in another room, 6th and 3rd, there was talk about Cocoa, what's new, and a description of NSURL, handle, and the services. Just after this session, a session about the new web services framework for SOAP support and XML.

Introduction to CF Network this afternoon. Tomorrow morning, so if you write NKs, I encourage you to go to session 108. 808 is for CF Run on Loop and CF Stream. Thursday morning, that's the Advanced Mac OS X Networking session, where we're going to go through the new protocols and talk a little bit more about NKs and performance. Thursday afternoon, section 811, Zero Configuration Networking, including the CF Net Services API. Feedback Forum. So there are three.

On Friday at 2:00 PM, the Core OS X, it's really a general Mac OS X networking feedback. I mean, everything that is not covered in other feedback forum, you can come and give us your feedback there. And for the Cocoa APIs, NSURL and NSURL Handle, the Cocoa Feedback Forum is the place to go.

And those are the primary contact should be Tom Weier, who's the evangelist for network and communications. But if you need to contact me, here is my address. So we got a lot more documentation. A lot more documentation is available. So most of it is on the CD or on the web. And there's also the new networking mailing list that certainly you know about.