I'd like to welcome you to session 110, overview of Mac OS X networking APIs. My name's Tom Weier. I'm a consulting engineer in our field engineering group, and I have the fortune of introducing this session. There's a lot of things in Mac OS X that have changed over the years. A lot of new features have come into the operating system, and there's a lot of material in this session. As you saw in the keynote, we have new VPN functionality, new enhanced support for IPv6 and a number of other key features. So with that, I'd like to welcome up Vincent Lubet, manager of CoreOS Networking.

Good morning. So this is what we're going to go through today. So we're going to start with a brief overview of the Mac OS X networking, a little bit the architecture, what's the new features, and then we're going to delve into networking, networking APIs. There are a lot of networking APIs, so it will be relatively high level, just more a list of features, And hopefully, you will have some idea which, depending on your needs, which API to use. And basically, we have system level APIs and then also framework APIs, framework level. And Becky will do the second part, talking about the frameworks.

So we have ongoing goals, and they haven't changed since last year and the year before, I think. So the ease of use, we'd like to have the networking be as transparent as possible. So one great example is Rendezvous and other zero-conf effort. Performance also is very important. We have the same kernel that runs on a laptop, runs also on an XR. So performance and scalability is an ongoing goal for us. Extensibility, that's a common feature from you, from a lot of developers. And also standards compliance. Whenever we can stick to standards, we would like to do it.

So, the core of the networking is in the kernel, that Darwin layer, and basically that where you have the Apple Talks stack that is not used very much these days, but also the TCP/IP stack. And all of that through the core services and a lot of framework serves the application's environment. Okay. So my question, the stack is based on FreeBSD. Last year, we updated it to FreeBSD 3.7, I remember, something like that. No, 4. 4.

uh... and uh... so with that you get those who to unix like uh... protocol stack, 3BSD. So you have a lot of code that runs on other Unix that are very easy to port on Mac OS X. The TCP stack includes IPsec and IPv6. We introduced that last year already, so we still have support for AppleTalk, a full remote access suite of protocol based on PPP. The stack comes with a firewall and also NAT, Daemon. The cool stuff we have added to Unix is this dynamic configuration based on the frameworks with plugin architecture so that as far as we can, we're trying to push the system so that the configuration reconfigure automatically. And of course, we have Rendezvous, and that was the major breakthrough of last year.

So what's new in Painter? So more rendezvous-aware applications and services. So if you went to the Stuart session yesterday, you saw a lot more applications in Painter. You have iChat, iTunes, Safari, and more. We have also more IPv6-aware applications and services. One of the... So, for example, AFP, the one that you have in Painter, runs over IPv6. We are introducing also an IPsec-based VPN, 802.1X for link layer authentication, even better support for mobility and WebKit and all the Safari framework, and a lot more. So we're going to go through a little bit. So 802.1X is a link layer authentication. That means that that's a user authentication that allows that runs before really your link can go up. So it's really the-- come to be the prevalent way to secure wireless LANs. But also, it's also used in some switch environments for Ethernet. And in Pantera, we support a wide range of authentication methods. A22.1X is still a young protocol, so it's not clear which of those authentication protocols will be the prevalent. But we support all that list. that are the ones that are used by Cisco, Microsoft, and other vendors.

the apple vpn so it's a client and server and so we use a ipsec for the to provide the really the the secure secure layers um and we use also l2tp for interoperability l2tp is in fact it's uh it's running ppp over over udp and that provides interoperability with windows cisco and things like that that's really the the really the only standard vpn protocol out there And so we prefer AES for the encryption for those who know the cryptographic algorithm. It's more efficient, but we still support triple DES and other algorithms. And we have also added support for SecureID. It's a very popular way to provide user authentication. So I think that's a lot of -- it's deployed in the company. But we have also other supporters of MS-CHAP, also V2 and things like that.

So we have a different level of networking API. So that's just a short list. And we're going to go through that in the rest of the session. So first, I'm going to start by the bottom, if you like, that the system-level APIs. It's more or less what you find in Darwin, the open source implementation. So I'll start with the BSD sockets. So that's the fundamental APIs for networking. Everything else is mostly-- every other networking API is based on BSD socket. And so that's the one you use to get the most out of the system. That's the raw access to the kernel is done via socket.

So when to use sockets? For performance. So if you're in server environment, if you're writing a server application, with you have the insurance to have the most of the system. You have very fine control of what's happening. You have access to all the low-level controls, complete IPsecs, PF and DRV, and things like that. I'm going to talk about that. And also, BSD, so it brings you Unix compatibility and portability. So on Windows, they have WinSug, so it's relatively close. So often, it's a good way to ensure portability.

With the BSD socket comes the resolver library. So it provides name and address resolution. And in fact, there are two level of APIs. Some of them works with other system, not only the DNS. And it goes on and on. So with the socket's API, in Panther, it's been updated by nine, so the latest and greatest. And we have also full IPv6 support. That means that you can resolve an IPv6 address using the resolver functions. But also, you can resolve over v4 and v6. So it's the full set.

So IPv6, so we implement the standard APIs. It's part of Socket. It's an extension of the basic Socket API. Something that we turned off that was a nice-- functionality was mapped address that we're able to use when you were a server, you were, for example, people were using just to just one socket, the V6 socket.

And because V6 addresses are larger than V4 addresses, the with this option of mapped address, you could have also received also V4 connection on that socket. Um, for security reasons, uh, we disabled that by default. It's off, it's not disabled, but it's off by default. because there are some security reasons, implications. There are some implementations out there that, in fact, use tunnel really it's a way to tunnel v4 in v6 and sometimes it bypass firewalls and people are not very happy with that so in panther it's off by default there's still a socket option if you know what you're doing you can use it Mac OS X doesn't tunnel v4 in v6 but there are other implementations that do and so we have the dns over ipv6 in panther and so the the idea here is for application. Last year we had a full office session on IPv6 and how to code for address family independence. It's really easy to write programs that support both v4 and v6. That's why those APIs are standard. And we encourage you to do that. And so one of the great stuff about v6 is rendezvous works over IPv6. So it's a very easy way to find out services and test stuff on the network. You don't need to have... With IPv6, you don't need to have an infrastructure. v6 has automatically configured addresses, link local addresses on all the interfaces, so you can find services. It works perfectly with multi-armed system. them.

IPsec provides IP level security from within the kernel, the bottom of the stack. So we support a bunch of, there are a number of APIs to set those security policy and association database. Those are the kind of the filters that tells you what traffic to encrypt using IPsec. There's the PFK socket, IPsec set policy, it's a library function, and also you can have a per-socket control.

So we saw a few, already a few in Jaguar, a few application, third-party application using IPsec. So the new thing is that in Panther, we're also using IPsec for our VPN. So there is something that is, something to remember is that This is a single shared system-wide resource. And it's managed by the internet key exchange, the one, the protocol that exchange the keys managed by a single daemon called Raccoon. And so it's a single resource, so please, if you use IPsec, make sure you don't override preferences or settings from other applications. And we've added also NAT traversal in Panther. That's something that really in these days with NAT is prevalent and so we support that. That's the, it's not yet a standard, it's still a ITF draft, but that's what we, that's the best way to do it.

That's the way to traverse NAT with IPsec. That's the most likely to be interoperable, although it's not yet a standard. So we have an IP firewall that works also with IPv6 in Panther. And again, just like with IPsec and the Raccoon, it's a single system-wide resource. So with IPsec, you can define filters and actions to do on certain type of packets. but just remember it's a single web resource. And just like, so for example, you've certainly noticed that the built-in firewall will not turn itself on if it detects there are other rules on the system. So be nice and don't overwrite other people's rules. Or you can ask the user if he wants to flush. the rules. And there's two ways to control the firewall. There's a command line, a PFW, and also just straight socket options.

PFND-RV sockets. So PFND-RV sockets are sockets that allows to write user space protocols. That means that they really-- that's a facility we have in the kernel using these type of sockets to send the raw Ethernet frames up to user space. And we use that with A22.1X. It's an Ethernet protocol, in fact.

And so that's a great way to stay out of the kernel. And it's also used to implement other protocol stacks that are maybe specific for an application like DECNATE or IPX and others. There are other solutions that also can be used instead of PF and DRV sockets also to implement user space protocol.

Those are listed to the diverged sockets that work with the firewall and the NBPF, the Berkeley packet filter. We, given the state of the internal API for network kernel extensions, we really like, if possible, that you implement your protocol in user space, if possible, so that you can be sure that there's no problem of compatibility in the future.

So let's talk about the problem, I mean, the network kernel extension. So today, the NKEs are tied to the kernel implementation. So we cannot really say that we have an API. It's really, we provide hooks where extensions can really get to the internal mechanism. That's fragile, it's going to break, It broke in the past, and every time we implement a fix, for example, or want to improve performance, we have to think about is this going to break a third-party kernel extension. So if you came to the session about the kernel yesterday morning, you're certainly aware that we are working on a new API that will isolate the extensions from the internal implementation of the kernel. And it's not yet ready. It's underway. And we certainly like your participation and feedback, because we're going to do certainly some drastic change in there.

System configuration, so that's the foundation for our mobility solution. And it's based on a daemon and a couple of set of APIs. So we have a set of APIs to manage preferences. That's the one that I use, for example, by the network preference panel. So those are system-wide local preference for this host. And we have also an API to get the status about the state of some parameters. So that's the basis for the dynamic behavior. So there are notifications when there's a change in the state of some data or key or the preference. And they are used today also by a lot of third party applications, for example ISPs, ones who provide their own dialers, they use that. And also application, that's how they can dynamically react to a networking change using the status. And it's used in, for example, by Mail and Safari, and also it's the basis for the dial-on-demand application.

So what applications they use usually-- so the preference API I just talked about are more used to manage the configuration. But we have an API called the AC Network Catchability API that allows to check whether a set of maybe name addresses or pair of addresses, name, impanter, are reachable.

Reachability, it's not a guarantee that, for example, the distant host is-- you can really connect to a distant host. But what it says is that from the standpoint of the system locally on the machine, there's an IP address, a router is there, maybe there's also a DNS server configured. And so this API unifies a set of information. It gives you a synthetic view of it.

So when to use SC network catchability? So just to tell you if you have a chance to connect to the server. Maybe the server is-- so it will not tell you if there's a firewall, if you have a problem with NAT or things like that, things outside of the control of the system. But at least it can tell you the system is properly configured. So when they will change in connectivity, that you have the chance to clean up and maybe to provide some feedback to the user. For example, CFSocketStream use that on every socket. Becky's going to talk about the CFSocket API a little bit later, but our own frameworks use this API as its base API.

So something new in Pinter that works, in fact, with the reachability API is the SC network connection API. This is the API that enables dial-on demand from within the application. And it's similar to the OTPP remote access API we had on Mac OS 7 and 8.9. So the idea-- so today, what we have is really something that we call at Apple dial-on traffic. So if you enable that preference in PPP, the PPP, every time it sees that some data is to be sent, it will dial the modem. And that's the cause of a lot of complaints because it's the system dials at the most opportune time. So what we want to do is instead with having this new API to be in control. And they can decide or maybe prompt the user, so I need to get on the network, you know, do you want me, and this requires to dial, do you want me to dial? Yes, no. And so, for example, it's great for mail clients and also that's the same API that is used not only for application but also for dialers with different set of parameters. Internet Connect, our own Internet Connect inventor uses this API. So really, we would like you to adopt this API. So I put together this little sample code. It's just to show you how simple it is.

So for example, this is how to tell if you want to, for example, to access www.apple.com, what you would do, you would call scNetworkEachability create with name, so where you pass the server name, and then you specify a callback for this reference, you get back a reference, and you specify your callback. when there's an event that happens for the change in the reachability of www.apple.com, your callback will be called. And you just schedule it with your run loop. So it was great for applications above the BSD layer, let's say. And you just run the run loop. And then this is the reachability callback when you get an event. Basically, the Really, the major event is the flag that tells you. It's a set of flags you get, but the one that's really interesting here is whether it's reachable or not. And there are sub-flags, and one tells you if a connection is required. And now in Panther, if the server-- so if you need to start a connection, you just have to use the connection API.

And the start connection API, usually when you are not a dialer, you just want to use the default, certainly the most current connection the user did with Internet Connect. So you just tell the user, just copy the current preference. And you tell the system to create a reference again, because that's kind of the hook, the endpoint that you will use. And again, it's an event-based mechanism. So you schedule in the run loop.

to be ready to receive event, and then you call the start. And you release the stuff you don't need. And again, when there's an event on the connections, you're being called back. And here, the main event you have, it's very similar to the Remote Access API, and it just says if it's disconnected, connecting, connected, disconnecting, and in case of error, you get invalid. And when you're done, you close the connection. So one point in this API, the connection has a ref counted. That means that the idea is that when your application doesn't need to use the system, certainly you would like the modem to disconnect. So you just release the connection. If there was another application using the connection, it will still hold the reference on the connection. So it's on the last reference that the connection will be turned on.

And with that, I'd like to-- oh, no, one more thing. Last but not least, that was my-- it's the DNS service discovery API. So those are the rendezvous APIs. There was a session yesterday about-- Oh, something is wrong here. The session is not kernel programming, but that's the Rendezvous API. It's 102. So the NNServiceDiscover APIs are the foundation for Rendezvous. And you have sets of APIs to register NNM services, also an API to browse for services. Rendezvous is really something for end users. So that's the idea, is that the end user will pick and choose It's not so great for background connections, because really the idea is that the user choose browse something and just remember the name. And then when it's time to connect to that service, you have an API to resolve and the service into an address on the part you can use in subsequent, for example, socket score. We have three API flavors, depending what level your application, what type of API your application is using. We have the DNS service discovery API, it's a system level API that's the foundation for the other ones. In CF network, there's the CF net services, so if you have a run loop, it would be the natural way to use. And in Cocoa, there's NSNet services that works for Cocoa. And now with that, I'd like to introduce Bikki Woolrich, who's going to talk about frameworks.

Thanks, Vincent. So Vincent has taken you through the basic feature set of what's available direct from the Darwin system, what's available at the Berkeley Sockets layer. And what I'm going to do now is talk about what we've built on top of that into the framework layers above it.

So I was thinking about how to prepare this talk, and it seemed with the introduction of Safari 1.0, the best way to look at those APIs was to look at what Safari has built upon. And that's how we're going to start out. After that, I'm going to talk briefly about some of the other networking technologies on the system. And finally, I'm going to give you some tips and hints on how you can transition off some of the older Mac OS 9-based APIs.

So let's talk for a moment about the Safari technologies. When we started writing Safari, we, of course, built on the technologies we already had built on top of the existing APIs. But we also discovered a lot of places where those APIs were lacking. And so we developed many new APIs at the same time. And now we've made those APIs available to you. That's part of the Safari SDK. As you've already heard from the keynote, those APIs are available on any Panther system And on any Jaguar system provided, Safari 1.0 has been installed. And I do not have enough time to go into those APIs in great detail. So I'm going to point you to some other sessions as we go, including session 403, which took place on Tuesday. But when you get the DVDs, you can take a look at it. Don Melton gave a pretty good overview of all of those APIs in greater detail than I'm going to have time for.

So what goes into Safari? It's on Mac OS X, so you know the core of the networking has to be BSD sockets. But there's a lot of stuff between sockets and what ultimately is the Safari application. And the first layer in that stack is core foundation. A core foundation provides a couple different important things. It's not really a networking library per se, but it provides a couple basic abstractions for us. First and foremost, the run loop. The run loop is how all of the different interesting events inside an application get funneled into a single callback mechanism on our system. So if you look at NS run loop or Carbon events, that's how user events ultimately are transmitted. And it provides our basic asynchrony mechanism.

CFURLs, basic abstraction for URL, pure data type. And those two kind of come together with CF Socket, which provides a way to take a socket, a file descriptor, and connect it into the run loop. So rather than having to manage a select loop yourself or a file descriptor set yourself, you can use CF Socket to get that input managed in the same way that all of the other user events are managed. CF Socket can handle literally any socket. It works with most file descriptors too, but we only promise it with every true socket. That includes UDP sockets, as well as server-side accept sockets.

Built on top of CF socket is CF stream. CF stream is just a basic stream abstraction. You get a stream, you open it, you read it, eventually you close it. If you're unlucky, it errored out somewhere along the way. It's hooked into the run loop so that it can signal the client, your application, whenever bytes are available or something interesting has happened. However, because it's a stream-based API, it only really works with TCP sockets. It doesn't make much sense to talk about a stream for an except socket or a UDP socket.

So that's Core Foundation. If you take a step up from Core Foundation, we get to CF Network. CF network is the library on our system that provides the basic protocol implementations. This is where our HTTP stack lives. This is where the FTP stack lives. CF network itself does not actually provide the SSL implementation, but it provides all the hooks into SSL and TLS. So if you've got a socket stream, you want to make it secure, CF network provides the hooks to run SSL over the socket stream. And finally, rendezvous. This is Vincent mentioned that there-- pardon me. Vincent mentioned CFNet Services, which is the API that CFNetwork provides for accessing Rendezvous.

The basic goal besides CF network is to provide you with those protocol implementations and hook them into the run loop. However, our goal with CF Network was not to be the most convenient API. There are higher level APIs that provide that convenience. At this level, we're trying to give you full control. What that means is that all the protocol details are fully exposed. So there's a lot of power implied with that. There's nothing you can do with HTTP, for instance, that you cannot do through CF Network. But on the other hand, you better know HTTP or the CF Network APIs aren't gonna make a lot of sense to you.

Other ways we give you full control, at the CF network layer, you have complete control over precisely when the reads and writes are done. Again, this can be a pain if you're not actually interested in the details. But if you need that control, this is the layer to get it at. Likewise, the threading policy. We do not dictate a threading policy for you at this level. At higher levels, we'll see some APIs that will actually take care of spawning background threads for you, for instance, but not at this level.

Couple things new in CF Network with Panther. We've added DNS host resolution. This is asynchronous host resolution. So you can start a request to look up the address of yahoo.com or anything. And you'll get a call back later on telling you when that address is available. We've also added FTP support inside CF Network. And for more information about CF Network, come to the session 112 tomorrow afternoon at 5:00 PM.

Yeah, okay, last talk of the conference, but what do you want? Okay, so what do we have above CF network? Well, I mentioned some convenience APIs that do not expose as many of the details to you. That's what these new foundation URL APIs are all about. It's a new set of APIs in Panther. It's a full-featured set of URL loading APIs. And here, the point is for the API to be as convenient and abstract as possible. So the policy is to make most of the choices for you.

Does that mean that you can't modify those choices if you want an unusual setup? No, of course you can. But the policy is going to be to start out by making the most common decision for you, and then you kind of have to undo those decisions. Whereas at CF Network, the policy was that you have to apply each and every policy decision yourself.

The API is asynchronous, building on the run loop, of course. It's basically callback-based. If you're familiar with the Cocoa API paradigms, we do it via delegates. And at this level, we add extensibility via subclassing. So if you've got to have the Gopher scheme implementation, we don't provide it for you, but there's a class you can subclass to implement it yourself and get it plugged into the entire URL loading system.

And again, it's part of the foundation library. So it's built right into the core and available to you at that layer. And for more information about these, go to session 418 this afternoon, where we'll be talking about these APIs in much greater depth than I'll have time to go into here.

But just to give you a flavor for the API, here are the basic abstractions. You start out by creating an NSURL request. This encapsulates everything, all the information needed to configure a URL download. So the URL itself, if you have a custom user agent and you're doing HTTP, you can set it there. Proxy settings, all of that goes into the request. Once you've got a request, you build a connection from the request. The connection represents the ongoing download. The connection has a delegate. That's the NSURL connection delegate. And you use that to get information about how the download is proceeding. Finally, what you're going to get back from the delegate is the data, of course, but also an NSURL response object that encapsulates everything that's not actually part of the data. So that includes things like the MIME type, like the HTTP headers that came back.

And then I just want to highlight briefly the other features that are built into the Foundation URL APIs. I've listed each and every class here, but I'm just going to talk about the major bullet points to explain the features. Caching. Caching happens automatically with this API. There's both an on disk and in memory cache available and used. Cookie storage and management, all handled automatically, all shared for a given user across all applications, unless there are preferences to change whether your particular cookie is stored. But by default, they'll be stored so that all applications can access them.

Authentication and credential management. We've got a bunch of classes built in so that you can know exactly who's asking for a password, whether there's a password already available on the system for your use, and give you everything you need so you can prompt the user and get that password if necessary. And finally, the extensibility I mentioned. So there's a class available, NSURL protocol, that you can subclass if you want to add your own particular scheme that we do not provide. Thank you. So that takes us all the way through the URL loading APIs. The last piece, of course, is WebKit.

WebKit is new in Panther. It's a brand-new public framework, and this is the layer that actually does all the rendering and navigation. So it's what actually draws to the screen and interprets the user events as the user clicks or moves throughout the document. It's a fully pluggable architecture so that you can support rendering new kinds of document types. We, of course, handle HTML text and the image types out of the box, but, in fact, we provide sample code that shows how you would extend WebKit to be able to display PDFs.

It's an Objective-C API fully integrated with the AppKit classes. So, in fact, the central class WebView is a subclass of NSView. The SDK also provides a bunch of example code that shows how you can take that WebView and use it from a pure C or C++ API and integrate it fully with Carbon HI views and Carbon events. And for more information about that, there's a session tomorrow sometime. I'm not sure when. But session 420, they're going to go into the WebKit APIs in a much greater detail.

And that's the full stack. That's what goes into the networking portion of Safari. Sorry. So now I'm going to touch briefly on these three other networking APIs-- Web Services, NS Stream, and Launch Services. Web Services is a framework we introduced in Jaguar. It provides APIs for issuing an XML RPC or a SOAP request. In Jaguar, the API was very focused on the client. So if you were a client and wanted to issue such a request and receive a response from the server, we had APIs for that. But starting in Panther, we've added support for server-side operations. So if you're on the other side of the equation and need to interpret an incoming request, We can now help you do that.

NSStream is new in Foundation in Panther. It's actually two different classes, NSInputStream and NSOutputStream. They're toll-free bridge to CFReadStream and CFWriteStream, which have existed for a while. And the reason why that's important is because NSInput and OutputStream is designed for subclassing. So we've received a lot of requests saying, hey, I don't want to talk to a socket, or I need to interpose a data filter between the actual bytes coming in from the network before you start processing it. How do I do that? Well, you can't really do that with a C API. But with NSStream, we now have a way to do that. Just subclass NSInputStream or OutputStream. Insert the filter or extra data processing you need. And then thanks to toll-free bridging, you can take that object and pass it directly into the APIs that consume read and write streams. And this was touched on briefly at session 410 yesterday, the Cocoa Update where they talked about everything that was new in Foundation and AppKit.

And finally, launch services. Well, most of you are familiar with launch services as the API you use if you have a file and you want to open it exactly the same way Finder does. So you're probably thinking, well, what the heck? That's not a networking API. Well, the fact is that launch services is good at finding helper applications of all kinds, not just for files. So the launch services APIs can be used to open an arbitrary URL as well, or to find out what application would handle a particular MIME type. In fact, Internet Config, which is an older API that you may be more familiar with, calls through to launch services to handle these kinds of services.

And so I mention that, of course, to get to this next point. We have some older APIs, some legacy APIs, that we're kind of interested in getting you to transition off of to some of the newer ones. And Internet Config is one of those. Are we taking these APIs away from you? No, of course not. They're still on the system. They'll continue to work the way they always have worked. But we're no longer extending these APIs the way we're extending some of the newer APIs that I've just talked about. These are the four I'm going to address in particular, URL Access Manager, NSURL Handle, Internet Config, and OT. KATHRYN So URL access manager. Clients tend to use it in one of two fashions.

Either they have a one-off, well-controlled transaction, or they're doing some kind of longer-lived transaction. If you're in that one-off case where you know exactly the details of what you want to do, you know you're performing an HTTP post to a server you control, you set up as part of your business, CF Network is probably the best way for you to go with something like that. gives you full control of the details. At that kind of level, you know, the extra abstraction almost gets in your way because you know exactly what you're trying to do. On the other hand, if you want an API that's simpler, kind of one-shot, fire and forget, NSURL connection is the way to go. And then if you're using URL access in the other way, where you're performing some very long-lived, complex transaction where you don't want to handle the details, NSURL upload and NSURL download are the two new glasses in the URL loading APIs that are available for that kind of functionality.

NSURL handle in Foundation, the new URL loading APIs really supersede NSURL handle. So use NSURL connection instead. We've added a compatibility shim that connects the two engines. So if you have some investment in a URL handle subclass, that'll continue to work as it always has. And not only that, anyone using the new API, the URL connection API, will automatically and talk to that subclass as well. Works in the other direction, so if you have a URL handle based API, you'll actually see and call through to the new Foundation loading engine as well.

Internet config. So if you're looking for a helper app, you're just trying to figure out who should I use to open this URL, or who should I use to handle this MIME type, call launch services directly instead. The other thing that we see in internet config is access to these system preferences, things like the proxy setting. To get those, talk directly to system configuration instead.

Finally, OpenTransport. We've been telling you for at least three years now that OpenTransport is not your high performance native networking solution on this system. BSD Sockets is. So as you're writing new code, we encourage you to use Sockets directly. Also, when you're choosing your networking code, maybe Sockets is not the right layer for you. And we encourage you to think about whether one of the higher level APIs that's going to provide connection to the run loop for you will maybe serve your needs better.

So that's all the material I had for today. I want to continue to repeat this roadmap. I've talked about most of these already. I did not talk about 4.11 internet technologies, which talked a lot about the Safari technologies and the web in kind of a general sense. That took place yesterday. Vincent mentioned the rendezvous talk also yesterday. Kernel extensions, CF Network In-Depth is tomorrow. And then the feedback forum. So if you don't like all of what I just said, come tomorrow morning at 10:30.

Some contact information there. And with that, I'd like to ask Tom Weier back up on the stage for the Q&A. Oh, sorry. Should mention the documentation. There's a load of documentation for the different networking available. Go to ADC home documentation networking, and pretty much every API I've talked about here, everything that Vincent talked about, has documentation under that heading.