This is a fantastic turnout. I think this really shows how much pent-up demand there is for networking that's easier to use. It's really exciting to see so many people here. So, we've got a lot of material to cover right now and I'm going to try to get through it quickly.

I want to cover why we're doing this, why we're here. Once I've identified the problem we're trying to solve, I want to talk about what we're going to do about it, and then I want to talk about how we're going to achieve those goals. And if I manage to convince you all how great this is, then you'll be interested in the APIs at the end to tell you how to make use of this.

So we'll start off with the why. Over the last couple of decades, the world has seen a huge list of competing wide area networking protocols. And the good news is that all of those have gone away and died. TCP/IP has won. The one that is kind of still hanging on there is AppleTalk, and it's hanging on because of ease of use. If you're a vendor that makes a printer, a network printer, you still have to put an AppleTalk stack in it because your Mac customers won't buy it unless they can just browse in the chooser and find it and print on it.

Now, we want to get rid of AppleTalk. We don't want to get rid of AppleTalk because it's bad. It was a great protocol 15 years ago, but we want to get rid of it because it's a big burden to Apple to have to support two protocol stacks. It's a big burden to the printer vendors to have to support two protocol stacks. If you're writing a network game, it's a big burden to have to do AppleTalk and IP. IP is one. Let's do everything with one protocol stack.

So let's consider the local area. Similar kind of proliferation of different kind of interfaces and connectors. And the good news is, they're all gone as well. What do we have today? We have even more different local connectors. 20 years ago--I'm talking about 20 years ago, before the Macintosh even existed--you went to your computer store and you bought a dot matrix printer and it had a parallel port. And every personal computer had a parallel port. You take it home, you plug it in, it works. You get this nice mono-spaced 80 column text out of it.

I'm not commenting on the quality of the printing, but there was only one way to plug it in. Now you get printers that connect by USB, by firewire, by ethernet. A lot of high-end printers have the little IRDA infrared window on them. You can print over wireless. What is the networking community doing about this problem? We're adding more ways to print.

Now, Bluetooth is a great technology. The hardware guys came up with a very small, low-power chip that communicates over short distances. It's low cost, it's low power, it's small, it's great. But the problem then is that they invented an entire scheme of addressing, naming, service discovery, browsing, printing protocols, file exchange to go with that cool new piece of hardware.

So we have Bluetooth file exchange. We have FireWire file exchange. Most of you have probably never even used it, but it exists. There's a tool for doing file transfer over FireWire. You may remember the IR file exchange. A hundred years from now, our grandchildren are going to be here at the developer conference being introduced to the new hyperspace communication with its hyperspace file transfer tool. We need to stop reinventing the world over and over again. You know the cliche about standing on the shoulders of giants. Well, in the networking world, it's sad to say that the networking world achieves what it does by standing on the toes of giants.

We need to stop reinventing the wheel. So what are we going to do about this? In the wide area, it's clear what we did. We picked a single protocol and we used that for everything. Can we do the same thing for local area communications? If we could pick just one, that would be a big improvement.

We'd have one protocol for wide area and one for local. Big improvement. But maybe we can do better than that. Maybe we can pick one protocol for everything. IP is clearly the one protocol candidate here, so can we use that for local communications as well? So I'm going to talk about how.

before we get into the timetable. When I talk about using IP for local communications in the same environment you currently use a USB cable today, a lot of you are probably thinking, he's crazy. Nobody wants to be typing in IP addresses and subnet masks and default gateways and all that nonsense just to plug in a printer.

And you're absolutely right, nobody wants to do that. And it's because of that perception of IP that easier alternatives keep being invented. But the question is, can we make IP as easy to use as USB? Several people have been asking questions about how Apple thinks it's going to impose this standard on the world. And it's not that way around at all.

This started quite some time ago. In fact, I've been working on this since before I came to Apple. And when Apple came to me and said, "Why don't you come and work for us?" Their pitch was, "Can you think of any company that is going to give you as much encouragement for your ease of use ideas as Apple?" And that was pretty compelling. So that's why I came to Apple to carry on this work.

For me, the roots of this starts back in 1977 when I was still a PhD student, and we were discussing how hard IP was to use on a Macintosh mailing list called NetThinkers, and we came up with this proposal to just take AppleTalk name-binding protocol and run it over IP, and I'll talk a little bit more about that later.

The next year in 1998 at an IETF meeting, I was talking to a guy from Microsoft in a bar about how we ought to make networking easier, and he had a proposal, and I thought it was cool, and we agreed on it. And later that summer, we shipped IPv4 link local addressing in Windows 98 and in Mac OS 8.5.

Later that same year, the discussions about browsing and MVP kind of evolved into multicast DNS, which I will explain. And the IETF community realized that maybe there was enough interest in this to form a working group. So we had a Birds of a Feather session in March '99. We had a second BOF session in July, and at the end of '99, the Zero Configuration Working Group was officially formed.

I don't actually remember volunteering to be chairman of that working group, but somehow it happened, and so... Almost three years later, Apple has now made a public commitment to this and announced it under the name Rendezvous. Lots of people have been asking what is the relationship. Rendezvous is Apple's name for ZeroConf, just like Airport is Apple's name for 802.11.

So the job of the working group, before we even designed protocols, was to get the IETF community to agree on what the problem was. And if you've ever tried to get a thousand people to agree on something, you'll know that that can be a slow process. But it's an important process because one person standing up and saying, "I think this is the answer," doesn't necessarily mean very much. But if you can get people to agree that that's the right answer, then the industry can make progress.

And the working group agreed on three requirements: addressing, naming, and browsing. And those are the three things I'm going to talk about in more detail. We have a draft, which is the IETF mechanism for producing documents that will become RFCs. That draft is on version 10, which kind of gives you an idea of how contentious this has been. And that draft lays out the reasoning behind these three requirements. Information about the Zero Configuration Working Group can be found at the zeroconf.org website.

So the first leg of ZeroConf is linked local addressing. You can't do much IP networking if you don't have an address. So that's the first problem. Now, everything I want to talk about today is very, very simple. This is not fancy and complicated and big PowerPoint slides with architecture diagrams with boxes and arrows to impress my boss and get a pay rise. What we want to do is do the simplest thing to get the job done and make a solution.

And this is not so much for Apple's benefit as it is for everybody else's. Because when you've got a gigahertz processor and a gigabyte of RAM, most software problems are fairly easy. But if you're making a $50 inkjet printer, you don't have that luxury of inefficient bloated software. So there's no benefit to Apple if this only works on Macs. We need this to be running in all the little peripheral devices as well.

So what's the simplest possible solution we could think of? Taking our lead from AppleTalk, which did this very well, pick a random address, send an ARP request. If nobody answers, I guess no one's using that address. You can have it. So that was simple. If you go home from this session today thinking that wasn't very impressive, everything he said was really obvious. Then you got the point of the session, right? This is supposed to be simple.

So IANA, the Internet Assigned Numbers Authority, has reserved a range of 65,000 IP addresses for this specific link local use. And that's the 169.254 address range. You may have seen this already because this has been shipping for a while, and a lot of people have the perception that when they see 169.254 in the control panel, that means networking is broken.

And it's understandable why you would think that because Link Local Addressing is like one leg of a three-legged stool, and when you only see the one leg, it doesn't look like a very good stool. So I'm here today to show you the other two legs, and hopefully the whole picture will make sense.

I also want to say that IPv6 already has linked local addressing. This is not competing with IPv6, but this is a pragmatic realization that many of the vendors making hardware devices today putting IPv4 in are not ready to move to IPv6. So this is an interim solution. We hope two years from now we'll all be running IPv6. But in the meantime, we have something that works for v4 as well.

So the second layer of ZeroConf is naming. There's not much point having a random IP address if no one else knows what it is. I mean, sure, you can read it out to the person next to you and they can type it in and that works, but it's not the experience we want.

The conventional Internet usage model is you type in a host name. You type in the web browser, you type FTP host name, Telnet host name, Ping host name, and there's a system called DNS that looks up the address that goes with that name. So keeping with the spirit of not inventing anything new if we don't have to, Can we do something very, very similar to DNS? And what we're proposing doing there is just like with the addressing that we carved off a chunk of addresses that are designated special use local addresses, We're talking about carving off a subtree of the DNS namespace. So any name that ends in local.arpa is a link local name, only relevant on the local link. You resolve it by sending a query by multicast, not by sending a query to your normal conventional DNS server.

The packet format is exactly the same as DNS. The records in the packet are exactly the same. The only difference is you send it to the link local DNS multicast address. And every machine on the network runs a little responder just like the AppleTalk MVP responder. And when you see a request that's asking for your name, you send an answer.

Right now, we're using local.arpa because the IETF kind of logically owns the arpa domain, and we're more free to play underneath that subdomain. Ideally, we would like it to be named ending in .local, and by the time this standard is finished, we hope it will be .local. But for the Jaguar seed you've got right now, it's local.arpa. There's a website specifically about multicast DNS as well, and there's also an internet draft describing how that works.

So multicast DNS has a client side and a responder side. The multicast DNS responder is on your Jaguar preview CDs, and the client is also on your Jaguar CDs. So if you type hostname.local.arpa into your web browser, it will do a multicast and connect. I'm going to show you that right now.

So here I've got a product. Many of you probably have things like this at home. This is a Linksys firewall home router thing. Very nice product, four port Ethernet hub, no screen, no keyboard. How do you configure this thing? Well, 20 years ago, devices like this would have a serial port and you'd plug a VT100 terminal into them.

In the 1990s, the web browser kind of became the VT100 terminal of the '90s. It was the universal interface you'd expect everybody to have, and that's great. But what do I type into my web browser? How do I know what IP address this has? The manual on page 38 tells you the address it comes configured from the factory, but somebody could change that, and how would you know? And maybe it uses DHCP, but if it does, you don't know what address it got, and there's little hole you can stick a pin in to reset it, but it's not quite clear what that does. It's a big hassle. So this is what we'd like.

I want to emphasize something here today. The only aspect of the demo here that's rigged are the products that Apple don't make. Everything that's running on Jaguar is absolutely real. And if the hardware vendors in this room want to put multicast responders in their products, they will work just like this on real Jaguar systems. So I want to connect to my Linksys router to configure it. I type Linksys.local.arpa. That tells my Mac to multicast it. I hit return. We're talking to the Linksys router.

Okay, back to the slides, please. So you hardware guys can do this today and ship it. The multicast DNS lookup capability even exists in OS 9, so you can ship a product that does this today and actually get some benefit from it. So what we've achieved here is we've kind of reached parity with conventional Unix command line user interface, which is to say, someone has to tell you what to type, and you have to type it and not make any mistakes. And if you get it wrong, it doesn't work, and you don't know why.

So -- It's a huge step forward than having to guess random IP addresses, but we still want to do more. And the great thing was we managed to convince the ITF Working Group to not just accept parity with the current state of conventional IP networking, but to raise the bar and do something that AppleTalk always did, and that's browsing the network. And the IETF Working Group has agreed that that will be listed as one of the fundamental requirements to qualify as Zero Configuration Networking.

We are not the first people to think this was a good idea. Over the last two decades, history is littered with the corpses of failed attempts to do browsing over IP. It seems like every permutation of the words "service discovery resource location" in every possible order have all been used up.

And the list goes on and on. And I apologize if somebody's favorite protocol is listed here as not being a success. But as far as I'm concerned, until I can go to the computer shop and buy a printer that does this stuff, then it's not real. I also apologize if anybody's favorite failure is not on this list, but we only have an hour, so I had to... So why did all these things fail? I think it was a couple of reasons.

They couldn't keep things simple. Appletalk NBP is very, very simple. And it's classic second system syndrome. When you come to repeat something, you keep throwing in all the features you wish you had first time. And they get so complicated that the only way to make these things work is with exhaustive testing.

But if you've got 450 companies, that's the 100,000 testing matrix. You can't do all that by exhaustive testing. You're going to have situations where a customer buys a product from company A and company B, and they need to work together, even though they've never been tested together before. And the only way you get that is through simplicity.

The other reason I think they failed is they made a couple of fundamental mistakes. They're very device-centric. Because if you make hardware, you think in terms of things you can kick, and you say, I want to find the devices on the network. Okay, it's a device. Now I need to talk to it and find out what it does. And then it becomes very complicated because this might be a device you've never heard of before, so now you need to invent this kind of description language to describe what it does, and things get very complicated very quickly.

The important thing that AppleTalk did, the real insight, is that people aren't interested in finding devices. They're interested in finding services. I want to print. Find me things that can print. I don't care what kind of thing they are, whether it's an all-in-one or laser or inkjet or whatever. I've got a client that speaks a particular printing protocol. Find me all the things that I can talk to.

The other mistake that these protocols made is they failed to understand that browsing and use are two different operations. When you look in the chooser for a printer you're browsing, you find its name. You do that once, typically. Every day after that, when you hit Command-P, you're taking that name and looking up its address. And that's the second step. And when I get further on, it will become evident why that's a significant difference.

The sad thing is, they could have learned this just by copying AppleTalk, but a lot of people working in the IP community, certainly back then, didn't think AppleTalk did anything interesting and didn't think it was worth learning what it did. And I think that's why they missed these fundamental requirements.

So we want browsing. Now the question is, the working group has already agreed that we need multicast DNS, we need naming when there isn't a DNS server, just like we need addressing when there isn't a DHCP server. None of this is opposed to DHCP or DNS. Those are both great protocols.

The focus of zero conf is that if you don't have a DHCP server, your computer should do something more than throw up an error message saying help, no DHCP server. Because, like this situation, that Linksys is my DHCP server. If I can't talk to it to configure it to turn on the DHCP server, then I don't have one.

So, I So these are complementary. They're not trying to change existing IP. They're trying to fill a big gap where existing IP does nothing. So we have multicast DNS. That code is going to be in the device. Rather than write a whole bunch of different code, maybe we could reuse that code.

I talked earlier about NBP over IP. And in the discussions at the IETF, somebody came up with a very good idea and said, "You know, trying to put AppleTalk on IP is like mixing oil and water. It'll never go. The IETF will hate it. They'll say it's an alien protocol." But maybe, just maybe, the DNS protocol is semantically rich enough to carry the exact same information that you would have put in an NBP packet using DNS format. And that seemed like a really interesting idea. And it took us a while to work out the answer to that question.

But suddenly we realized that we don't even need to change DNS. There are three useful facilities in DNS that are well known, but they've never been put together in quite this way before. The first one is that DNS can return multiple answers. If you have a multi-homed host, you look up its address, you don't get back one address, you get back a list. Everybody's familiar with that. Every DNS server does that.

The second feature of DNS is pointer records. A PTR record is what you normally see used for doing a reverse lookup, when you want to go from address to a name. But in fact, a PTR record is a generic pointer, a link from somewhere in the DNS name hierarchy to somewhere else. So that's a facility that we're going to use. And the third feature is something called SRV records, service records.

Normally when you look up a host name, you get the address. You look up www.apple.com, you get the address where that service is running. But not the port number. And that's why everything has to have well-known port numbers. Web servers always run on port 80 because the DNS doesn't tell you. The DNS tells you the address, but it misses that last bit of information.

SRV records fix that deficiency in DNS. SRV records are supported in bind 8, bind 9. They've been around for about five years. So that's not a new invention. Putting these three things together, we get something that nobody ever thought you could do with DNS before, and that's browsing.

So here's how I browse for printers on the network. And there's a very subtle point that I want to draw attention to here. If you want to design networking protocols that work, you have to have a behavioral model of protocols, which is, if it walks like a duck and it quacks like a duck, it's a duck.

It doesn't matter how that protocol is implemented. So if you're an AFP client, you want to talk to AFP servers. You don't care whether it's a Mac server or a Windows machine or a Unix machine running NetAtalk. If it talks the protocol properly, you're willing to talk to it.

And this query here is saying something very specific. It's saying I am looking for services that speak the LPR protocol over TCP on my local network. And _printer there is the official IANA protocol name for the LPR protocol. That doesn't mean generically all printers in a sense that human beings think of them. That means specifically things that implement the LPR protocol. That's the query because I've got an LPR client. I want to find things it can talk to.

And here are the answer, or answers that come back. Because all the devices on the network run their own responder, with multicast DNS you can get a collection of responses back. And here, the result for that PTR lookup, we have four names: sales.printer.tcp, marketing, engineering, and third floor copy room. Now you see we have uppercase, lowercase, spaces, in fact it's all UTF-8, kanji characters.

DNS supports all that. Conventional host names don't. Host names have to be letters, digits, and hyphens, no spaces, because you have to type them on the command line. But these are not host names, these are service names, so they're not bound by those normal restrictions for host names.

The first label of each of these names is the user-friendly name that you display on the screen. The user-friendly name isn't a separate attribute because any time that the real name of something and the name you display are not the same thing, then you get weird inconsistencies. So there's a hard one-to-one mapping here.

Its DNS name is what you display on the screen. And we have a graphical version of this. If this looks a bit reminiscent of the old chooser, that's not a coincidence. We have services, we have domains, which are equivalent to zones, and then we have the services that we found in that domain.

So a service name has three components which intentionally mirror the three components of an AppleTalk MVP name. That's the name of the service, the type of the service, and the zone or domain where it lives. in multicast DNS service discovery, the first label is the name, the second two labels are the protocol name.

That syntax with the underscores, underscore print dot underscore TCP, that's not our invention, that's borrowed from the SRV RFC. Because I'll--I've said this before and I'll repeat it. We're not trying to invent new stuff here. Anywhere something exists that we can use, we'll borrow that. And the rest of the name is the conventional domain, could be apple.com, stanford.edu, whatever.

And there's the example repeated. We've got the name, we've got the type, and we've got the domain. If the domain is local.arpa, that means multicast on the local network. But if the name is apple.com, it means send this query to the regular Apple name server just like any other query. And you can use standard Unix tools like NSLookup to do these queries. You don't have to change a single line of C.

This already works with the tools you have. So I want to stress this thing about service types. They're not human-readable strings. They're opaque identifiers that name protocols. And that list of protocol names is maintained by IANA. And there's a list of them on their website. And if you want one of your own for your own protocol, getting a name and a default well-known port assigned is really easy. Just fill in the form, answer a few questions, and you can get a port number and a protocol name of your own.

So one of the questions that have been asked an awful lot is, "We don't want all this AppleTalk stuff on IP. AppleTalk's really chatty and it's horrible, and now you're doing that to IP as well." And the answer is we're not. We have been very, very careful not to have some of those problems of AppleTalk. When AppleTalk was designed more than 15 years ago, what it did was appropriate, but we have better technology now.

So the demon that's running in the background on your Jaguar machine is aggressively caching all the information it sees. Replies are sent by multicast, so if one person is looking for printers, then other people get to see the responses and store those in the cache. So if they later look for printers, they don't have to ask the same question again.

With AppleTalk, if you're looking for printers, you send an MVP query saying, "I'm looking for printers," and you get 50 responses. And a second later, you say, "I'm looking for printers," and you get another 50 responses. It's very inefficient. With multicast DNS service discovery, the query includes a list of answers you already know. So you do a query, you get 50 answers. Then you issue another query with those 50 answers embedded in it, and all you get then is maybe the one or two that you missed. So that's much more efficient.

If you've got two machines on the network that have the same information, then when one sees the other answer, it will suppress its own reply. If you've got two people browsing for printers, when I see you ask for printers, I'll suppress my own question because there's no point in me asking the same question as you.

When I open a printer browser, or whatever, I keep talking about printers because printers is a concrete example of something that we all deal with day to day, but The real potential of ZeroConf is much, much broader than that, but I want to try to keep this grounded in reality for this talk.

I think a lot of you out there are already thinking of cool things you could do with this and cool new products you can make. And that's really what's exciting about this. It's not just about making current products easier to use. It's about enabling whole new kinds of products that you wouldn't have dreamed of making before because the support costs would have killed you. But now they've become viable, and that's what's exciting.

So when I open a browser looking for some service, I don't keep pounding on the network. I send a query, and I wait a second. I send another two seconds, four seconds. It backs off exponentially down to a kind of quiescent rate of about one query an hour. So very low load on the network.

So the question you might ask is if I'm only asking once an hour and somebody plugs a printer in, am I going to have to wait an hour before I see it? And the answer to that is whenever a new service starts up on the network, it announces its presence with the same kind of algorithm, one second, two, four, eight, backing off, so that it sends about ten packets spaced over about an hour and then it doesn't announce anymore. But that means that when a new service comes online, you get to find about it in a timely fashion without pounding on the network polling all the time.

So a lot of work has gone into improving the efficiency So I've talked about the browsing. I've talked about finding the name of the service you want to use. And remember I said, service discovery is a two-step process. There's browsing and then there's using. Now I'm going to talk about the using stage.

So we found a name: sales.printer.tcp.local.arpa. Well, what is that the name of? That is the name of a DNS service record that describes how you can reach the service. With DHCP, the address might change day to day. With dynamically allocated ports, it might not be in the same TCP port every day.

But DNS SRV records let you look that up on demand and get fresh information. So here's the query that I send, and here's the answer that I get. The sales printer today is on port 515 on IP address 16925412.34, and the Q name for that printer is LPT1.

I could actually move that printer to a different print server, which may be using a different LPR Q name, but by putting this information in the DNS, you can hit Command-P, and you're still printing on your default printer. You don't need a different LPR. You can just use the same LPR. need to be aware of the fact that the administrator has reorganized the network. So now we're going to do another demo. Typing stuff in to connect to this Linksys router was all very well, but it would be much nicer to browse for it.

So let's look for things on this network that speak HTTP. Oh, there we are. And I talked about UTF-8. Everybody says, "Oh, we're international." I just wanted to show that we really mean it. We have some Japanese text there. I think that says "Japanese" in kanji. I don't speak Japanese, but somebody can correct me if I'm wrong. So when I select that, we get its address. We get the port number. Click Connect. Now we didn't even need to know what to type. We just browse for it.

So I brought some other cool toys as well. This is a wonderful little camera made by Axis. This thing runs Linux. It's got a web server in it, an Ethernet port on the back. Cost about $400. Takes about four hours to set it up. But what if this had multicast DNS? I take my cable, I plug it in. Link Flight comes on. And give it a few seconds.

That was so cool, I bought another one. Let's give that a second, see if that shows up. Okay, back to the slides. So, browsing with DNS is a system-provided API in your Jaguar seed DNSserviceDiscovery.h is the name of the header file. I'm going to talk about the APIs, but you can find that on the disk. We have a little bit of sample code on the Apple developer site.

If you're making a hardware device and you want to put this in, there's a couple of ways you can do it. You can read the draft and implement it, and that's fine. This is an open standard. But if you want to save time, save development time and save debugging time, We're willing to give you the source code. When Jaguar ships, all of this source code for the Jaguar MB&S responder in portable C will be in Darwin.

If you're a hardware vendor that's really in a hurry to ship a product before that time frame, contact Tom Weyer and we can give you an advance copy of that source code. We don't have the resources to support every company doing that, but a small number, if you've got products you really want to ship and you're excited about this, by all means contact Tom and we'll work with you.

find out more about what this is doing, because you don't really believe me, you can look at this stuff in EtherPeak. That's the cool thing about using a standard packet format, is that EtherPeak already knows how to debug and decode DNS packets. The only thing it doesn't know is that multicast DNS is using port 5353.

So you just need to open your IETF.dcd decoder file with whatever favorite text editor you want, find the line that recognizes DNS packets, and duplicate that and make another recognizer that says 14E9, which is 5353 in hex, go to the DNS decoder. You don't need to write all that down. The instructions are on the multicastdns.org website.

But you put that one line in your decoder, you can look at all the packets that your Jaguar seeds are sending out and see exactly what they're So, ZeroConf is cool for Apple, but we really have it easy because we have computers that have got screens and keyboards on them. So, setting them up is, relatively speaking, not as hard as it is for somebody who's got a device without a screen and a keyboard.

So, the router, the cable modem, airport base station, anything like that is a perfect candidate for this. Network printers, the video camera, another example. Rack mount servers. I don't know whether any of you guys have been into a data center, but it's crazy what they have there. They have the racks of servers, they have all the spaghetti ethernet wiring, and they have spaghetti serial port wiring going to like a Livingston port master or a Cisco 3600 so that they can sit with their serial terminal. And they've got like a logical serial network where they can log in to any server over the serial port to type commands to it.

And for the disk arrays, they've got a fiber channel network. So, they're running three parallel networks. They're running three parallel networks through their data center. All of this could be done over IP. With zeroConf, you don't need the serial ports. You can just telnet or SSH to the server. It doesn't matter if its IP configuration is messed up, because if it has a linked local address, you can talk to it anyway to fix its standard IP configuration.

There's also an ITF working group working on doing SCSI over IP, because what a lot of the disk people have realized is that their expertise is in making really, really good hard disks, not in making communication technologies. So they've kind of said, well, listen, we'll let you gigabit Ethernet guys and 10 gigabit Ethernet guys build the cool network hardware, and we'll just build the disks.

So there is a move right now, and it is a move. It may be a couple of years away before you see products that do this, but there is a move to running everything over IP so that you have one cable going into that server instead of three.

A lot of you may have TiVos in the house. When people get a TiVo, they like it so much they buy a second one for the bedroom TV. And then what's the problem that you have? You've got the shows recorded on the wrong TiVo. Networking home appliances like this is going to be a huge application for ZeroConf.

And there are many, many more, which I'm sure you're already thinking of. I had a bunch of examples here of things that I thought would be cool products, but every time I said them, Steve said, "Ooh, that's a good product. Don't tell them about that." So I'll have to leave that to your imagination.

So now, Eric's going to help me with another demo. Browsing to find a service is really cool, but this is zero configuration, not little bit of configuration or easy configuration. So, I want to show you a demo here which some of you have seen before, but we have a bit more time now to tell you exactly what's going on. I have a document here. To prove this is live, on the corner here.

Can I get your name? Howard. Howard, okay. I know Howard, but he was the first person I saw say, "We'll use Howard, but this is not rigged." So type in howd. Now I'm going to print this document. But you see, I just bought this Mac in my scenario. I don't have a printer. It's never had a printer. It's never had a print queue. So I go down to my computer store and I buy a printer. This printer's never been turned on before. It's never been configured.

Can we plug in the printer, Eric? Now you're thinking, I've got my computer, I've got my printer, they're plugged in with a cable. What does the computer think I want to do with it? That's what I want to do with it. One finger, hit the return key, and we'll see whether that works. The printer might take a minute to warm up. Oh, no.

So I want to stress that this is not rigged. This is real. You put a multicast responder in your printers, they will do this with Jaguar. Thank you, Eric. Okay, so let's move on. Actually, there's one more thing I want to do. Eric, do you have your laptop there? Yeah, I've got it.

Why don't you plug that Ethernet cable into your laptop? You can open it up. Eric told me earlier he had a file he wanted to give me, and we've talked about all these file copying tools. So, I'm not going to touch the keyboard here. Let's see what this is doing. Oh, that's the disk of Eric's laptop.

Thanks, Eric. So now I hope I've convinced you that this is cool stuff. I'm going to tell you about the APIs that you can use in Jaguar to use this in your products. Back to the slides, please. Thank you. So, there are APIs at various levels you can use. The lowest level API sends marker messages to the MDNS responder daemon.

You can use this in standard Unix tools like Apache that aren't linking with the rest of the OS X framework. All of the APIs here take a common kind of format, which is you make some call, DNS service something, and it returns you a DNS server discovery ref.

From that ref, you extract a mark port, which you have to listen for messages on. You can add it to a mark port group. You can create a CF mark port from it and add it to your CF run loop if you've got a run loop application. And whenever you get a message on that port, it's your responsibility to call DNServiceDiscovery, handle reply. And then when you're finished, you deallocate. So here are the three APIs I want to talk about. You have a service. You're running a web server, SSH daemon, a game, whatever it is. You want to advertise that that's existing on the network and listening for incoming connections.

You give the name, the type, the domain. For now, I suggest you just pass empty string for the domain to mean the default. In the shipping version of Jaguar, you'll be able to register on unicast domains as well as on local multicast, but for now, stick to local multicast.

You pass the port number you're using because you may not be using the well-known port. You have a text record, which you can use for any additional information that your protocol needs. In the case of the HTTP for the web server, that additional information was the path of the URL you want to fetch.

And you also pass a function pointer for a callback function, which will be called if there's a name conflict. If someone else is using your name, you'll get called, and that's your opportunity to either programmatically generate a new name just by incrementing a digit on the end, or you can prompt the user and say, Stuart's computer is already in use on this network. Please pick a different name. Your choice.

For browsing, you tell it the type and the domain you're looking for, and it gives you callbacks telling you when it finds services. You'll see the template here is very similar to the last one. It's just that you don't provide the name, the port, and the text record because that's what you're going to learn in the reply.

Once you've browsed and found a service and maybe stored that in a preference file or whatever you want to do with it, when it's time to use that service, you need to resolve it to get an IP address. And there you give the name, the type, and the domain, and when the service resolves, normally very quickly, normally in a millisecond or two, your callback gets called. The reason it's an asynchronous callback API is because if the Ethernet cable's being unplugged or something else has gone wrong with the network, it may not complete immediately.

And users hate it when the whole UI freezes because something isn't working. So if you want to give your customers a pleasant experience, you need to make everything asynchronous. If there's a lengthy operation, put up a dialogue with a cancel button so that they're in control. There's nothing users hate more than seeing the spinning pizza of death and not being able to do anything about it.

So that's the simplest low-level API. And if you're writing a simple daemon that doesn't link with any other frameworks, that may be the best one for you. But we have some other choices as well. So moving one level up from the Markport API, CFNet Services provides a very nice API that fits in much more nicely with the programming model of the rest of Core Foundation. And moving forwards, you'll expect to see new functionality and more ease of use happening at that layer.

Above that, Directory Services and NSL are also clients of that same CFNet Services API. Right now, you can use things like the NSL browser to access multicast DNS, but you don't get all of the functionality. For instance, you can browse the network and find services, but when you select them, what's returned is a resolved URL with an embedded IP address in it, which is great if you want to use the service right now, but if you want to save that away in a preference file, saving an IP address is not good. You want to save the name. So there are plans for adding that support in Directory Services and NSL, but not in the Jaguar timeframe. So now I'd like to invite Jeremy Wyld to come up and tell you the details about the CFNet services.

Thank you. So I just want to talk briefly up here, and then we'll get Stuart back up, talk some more. I want to talk to you about a set of APIs called CFNet Services that are located in the CFNetwork framework. In order to do that, I need to quickly give you a one-slide overview about CFNetwork. CFNetwork is an abstraction of common networking protocols: SSL, HTTP, and of course, Rendezvous.

CF network is built and written in the style of core foundation. That means we have CF types, we create CF types, we use CF types, and then you get the use of the core foundation's reference counting, so CF retain, CF release. CF Network is located in the Core Services umbrella framework, so that's what you'll link against in order to get this stuff.

To underline CF Network, all of Apple uses CF Network for its underlying networking protocol usages. So, applications and frameworks like Mail, iChat, NS Services located in Foundation, and then also NSL uses CF Network. This, of course, is where CF Net Services is located. CF Net Services is your abstraction layer for performing your rendezvous, DNS discovery APIs. We have two types, two CF types. We have a CF Net Service and a CF Net Service Browser. A Net Service represents single entity then on the network, and then the Net Service Browser represents search for those services or domains.

So these two objects, how do you go about using them? There's one usage model for both these objects. You're going to create them, you're going to schedule them on a run loop, then you're going to tell them to perform whatever they do. You tell them to run, and then you sit back and wait to handle the callbacks as they occur.

There's going to be three main tasks that you're going to want to perform when using these objects. You're going to want to advertise your service, you're going to want to find services that are published on the network, and finally you're going to want to connect to and use a service on the network. So what I want to do is take a sample HTTP server, I'm going to walk through some code, you can just assume that this HTTP server, like Stuart showed, is just listening on the network. There's no pre-advertised port. We don't tell someone that's listening on port 80.

So here I'm going to register our service. We create the object, we schedule it on a run loop, and then we tell it to register. The things that I want to point out here, we're registering it on local domain indicated by the empty string. We're doing HTTP. We've given some name. It could be the name of the computer. It could be something we asked the user.

But the one important note here is the port. Assume the port to be opaque. In this case, just assume we want and asked the port for its local binding address. We're just going to register it on the network. At some point in the future, we're going to get an error for some reason.

The most common, or the most important error that you'll want to really, uh, Take account for is the name collision. So someone else on the network has a service registered by the same name on the same domain. At that point you want to formulate a new name. So you could add a one or a two to the end or you could prompt the user and ask for a new name.

Either way we'll go ahead and register it. And finally we just go ahead and clean up the object. So we've got this service registered on the network. There's going to be someone out there that wants to use your service. Or hopefully they want to use your service. Very similar. We create the object.

We schedule it on a run loop. We tell it to go find services. So we're telling it to go find services of the HTTP type. Hopefully we'll find things on the network, things will go away, our callback fires. We're going to be told to add items to a local caching list or remove items from a local caching list. And I'll do just that.

Now, the one thing to note here is this KCF Net Service More Coming flag. This is used to indicate that very soon after you return from this call, you're going to get this call again. This is to handle large networks where you have lots of services on it.

So instead of having one of those apps that flickers every time something comes in and goes away, this will help you prevent that. So you wait to do the update when you don't get this flag then. So we've got one registered. We've got someone out there finding these things. At some point, someone's going to say, "I want to use that service," like Stuart did in his browser.

How are they going to connect to and resolve that thing? This is very, very similar to the registration. Instead of performing the register, we're going to perform a resolve. The other thing to note here is that we're creating the object with a zero for the port value. The port is not important when we're resolving. We're going to go to the network and ask it for this thing's address, which will have the port in the address. So at some point in the future, that thing is found on the network.

Our callback fires were going to be given an address inside of the CFNet service that we were looking up. Now the thing to note is that this stuff is inherently multi-homing supported. So when we call to get the address from the Net service, we'll get an array of addresses. And then the right thing really to do is go through each one of those addresses, trying to find the one that will eventually connect for you. Um, the values or pieces of data that are inside the array are simply SOC adders that are wrapped as CFDatas.

Had we not gotten a no-error response, we simply clean up our object, toss it away. So that is a quick overview of CFNet services, how to use them. I invite you to go and look at the headers in CFNetwork. And I would also suggest that you try getting notes or seeing the sessions 805 and 808, which covers CFNetwork and CFRunLoop and CFStreams.

So what's next for you guys? If you're software developers, use the Jaguar APIs. If you're hardware developers, build ZeroConf into your products so that everything can talk to each other. And This is not just for Macs. One of the great things about multicast DNS is you can write an application that sends and receives those packets, so you're not hostage to the operating system vendor providing the support. This is not like something like TCP that's got to be in the operating system before you can use it.

I'd like to invite Bob Bradley to come up on the stage. Bob works on airport. Bob has been responsible for the Windows airport configuration tool and a bunch of other airport software. So I've just said that you could make this work on Windows. I want to show you that it does.

So, very quick demo, but we have multicast DNS running on Windows. Of course, that means we have multicast DNS running in the firmware of the airport base station as well. This is 3,000 lines of very portable C, so it should be easy for just about any hardware vendor. If you've got a processor and firmware, you should be able to fit this in. Thank you, Bob.

Here are some interesting sessions. Now, these are all in the past, but you can get these on DVD. If you want to find out more about networking and specifically the CF network APIs, those sessions are available on DVD. If you've got questions, specifically if you want to get the Apple source code, contact Tom Weyer about that.

On your preview Jaguar seed CDs that you have, dnsservicesdiscovery.h is the low level APIs. There is also sample code showing how to use the high level CFNet service APIs. For general information about the IETF, go to the IETF website. The IETF is a completely open organization. There are no membership fees.

If you're interested in Zeroconf, please sign up for the mailing list, participate in the discussions, because that's how the work gets done. If you want to register your own port number and protocol name, go to the IANA website. And if you just want to find out more about how all this stuff works, zeroconf.org, multicastdns.org, and dnsservicesdiscovery, dnssd.org, give you information about that.