Good afternoon and welcome to the Rendezvous session. I'm Craig Keithley. I'm Apple's I/O technology evangelist in worldwide developer relations. One of those I/O technologies is Rendezvous. And over the past year, we've been working very hard to bring Rendezvous to as many products as possible. I have over 120 developers actively working on projects. More than 35 or thereabouts have shipped.

There's more on the way. If you were at the session earlier this week for open source, you saw that OpenPlay now has added Rendezvous support. So in the future, games that use OpenPlay will automatically enable Rendezvous. This is a big step forward. So if you're a game developer and you're here to learn more about Rendezvous, the best recommendation I have for you is go check out OpenPlay. You're going to get the benefits of OpenPlay plus the benefits of Rendezvous automatically.

You know, as we look over the history of networking communications, there are a couple of important stages. You know, I can think back to the first time I used a dial-up modem, dialed into ARPANET through my local university, and how exciting that was. And then as AppleTalk came out in the mid-80s, and I was able to easily network products, this is the next generation. It's the way that people should be doing zero configuration networking. It's plug and play.

It's how we want to make devices work. So to go into that, this session will detail what Rendezvous is, what we've been doing for the past year, the new features that are coming in Panther, the new APIs that will be available to you in the future, and we want to go over some hints for software developers and hardware developers.

This will run the range both from software techniques to, licensing the logo. All of you, if you're doing Rendezvous development, should be licensing the logo. It's free. It's an easy way for your customers to know that they've bought a product that works with Rendezvous. So without very much further ado, let's bring up Stuart Chechier, who will go into all this. Thank you. Once again, just like last year, it's a great turnout. I'd like to ask everybody to shuffle in and fill up the seats because there are still people standing in the doorway and people trying to get in. So, if there are any gaps, close them up.

So I'd like to just get a show of hands. How many people saw the WWDC presentation last year on Rendezvous? Okay, about half, that's good. So, I'm not going to repeat that material this year. I'm going to do a quick overview to remind you what it was all about, but if you want to see more detail about that, pull out your old DVDs from last year and have a look, or if you weren't here last year, then you might be able to find one from a friend and have a look at that.

So, right now, I'm just going to quickly skip through to refresh your memory. We're going to talk about why we did Rendezvous. We're going to talk about what we did to solve the problems. And we're going to talk about how we made it all work. So let's get on with that quickly. We've got a lot to cover.

So the why is, 20 years ago, many people in this room are probably not old enough to remember that, but 20 years ago, there was huge competition in wide area networking. There were all these different protocols, and devices from one vendor normally wouldn't work with devices from another vendor. And this was obviously not a good situation. And the good news is that in the last 20 years, they've all died, and the only thing we seriously consider these days is TCP IP, which is great.

Craig Keithley, Stuart Cheshire So now let's look at local communications. In the similar era, 10 to 20 years ago, we had all these different connectors on our computer, and the good news is, those have pretty much died and gone away as well. Craig Keithley, Stuart Cheshire Unfortunately... We still have all these different ways of connecting to something like a local printer. And as time moves forwards, the list is getting longer. These are not all technologies that Apple ships, but they're all local communication technologies that are in the marketplace that people are working on and developing.

So what did they do to solve this incompatibility problem in the wide area? And the answer was they picked one protocol and said, everything talks that protocol, and yeah, there may be some little benefits of another protocol, but there's a bigger benefit in having a standard. So we should do the same thing for local communications. And going even further than that, the protocol for local communication should be the same one that is already won in wide area communications.

Now when I say that, a lot of people react by saying, well, that's crazy. Nobody wants to type in subnet masks and IP addresses just to print on their inkjet printer, and of course, they don't want to. The point is to make it so that you don't need to do all of that to make IP work.

So, the answer to solve this problem, you all know, that's why you're here, is Rendezvous. And the press has been saying marvelous things about Rendezvous. There are lots and lots of good stories about it. One of my favorite headlines is "Backstage pass to the future." I think that really sums it up.

Tim O'Reilly, very well known and widely respected person in the industry, said this about Rendezvous. "It is truly revolutionary. It's one of the things that's going to have the largest impact on application design over the next couple of years. We're just at the beginning of the second internet revolution, and Rendezvous is a big part of it. You can't get much better than that." So here's the quick recap of last year.

What do you need to do to do IP networking? Well, you need an address, you need to be able to use names, and you need to be able to browse the network to see what's there. Very simple solutions. The point of this is to make it simple. When you've got a gigahertz processor and lots of RAM, most software problems can be done with enough effort.

But when you've got a little inkjet printer for $50 with a tiny amount of firmware and a slow process, you don't have that luxury. So one of our overwhelming goals of Rendezvous and driving principles is making something that isn't just for Macs and PCs. It's for all of the other little devices out there as well, and not just the devices that currently do networking, but many of the devices that don't do networking at all right now.

So, in that principle of simplicity, you need an IP address? Pick one at random. Send an ARP request? If nobody answers, you can use that address. Just like AppleTalk did. Very simple. There's a range of addresses reserved by IANA for this purpose, and there's an internet draft describing how to do it, and you can find that at zeroconf.org. But what I said is pretty much summing up how you do linked local addressing.

Link local addressing isn't new. You've probably seen it before. When you see 169.254 in the control panel, you say networking is broken. It's understandable why people think that, but they think that because on its own, a self-assigned address isn't very useful. In Jaguar, we introduced the rest of the technologies to make it useful, and now you can do things with that link local address, even if you can't communicate with the global internet and buy books from Amazon or do whatever you want like that. It's been around since 1998 in Mac and Windows. It's in OS X. It's in Linux. Pretty widespread. You might know it under the names Autonet, AutoIP. And of course, IPv6 already has link local addressing. Rendezvous works both on v4 and v6.

So, naming. Similar principle as before. DHCP is great. If you have a DHCP server, that's great, but if you don't, make up your own address. Same thing here. DNS is great, and if you have a DNS server, there's no reason not to use it. But if you just have two computers and you want to exchange a file and you forgot to bring a DNS server with you, that shouldn't cripple you.

Craig Keithley, Stuart Cheshire So, multicast DNS is how you do name lookups when you don't have a DNS server. Same packet format, same query syntax, just multicast it. Every device has a little responder, just like an AppleTalk NBP responder, and when it sees a request for its name, it answers. Again, we want to make this very simple.

The specifications for that, you can find at multicastdns.org, but again, the description I gave is most of what you need to know about it. The client has been in since Mac OS 9, it's in 10 of course, it's in Linux, there are several projects, if you go to .local.org, you'll find several people working on multicast DNS for Linux. Microsoft, characteristically vague, I can say that at the IETF plenary presentation last summer in Japan, they described multicast DNS as a vital technology for IPv6 and said it was under consideration and or underway at Microsoft, so you have to take that for what it's worth.

What this gives us is the ability to type laser-eye to .local into your web browser and connect to the configuration page of your printer without having to know what address it picked for itself. So this is a huge step forward over typing dotted decimal IP addresses, but of course, we're not content to stop there because Apple Talk did better than that, and we want IP to do better than that. So we want to raise the bar. We want you to be able to find what's on the network without having to know what name to type in.

Devices, we know, are going to need link local addressing anyway to work usefully. They're going to need local naming to work anyway. Rather than add a third, different body of code to do service discovery, the insight we realized is that the multicast DNS code also gives you service discovery for free. For the guys making the $50 inkjet printer, that's a big win.

I'll explain quickly how that works. You do a standard DNS query for record type PTR, and here the query is semantically saying, find me devices on the network that speak the IPP printing protocol, because I'm an IPP printing client, and that's what I'm looking for. You do that query, and you get back one or more responses from the devices on the network that implement IPP. We want these names to be user-friendly, just like AppleTalk. These are structured.

These are structured names with three parts, and the first part is the user-friendly name that you display in a graph user interface. Normal host names in DNS are limited to letters, digits, and hyphens, and they have to be short because you want to type them on a command line. But these things you pick in a browser, so they can be long, they can have spaces, they can have uppercase, lowercase, punctuation, full UTF-8. You can put kanji characters in because you don't have to type them. You just click on them and list.

The names are structured just like the old Apple talk, name, type, and zone. And here its service name is the first part. The second two labels are the service type, in other words, the protocol name of the service. And the remainder is the domain. Craig Keithley, Stuart Cheshire The names are structured just like the old Apple talk, name, type, and zone.

And here its service name is the first part. The second two labels are the service type, in other words, the protocol name of the service. And here its service name is the first part. The remainder is the service. Service types. Important point here. A service is identified by the protocol it speaks.

Human beings think in terms of objects like printers, but from a software point of view, if you've got an IPP client, what you're interested in is finding things that speak IPP. Some of them may be printers, some may not. There may be printers that don't speak IPP and you can't talk to them.

It's no benefit finding something you can't talk to. At the network level, what you're looking for is the software entities that implement a particular protocol, not bits of hardware. That's an important point because many service discovery protocols get that wrong. They look for hardware and then having found the hardware, you're not quite sure what it does and then you have to go through a whole negotiation phase.

So having found the names of the services on the network, what is it that we found the name of? And the answer is in DNS, we found the name of a service record and a text record describing that service. So when it's time to print, you want to know the IP address and port number where that service can be reached. Craig Keithley, Stuart Cheshire Now, with DHCP, or link local addressing, the addresses might not be the same from day to day, just like AppleTalk.

So when the user picks a default printer, we don't save the IP address, because that might be wrong tomorrow. What we save is the Rendezvous name, and then on demand, we resolve that for an address by doing this query. Craig Keithley, Stuart Cheshire And the answer we get back is that the sales printing service today can be found on port 631 at myprinter.local. It's a PostScript printer, so its page description language is PostScript.

Craig Keithley, Stuart Cheshire Craig Keithley, Stuart Cheshire And the clever thing about DNS is it can give you answers you didn't ask for if it thinks that you're likely to need to know that information. It saves you asking another question. Craig Keithley, Stuart Cheshire And in this case, the responder said, well, you didn't ask for the address of printer.local because you didn't know it was printer.local when you asked the question, but you're going to want to know that, so I'll give you the answer anyway. So there you see the address has been put in the packet automatically. So one query, one response, you have the information you need to print on that printer.

This was launched with great fanfare last year in Jaguar. It's in Darwin, so it's very easy to get it and run it on any platform you want. There are also other independent implementations completely separate from Apple, which is great. Just like the others, specification is freely available, and you can get it from dns-sd for dnsservicediscovery.org.

So, that was the recap of where we were last year. What's happened since then? We shipped Jaguar, and we shipped a few bits of software that we're using Rendezvous. iChat is an obvious example. Finding network printers is another obvious example, although this time last year, there weren't many Rendezvous printers on the market. That's changed dramatically.

Finding Apple Share servers is another example. Since then, we've done some more updates, and we've advertised some more services. You will see HTTP, when you turn on personal web sharing, you'll see it showing up in Safari. You might say that too many of them are showing up in Safari. It kind of shows how many people have accidentally turned on personal web sharing, but don't actually have a web page there that they're intending to share.

Apple has shipped hardware products using Rendezvous. The obvious candidates are the ones that don't have a screen and keyboard, so the only way to find them is over the network, and you need to be able to do that. No matter how busted the network is, you need to be able to find it. If the airport base station is your DHCP server, then you don't have DHCP until you've connected to it to turn on DHCP, so there's a bootstrap problem there.

Software products, you've all seen Safari, you've all seen iTunes, the Shake network video transcoding software is another thing that uses Rendezvous. A lot of products from third parties. It's absolutely amazing to me for a technology to get this much adoption in just one year. I can't think of any other new technology that's had such an overnight success.

And I think that says a lot about the cost-benefit ratio of Rendezvous. It is so easy to do, and the benefit is so immediate and so obvious that there is really no reason not to use Rendezvous. Anywhere that you do networking, you're looking for service, you're providing a service, adding those few extra lines to do Rendezvous is such an obvious win. So printers were the first candidates because Apple-taught printers were the mainstay of network printing, and those were the first people to jump on. board rendezvous.

Got some other little bits of hardware, which I'll show you later on. TiVo's in the home, great example. You have music and photos on your Mac, and you don't want to sit around the computer to watch them, you want to sit in the living room and watch them on the TV. I talked about TiVo last year as a purely hypothetical example of something I thought would be good, and the great news is that they actually did it, and less than a year later they're shipping that as a real product to customers.

Chaparral RAID, just like XSERV RAID, another example of a headless device. Martian NetDrive is another great product, little box, $400, put it in your garage, turn it on, it's a network file server. No screen, no keyboard, it just shows up on the network. You configure it through Safari, which shows up automatically using Rendezvous, and it gives you a place to store the data in your house, so your computer doesn't have to be turned on all the time.

Lots and lots of software products, network databases, games, Hydra is a great example, I'll show you that in a minute as well. FTP, clients and servers, lots and lots of software things because it's so easy to do. We have Rendezvous on other platforms. The Crocodile Rendezvous FTP server for Windows advertises using Rendezvous on Windows and shows up in the FTP Rendezvous menus on all FTP clients on Mac and Windows.

Swamp Wolf has taken the Apple Darwin code and done some extra work on that to turn it into a system service for Windows, and I hope to show you that a bit later as well. JRendezvous is an implementation of Rendezvous written in pure native Java. Interesting exercise in showing what Java can do.

And the people doing that are running it on cell phones, apparently. They have cell phones that have a Java engine in them, and so everything you write has to be in Java. I don't know about their product plans, but we can only speculate about where that might be going. There's apparently a version in Python as well. Lots of things that people are doing. And Linux, as always, has a lot of open source efforts going on.

Dotlocal.org is an interesting resource for the Linux work. So, time for some demos. Let's go to number four, please. So, let's plug in and see what we have on this network.

Okay, first thing, we have a Brother printer here, one of the first companies to ship a Rendezvous printer. Let's turn that on.

Okay, well that's, okay we have a link light, I'll give that a second. So if you're buying a printer now, pretty much all the printer vendors have printers with Rendezvous built in. But if you have an old one lying around that doesn't have Rendezvous, this is a great little product from SEH, Intercom Network Print Server.

This little box here implements a print server. So I plug it into the parallel port on this old printer here. This is just an obsolete printer I found lying around in the corridors at Apple. The reason you know it's obsolete is because it doesn't have Rendezvous. but there's hope for it because we have this.

So this is the brother, took a minute just to power on. And just like that, without knowing what address it picked for itself, we're now connected to its status page. We can view the toner levels and view all of its configuration information. So, easy one-click connection. I plugged in the Intercon print server, and it shows up as well. And that's it.

When I was bringing all this equipment and setting it up, the conference organizers were saying, "You're mad. You can't do this. This is not the keynote. You don't have two hours to set up. You've got 15 minutes between sessions." I said, "It's okay, guys. It's Rendezvous. I don't need to set it up." So we'll see whether they were right. This is something I love. I have to tell you about this.

People who work in data centers are probably familiar with all the equipment in the 19-inch racks that's got serial ports on it for configuration and setup. And we don't have serial ports on our computers anymore, so you end up needing one of these USB to serial adapters. Well, this is like that, except this is an Ethernet to serial adapter.

And you just take this and plug this into the serial port on whatever device you want to configure, and it advertises Telnet service. So now you don't have to run serial wires all over your data center, it's just on the network like anything else, and you can Telnet to it. And I forget the price of these, I think these are about $50. These are even cheaper than USB to serial adapters, and this does Ethernet. This is, it's called SitePlayer. If you go to siteplayer.com. Sorry? I think SitePlayer is the place to look.

All right, good. Yep. Site, S-I-T-E-P-L-A-Y-E-R. In fact, why don't I plug it in and then we'll see. So plug it in, light is on. Okay, this thing has 16K of flash memory. And in that 16K, the guys implemented TCP, IP, UDP, ARP, DHCP client, DNS client, Rendezvous, web server, Telnet server.

Okay, and of... And of that 16K, 9K of it is the HTML text of the web pages. So he's got 7K for code. And this is not even assembly code, this is C. Absolutely incredible.

Click it, and Safari should open a window. And just like that, we connected to it, have access to its configuration page.

So, we Rendezvous is all about enabling IP. In as much as you can run IP over USB, which you can do with various products that I think emulate Ethernet over USB, then Rendezvous just works transparently like any other IP device. But if you've got a device that doesn't speak IP, then it's kind of operating in a different world. Things like this Intercon print server are the kind of gateway from the IP world to that world.

I was going to bring some equipment with me, but unfortunately most of the things these days that use serial ports kind of fit in 19-inch racks and are a bit bulky, but this is one thing I found at home. This is a little voice-over IP product. It's got Ethernet on it, but you have to connect a serial port with a terminal to configure it, so this is a great thing for connecting to the site player. Maybe we'll get time to look at that more later. I think that's for this round of demos. Let's go back to the slides, please.

Alright, so what new features do we have to offer you in Panther? Jaguar had IPv6 support in the kernel, but Rendezvous didn't use it. The good news now is that Rendezvous is using it. It sends its queries over v4 and v6, and it will advertise services that are running on v4 and v6. So, When you resolve, you can now expect to be getting V6 SOC adders back as well as V4, and you should pay attention to that in your code. Don't assume it's always V4.

We have subtype browsing for more selective queries, that's described in the drafts. We have a lot of performance improvements, both in terms of CPU performance, and in terms of smarter algorithms to use the network more efficiently. These were things that we all had planned on the roadmap, but didn't make it into Jaguar. We have a cool feature that gives you faster purging of stale cache data, which has been very widely requested. I'll talk a bit more about that.

Network administrators last year at the feedback forum asked us for a way to enumerate all services on the network. Now, for a software vendor, finding everything on the network isn't very useful if you can't communicate with it. It's only useful to find things that you know how to communicate with.

But for an administration point of view, finding everything on the network is useful. So we had to work out a way to do that that was elegant and efficient, and we did do that, so that's now in Panther. We have a bunch of new client applications using Rendezvous services, and we have some slight improvements to the APIs that reflect feedback we got from developers over the last year.

One of the trade-offs in any network protocol, including Rendezvous, is if you're going to present a list of resources on the network, you have a trade-off between the timeliness of that data and the accuracy of it, and how quickly you poll the network. And if you're willing to poll the network once a second, you can have very up-to-date data, but of course, that would be bad.

So, we tried to make Rendezvous very efficient on the network and very frugal with its use of packets. And that means it will cache data typically for up to two hours. And what that means is that if you shut down your Mac, gracefully it sends a goodbye packet and it disappears from everybody's browser list.

But if you just yank the Ethernet cable out of the printer, it doesn't get a chance to send the goodbye packet. And people see these stale entries showing up in the browser list, and that's frustrating. Because they see the printer, they try to print, they get an error. They go back to the list, it's still there. They try again, they get another error. Very frustrating. So, what we do now is we don't continually poll the network, because that would be bad.

But when you try to print or use a service and fail, then internally the code kind of asks itself a question. It says, well, why were they trying to use that service? Well, maybe it's because it's in the browser list. And if it didn't respond, then maybe it shouldn't be in the browser list.

So, the time to live on that cache entry shortened from two hours down to a few seconds. The machine sends a couple of queries, and if it doesn't get an answer, then it's flush from the cache and it disappears. And that produces a dramatic difference. In user perception. They see the stale printer, they try to print, it doesn't work.

They go back to the list, and it's not there anymore. Somebody must have just turned the printer off. Now, that's not actually what happened. It was actually turned off half an hour ago. But the important thing, this is very important from a sort of human factors point of view, is that the person has a consistent mental model for what happened. And then they're not frustrated, because at least it makes sense to them.

What going even beyond that, when the other machines on the network see you do a couple of queries and not get any answer, then they also conclude that that data must be stale and delete it from their caches as well. So only one person has to try to access the stale printer, and everybody gets the benefit of having it disappear. So big improvement in user experience there without any extra packets on the wire, which is great.

One of the future plans, I said this only works right now with .local with local multicast, but we are planning, I'm not announcing any dates or time table here, but we are planning to do this globally using unicast, DNS queries, and DNS dynamic update. So bear that in mind when writing your code. Don't assume that the domain will always be .local. Okay, so back to number four, please.

So one of my earliest memories of computing when I was very young was the big teletype machines that printed out on rolls of paper at 110 board. And that was how everybody connected to the Unix mainframe was over these serial connections. And the DNA of that kind of lives on in OS X. Terminal may actually be the oldest DNA in that sense that's in OS X.

And this is emulating a roll of paper on a teletype. And there are lots of things using Rendezvous in Panther, but I thought going all the way back to the start would be interesting. So can something as ancient as this benefit from Rendezvous? And this is pretty neat. Command-Shift-K, and we've got a little server list. And right there is Telnet connection to this site player box.

Let's put it into character mode and let's plug it into this piece of prehistoric hardware I was talking about. Getting this demo set up was the hardest demo of everything I did. And if you remember using serial ports, it's this stack of gender changes and DC and DTE and CTSRTS, X on, X off, board rates. And you type stuff and nothing happens. And you know, is it turned on? But I finally found a combination that works.

Let's power this guy on and see what happens. All right. So, you know, we can set its IP address, we can reboot it, we can let it do its thing, and this could be something over the other side of the data center, and you just telnet to it, and in fact, all of the serial ports in your data center just show up as things here. So... All right, thank you. Back to the slides.

So, what new APIs do we have? The good news is, they're modest improvements, they're not things that are going to require you to gut your code and change it. NSNet Services is unchanged, CFNet Services is unchanged. We've made some minor updates to the low-level DNS service discovery APIs, but the old calls are still supported, so your current applications will continue to work.

Just to remind you of the architecture, on top of the kernel at the lowest level is the MDNES responder daemon that implements the protocol. The DNS service discovery APIs communicate with that daemon to communicate what services you want to register and what things you want to browse for.

Led on top of that is the core foundation CFNet service, and led on top of that is the Cocoa NSNet service. Depending on whether you're writing a Cocoa application or a raw BSD command line tool influences which of those APIs you would want to use. That's really a personal preference. But at the low level... The new DNS service, Register Call, offers a few improvements. Some people need to advertise services on a specific interface on multi-home machines. This is not common, but if you want to do that, you can now specify an interface.

When you pass empty string for the name to register, the system will use the default name for you. But you don't know what that name is. That's kind of the point of passing empty string, is it saves you needing to know what it is. But if you're writing an application where you want to filter yourself out of the list of results you get back, knowing what name the machine picked for you is useful. So we've added that.

We've raised the limit on text record size. The guidance for text records remains the same. They're intended to be a few bytes of ancillary information. But we did have some applications that legitimately needed a little bit more, and the text record was, when we thought about it, the correct way to solve that application's problem. So we've raised that limit a little bit. We don't want to raise it above 1400, because we want these things to fit in single Ethernet packets. Things get much less efficient when you have to fragment the IP packets.

Text records can contain arbitrary binary data. That was almost true in the past, except ASCII 1 was used as a delimiter. Now, it's just an opaque blob of data. It's passed as a pointer to data and length, so you can pass true binary data now. And we've added a new facility, which came as a request from the printing industry, for what we call placeholder names or flagship names.

And the idea there is, if you have a printer that offers IPP printing, and you call it sales, and you have another printer that also offers printing, but it's using PDL data stream protocol instead, each service is its own namespace. And most of the time, this is good. You can have a file server called sales department and a printer called sales department.

And that's not a conflict, because they're different things. But having two printers called sales department is confusing. So the printer guy said, when we register a printer name called sales department, we want to know that no one else is using that name, not just for IPP printing, but for any kind of printing. And the solution to that problem is that for each family of protocols, like printing, one protocol is picked as kind of the flagship protocol of the fleet.

And even if you don't implement that, you can still print. And if you don't implement that protocol, you register a service, a fake service, with a port number of zero for the flagship protocol. So a printer that only speaks IPP would also register an LPR printing service with no port number. It won't show up in any browser lists when people are browsing for LPR printers.

But if another printer tries to register that name, it will get a name conflict, and it will be told, you can't have that name because that's in use. So this allows protocols to be grouped into families that kind of are conceptually common. functionality even though they're a different protocol.

Browsing, again, if you want to pick a specific interface, you can. And the replies that come back indicate which interface the reply was found on. And when you have two services with the same name, one on Ethernet, one on Airport, knowing which one you're talking about is useful.

It doesn't happen very often, but when it does happen, this solves that problem. Craig Keithley, Stuart Cheshire Browsing, again, if you want to pick a specific interface, you can. And when you have two services with the same name, one on Airport, knowing which one you're talking about is useful. It doesn't happen very often, but when it does happen, this solves that problem. busy, idle, away.

and because of that, all the iChat clients leave their resolves active because they want to keep getting callbacks when that information changes, but they don't need to be constantly querying for IP address and port number. They only want to know about the text record. So the new call lets you be more selective and consequently more gentle on the network by only asking for what you really care about.

Text record limit, as I said, has been raised in this call as well, and you can fetch true binary data in this call. And we've made a number of efficiency improvements so that when things like iChat do leave their queries active on the network, it generates a lot fewer packets.

Some specialized calls. If you want to make a proxy responder, which is advertising services on their behalf, say you've got old network printers that don't have Rendezvous and you want to run a proxy that advertises on their behalf, the register record call lets you register a whole bunch of records more efficiently and lets you do specialized DNS records. It lets you register any arbitrary DNS record, whereas the previous calls are focused around the standard DNS service discovery conventions.

DNS service query lets you query an arbitrary record, and the reconfirm record is one of the triggers for the mechanism I was talking about before for the fast cache expiration. If you get an IP address back from DNS service discovery, and when you try to open a TCP connection, it doesn't work, you can call this routine to give a hint to MDNS responders that that data it gave you may not be good anymore, and it should go back and check on the network.

Obviously, use that cautiously, because if you had a bug, that could do bad things to the network. Thank you. So, in the last year, we've had a lot of software developers use Rendezvous, and we've found some common themes emerging of things we had to help them with. So, I'm going to talk about some of those today.

So, obvious advice, use Rendezvous and put the logo on the box. If you're a software developer, it's very similar to using the QuickTime logo. If you use Rendezvous on OS X, you can use the logo. And that's a message to your customers that you have a quality product that's easy to use.

People were confused initially about naming, and unfortunately it is just a little bit confusing. There are two kinds of name. There are short names that you type on the command line. You want them to be short and easy to type and don't have funny characters in them or punctuation, and that's good for command line interfaces.

But when you're browsing, there's no reason to be restricted to that. So in Jaguar, there are two names in the sharing control panels. There's the computer name, and there was the thing that was labeled the Rendezvous name. And it is the Rendezvous name in the sense that it's your linked local host name for command line use. But a lot of people took that to mean that Rendezvous names have to be lowercase letters, digits, and hyphens, just like host names. That's not the case.

And when you register a service, most of the time, use empty string, and the system will just use the default computer name for you. And if there's a name conflict on the network, it will add a number two on the end and re-register, so it will handle all of that for you. If the user changes the name in the sharing panel, then it will update the name of your service automatically. So for most applications, using empty string is what you want.

If you want to specify a different name, that's fine as well. iTunes is an example of that. In iTunes, you can give a name to your music library, which may not relate to the name of your computer, because it's really naming the music. It's not naming the piece of hardware where the music is living. So, pick which is appropriate for your application.

Very important. The service types are how you identify what service a client is looking for. And if different people use the same service type, then this is going to cause conflicts. That's not good. Clients are going to browse and find things that don't actually make sense. A good example of this is WebDAV. It's a file sharing protocol that runs over HTTP, which is a reasonable design decision. But it's a private design decision for the protocol.

If you have a WebDAV server, don't advertise it as underscore HTTP, because even though it is using HTTP, it's not something that a user necessarily expects to see in their web browser and connect to and see something that's human meaningful. Now, you may have a web interface to your server as well, in which case you advertise that. But underscore HTTP means something a human being would like to look at in their web browser.

WebDAV as a file sharing protocol should be advertised as underscore WebDAV. And the fact that it's layered on top of HTTP is just an implementation detail. And if you think about this, everything runs on top of TCP and everything runs on top of IP, but that doesn't mean all protocols are the same. The fact that they share a common foundation doesn't mean that they're semantically the same protocol.

You don't have to pay to register a protocol name, you just fill in the form. If you want to play around and experiment, all legal service names are 14 characters or less, so make a longer name and you know you won't conflict with a real product. Some developers have concerns that by registering their service, they give away the product they're working on, so that's fine to work with some kind of temporary placeholder name, but when you ship, do the IANA form and get a legal service name, because that way you own it and you can take action if other people come and trample on your service name and mess up your product.

Just like using empty string for name, when you register a service or when you browse for services, use empty string for domain. Empty string means do the default, do the right thing that the system has been configured to do. And right now that means local, but in future that will mean different things. And if you pass local, we'll assume you meant you only want local. So unless that's really what you mean, pass empty string.

Another common error, partly because the sample code we gave out kind of illustrated how to do resolves, and people assumed that you had to do it that way. You don't need to resolve everything you find. That's very hard on the network. You only need to resolve when you're ready to actually use the service. And a related point is, don't store an IP address and port number in the preference file, because it might be wrong. Don't even store a host name. Store the service name, look it up on demand.

Don't assume IPv4 anymore. Every Jaguar and Panther system runs IPv6, and when you browse, you will find IPv6 addresses. So you should either use them, or you should very least be aware of them and handle them properly in your code. Don't crash or bail out just because you get a SOC adder that's not AFInet.

When you do a resolve, remember to cancel it afterwards, because as long as that resolve is active, like iChat, it's constantly querying the network saying, has the data changed, has the data changed? And you do this enough, it can be a big burden on the network. Craig Keithley, Stuart Cheshire After you've established your TCP connection, you can cancel the resolve. Now, remember that a resolve can and usually will return more than one result.

If you've got multi-homing, if you've got v6, you may have link local addresses and global addresses and v4 addresses, and the resolve call will give you all of those. Craig Keithley, Stuart Cheshire You don't know which, if any, of those addresses are reachable to you, so if you really want to write a robust application, you have to try connecting to each of those and see which one works. Craig Keithley, Stuart Cheshire But having succeeded, it's time to kill the resolve, because you don't need it anymore.

Common error? In the applications that were resolving everything they found, which is bad in the first place, when they got a remove message for a service going away, they would do a stop resolve on that object, and that doesn't work. When you have a NSNet service object and you start a resolve on it, you have to stop the resolve on that object, not a different object that happens to contain the same service name. And that was an easy mistake to make, but when every resolve you start, you've got to keep your own data structures in memory, your own list of resolves, so that you can actually get to those objects and cancel them when they're finished.

Don't overload Rendezvous. I know it's great and everybody loves it, but you can take things too far. iChat is an example of good use of Rendezvous. They need to communicate information to all the peers on the network, and the choice was use their own multicast protocol or use Rendezvous. And we looked at the design and we said, "Well, you know what? There's no point in you inventing your own thing.

Rendezvous is there. Put the data in the text record. Leave a resolve active. That is the right thing to do and it's the most efficient on the network. But before you make that decision, look at it and make an informed decision about whether that's really the right way to do it.

General piece of advice, this is not really Rendezvous, but it's good advice about network design. Now that more and more products are doing networking, this gets more important. Any periodic polling on the network is bad. And in your lab, it might seem fine, but you put a thousand machines doing that, and suddenly things add up very, very fast. 100 meg and gigabit ethernet can carry a lot of traffic, but airport is much slower, and multicast or broadcast over airport is even slower than that.

Airport slows down from 54 megabits to 1 megabit to send a broadcast packet. So even a small number of broadcasts are disproportionately expensive on airport. Be very careful with that. Also, the history of IP has assumed well-known port numbers, and that is less and less true. Especially now with fast user switching, you can't assume your application will get the port it expects, because another copy of your application might already be running. Pass zero when you bind, you'll get a random port, and the good news is Rendezvous advertises your port. You don't need fixed ports anymore when you're using Rendezvous.

Final sanity check. When the product is done and it works and everything seems to be good, have a look at the wire. Have a look at the packets on the wire with a network sniffer like Ethereal or Etherpeak or TCP dump. Newer versions of them already understand multicast DNS. If you've got an older version, it's very easy to add multicast DNS support. Because it's standard DNS packet format, you just need to tell the packet sniffer that port 5353 is DNS packets.

Here's an example how to do it with Etherpeak. You just open the decoder file, find the DNS line, 35 hex is 53. Duplicate that line and put in 14E9, which is 5353 in hex. You don't need to write that down because you can find that on the multicast DNS website.

Have a look at the packets on the wire and see if there's anything that you might be able to improve. It's very easy to have an application where sitting in front of the computer everything is working fine, but on the wire it's sending 100 packets a second. And you say, okay, there's more to correctness than just does the right thing appear on the screen.

So, hardware developers, similar kind of advice. Put Rendezvous in your products, pass the conformance test, and put the logo on the product. The conformance test is Apple's assurance, and your assurance, and the customer's assurance that products with the Rendezvous logo do in fact work well and do give the experience that people are expecting.

Craig Keithley, Stuart Cheshire Put Rendezvous in your products, pass the conformance test, and put the logo on the product. The conformance test is Apple's assurance, and your assurance, and the customer's assurance that products with the Rendezvous logo do in fact work well and do give the experience that people are expecting.

Amen. He went through the menus and there was a checkbox that said "Enable UPnP", which is off by default. So, they just missed the point of, like they put all that code in the product and then missed the point of why they put it there. So, we don't want people to make mistakes like that.

Don't skip link local addressing. Something we've heard from some developers is, well, you give us the multicast DNS code on the Darwin site, so that's great, but you don't give us link local addressing, so we can't do that, it's too hard. The reason we don't have the sample code there is because there really isn't any sample code to give, because the algorithm is, send an ARP packet, listen for an ARP reply, and if you get one, pick a different random number.

And the way you send and receive ARP packets is so platform-specific that it would be different in every platform. It's not a standard API the way Sockets is, because it's generally down at the kernel level. And that means that the only remaining sample code we have left to give you is a random number generator, which would kind of be insulting your intelligence.

It really is very, very simple, and it is a vital part of Rendezvous, because everything you're seeing up on the stage here is using link local addressing, right? That's how I can just plug it in and have it work, and I didn't bring a DHCP server. And that's an important part of making network products that cannot fail, and that's part of Rendezvous.

It's the, when you plug it in, it will work, no excuses, no, oh, well, you didn't have the right subnet mask, and your DHCP client ID was wrong. None of that nonsense, right? You plug it in, it works. For that to be the case, you can't be relying on things like DHCP and other infrastructure on the network. DHCP is great, definitely put a DHCP client in, but don't make it your only way of configuring.

If you're ever in doubt about how fast the things should respond or things like that, think about USB. You saw when I plugged in these devices here, they all showed up within a few seconds. There are some vendors who came to us with a thing that would try DHCP for five minutes before it gave up.

And we had to say, look, nobody wants to wait five minutes, struggling, you know, not sure why their printer isn't showing up, because about 30 seconds in, you know, they're taking a screwdriver to it and changing dip switch settings and fiddling with it and thinking the Ethernet cable's bad and doing more damage. So, USB is active within a few seconds and Rendezvous network devices should be as well.

Another common thing with network devices is when you change your configuration setting, you have to power cycle them to make them work. Don't do that. All Ethernet hardware pretty much these days gives you link change detection, so when you detect the cable is connected, configure a link local address and advertise your services on that interface, just like plugging in a USB cable. You don't have to power cycle a printer when you plug in the USB cable, and you shouldn't have to power cycle it when you plug in the Ethernet cable.

The easiest way to get the multicast DNS and DNS service discovery into your product is just to take our code. It's about 75K, which is not big in today's world of bloated multi-megabyte applications. If you're doing something truly tiny, then contact us and we can work with you, because as I say, we've got some developers doing really tiny implementations. They cut a lot of corners to do that, but talk to us and we can set you up with something that's appropriate. But the most full-featured, fully-tested code is the same code that's in Panther.

You know that's been run on millions of machines, so that is really the code that you have the most confidence in. Okay, so some other interesting sessions you might want to go to. The first one is already over, but you'll have it on your DVD, so you can review that if you want. We've got networking sessions and networking feedback tomorrow and Friday.

Craig is our developer relations guy. If you have any questions, contact him. For the specifications, zeroconf.org, multicastdns.org, dnssd.org, all have those drafts. They've just been updated last week, so they're up to date with all the latest stuff in Panther. We have Apple developer information. We also have the Apple Rendezvous mailing list, which is a great place to ask questions. So that's often a good place to ask your first question, instead of going straight to Craig with a question. Many times asking on the list will get you an answer.