Ladies and gentlemen, I introduce our first presenter, and that would be architect Dr. Stuart Chechire. Okay, I want to thank you all for coming. It's great to see such a full room on a Friday morning, last day of the conference. And I'd like to believe that it's because you're here to see me, but I know it's really because you've all experienced firsthand the frustration of trying to set up network devices.

And Apple's not the first company to realize the importance of this, but I believe we're the first company to succeed with a solution that really works. I'd like to start with a show of hands. How many people in the room now are IT administrators, network administrators? Okay. That's a good turnout.

So, I'm going to start with a few We have a lot of new stuff in Rendezvous this year. This has been the biggest year for Rendezvous, and we've got more stuff to announce this year than last year or the year before. So I'm going to get right into it. We've got so much new stuff, we should be calling it Rendezvous 2 or Super Rendezvous or something.

So there are three big areas where we've gone beyond Panther in three different dimensions. We've gone beyond the local LAN. In Jaguar and Panther, Rendezvous was focused at the area of IP networking that's least well served, which is a small network just plugging things together. But in Tiger, we now expand that beyond the local LAN using standard unicast queries and updates.

People have raised this criticism before, oh, Rendezvous is only for local networks. It doesn't scale to the enterprise. Well, we've left the enterprise behind. Because we're built on DNS, DNS is a worldwide database. It's the biggest distributed database in the world. And because of that, in Tiger, you can browse any domain that's advertising services anywhere on the planet from anywhere on the planet. So we now scale to the whole planet.

We go beyond the old Rendezvous in another very important way, which is while we always had the Darwin code, which ran on a variety of different platforms, it was a little bit inaccessible. What we have today, just announced this week, is a Rendezvous system service daemon running in the background, just like it does on OS X, running on Linux, FreeBSD, Solaris, other Unix systems, and of course, Windows. How many people in the audience develop for Windows? Nearly half.

Exactly as we expected. And the good news now, you can go to the Apple developer website and download our technology preview for Windows, run the installer, and you get the exact same DNS underscore SD dot H API that's provided on Panther, the same API that's provided on Linux and FreeBSD and Solaris and the Unix platforms.

So the same C code you write is now portable across all of those platforms. And the other way we go beyond the old Rendezvous is beyond C APIs. The current APIs are C header files. We now have a fully supported Java class library that provides you the full functionality.

We announced this at a talk at Java 1 this week and got a big enthusiastic reaction there as well. Java people have been waiting for this a long time. So you have the full suite of Rendezvous facilities available to you, but with object-oriented Java-style APIs. And the other area where we go beyond Rendezvous is not just Java, but we go beyond C2, C#, Visual Basic, all of the .NET languages on Windows as well. So you can now write Visual Basic programs using Rendezvous.

So an outline of what we're going to talk about today. I'm going to recap what Rendezvous is about, because most Mac users and developers know about it, but I want to make sure that we're not leaving anybody behind. We're going to talk about the wide area of service discovery and advertising. We're going to show you Rendezvous running on Windows and on the Unix platforms.

We're going to tell you about the Java APIs, and the APIs that we have in Panther proved to be very good. We didn't have any bugs or omissions to fix, but we have added a couple of new helper functions, which I'll tell you about. And you may have seen a setting up here. We just had a whole suitcase full of stuff. We had the Rendezvous plug fest at the Apple campus last night, and we told people that if they brought cool stuff, then we'd try to show it, and we got a whole suitcase of stuff.

So if it weren't for Rendezvous, it wouldn't be a Rendezvous. It would be insane to try to set up 20 different devices in 15 minutes to do a demo, but because of Rendezvous, we'll see if this works. And we hope to have time for Q&A at the end.

So, quick recap, what is Rendezvous? First and most important is it's a philosophy. It's an attitude, and it's the attitude that you should be able to just plug things in and have them work without fussing with addresses and subnet masks and nonsense configuration. And that's what's most important, and I always say that first, because people forget that. Rendezvous is not about technology.

Rendezvous is about the goal of making products that just work. If you think about plugging in a USB device, you don't have to type addresses to configure it, you just plug it in. And there's no reason Ethernet should be any different, or wireless. So that's the most important thing.

But there are underlying technologies that enable us to reach that vision, and those are addressing, naming, and discovery. Now, I'm not going to go into these in the same detail I have at previous talks, but just to recap, you're not going to do much IP addressing without an address. DHCP is great, but if there isn't a DHCP server on the network, all of these Rendezvous devices will pick their own address.

Second thing, having a bunch of random IP addresses is certainly a first step, but it's not sufficient, because if you don't know what all the IP addresses are, you're not a lot better off. So the second step is naming, and the normal usage model for Internet software is DNS hostnames. DNS is great if you have a DNS server, but if you don't, then we need a safety net.

And the safety net is multicast DNS, where you send a standard format DNS query, you multicast it to everybody on the local network, and each device has its little multicast DNS responder. And when it sees a query for its name, it says, "That's me," and it answers. So this doesn't replace or compete with global scale wide area DNS, but it's the safety net when you have just two devices and a cable, or three or four devices in a hub, and you don't have a DNS server setup.

And the third leg is discovery, because using host names is better than using addresses, but you still need to know what name to use. And discovery lets you browse the network, like the faithful old Apple talk chooser, and see what's out there and click on it without having to know in advance what the name is.

And why do you care as product developers? Well, you care because if the user can't use your product, then they're going to call you, they're going to run up support costs, and ultimately they may return it. I witnessed something at a startup a few years ago here in California, in Silicon Valley, at the heart of the computer industry. They bought a $1,500 high-end HP laser jet printer, double-sided stapling in the corners, very, very beautiful, fancy machine, plugged it into the network. Apple Talk auto-configured. The Mac users were printing on it right away. They could not get IP set up.

These were guys with masters and PhDs from Stanford doing a dot-com startup. They could not make it work. After two days, they put it back in the styrofoam, took it back to Fry's, and returned it. And that's just a tragic story, which is why today every major printer vendor has Rendezvous in their printers, because they don't want... They don't want the printers being returned.

But what is more exciting to me is not just taking the current stuff and making it easier, but the fact that when you don't have to configure it, entirely new product categories become possible. And that's where I think we're going to see a lot of the exciting things. You will all have seen the announcement for our Airport Express.

This has no screen, this has no keyboard, but it shows up in a pop-up menu in iTunes for you to play your music. That wouldn't be possible if you had to type in addresses and netmasks and things. This product wouldn't exist. So that's where I think we're going to see the excitement in the next couple of years.

So, to summarize, Rendezvous has grown both in breadth and in depth. It's grown in breadth in terms of reaching more platforms and more languages, and it's grown also in that it now scales beyond the local link. Geographically, it's grown to scale to the whole world. So, don't even try to read this.

I'm not here to talk to you today about UPnP, but whenever we meet with developers, it's a question that comes up, what about UPnP? And the UPnP forum loves to proclaim how many hundreds of companies they have signed up for their forum, but they only have one credible product today, after all those years of work, and I'm being generous by even calling it credible. That's the UPnP home gateway protocol, and it really doesn't even work very well, but that's the only thing that they can kind of point to as their success.

Well, never mind the forum and the hundreds of companies. We have hundreds of products. This is from the list of registered Rendezvous service types from the DNS service discovery website, and this is just the first page, and... It goes on, and I won't go page after page after page.

We're only on to the letter I here. We're only on the ninth letter of the alphabet. Every one of these registered services, this is not a product, this is a protocol. So for every one of these, there are one or more servers advertising that, there are one or more clients browsing for that. If it's a network game, it may be a server and a client from the same company. In the case of protocols like SSH, Telnet, FTP, there are of course dozens of servers and clients advertising that.

So we have this huge adoption, this quiet revolution going on that people almost aren't aware of, and daily this list of registered Rendezvous services gets longer and longer. So on that note, I'd like to invite Kiren Sekar up on stage to tell you all about Wide Area Rendezvous.

This doesn't use Rendezvous. Take for instance a network game. All of a sudden, you can collaborate with another game player across the internet with just a couple API calls. It's that easy. It provides a great user experience, and it's easy for you too, allowing you to focus on your core competencies, which is creating great applications, not messing around with this networking stuff. If you manage a network environment like in an enterprise, you might have found yourself choosing between a network that's easy for you to administer and a network that's easy for your users to interact with. And with Wide Area Rendezvous, you get both.

And of course, like Local Rendezvous has done, Wide Area Rendezvous will add a competitive advantage to your hardware products, making them better for your customers to interact with, and ultimately lowering your support costs. Now, as Stuart explained, when we set about solving the local problem, we focused on a few core pieces of functionality. And moving forward with Wide Area Rendezvous, we're doing the exact same thing.

First, we give every machine a dynamic DNS hostname. This is much like the link local name on local Rendezvous, but now the name is globally unique, meaning it can be looked up and accessed from anywhere. And this name is persistent, meaning as you move between your home and your cafe and your office, the name stays the same even as your IP address changes. This is the first big step towards reachability. This alone brings us so much functionality. But we go ahead and take it a step further.

First of all, we don't want to have to remember these names. And even more importantly, we want to learn about new machines that we didn't know about before, but they're providing some service that's of interest to us. So we take the DNS service discovery and registration that we have on the local network and publish this into a global namespace where these services can be accessed potentially from anywhere.

Now, it's easiest to explain the architecture to the solutions of this functionality in the framework of local Rendezvous that we all know. Local Rendezvous, of course, starts with DNS service discovery on the top. And that is the APIs that your applications use to browse and register for services. And of course, the resource record format, using standard DNS messages to encode information about your services. Now beneath this, we have multicast DNS, the serverless protocol for registering and querying for these DNS records on the local network.

With Wide Area Rendezvous, we simply slide out the multicast DNS layer and use unicast DNS, communicating directly with a DNS server. Now, in the difference between this architecture and our previous local architecture, what has stayed the same is just as important, if not more important, than what has changed, and that's DNS service discovery. This means that our APIs are 100% unchanged. The exact APIs that you've been using for the last two years will give you all of this new wide area functionality with little to no modification in your applications.

When we first did local Rendezvous, many people asked, why are we using the DNS message format? And back then we did have some good reasons. There were a wealth of debugging tools. Developers already knew the message format, just to name a few. But now is where we see the really big win. By making that decision for local Rendezvous, we're allowed to keep the same protocol and the same APIs, and instead communicate with these DNS servers that automatically know how to understand our messages.

We can look at some of the specific advantages of the DNS, both on the discovery using the DNS queries and the registration side using dynamic updates. Let's start by looking at registration, or pardon me, with discovery. To discover a service or to look up information about a service, we format a standard DNS query, like we would have done with local Rendezvous, and instead of sending it out on the network, we send it directly to our DNS server and get an answer. It's really that easy. But along with it being easy, we inherit this huge wealth of advantages that DNS has to offer. DNS has extensive caching, DNS is distributed in nature, and perhaps most importantly, DNS is ubiquitous. There are servers everywhere.

Now, getting the information off the server is pretty easy, but how do we get information to the server? How do we publish our services and register our name? After all, DNS was initially made for a relatively static data set. When it did change, it was usually an administrator actually typing in something in a text file. Fortunately, that problem has been solved for us as well with Dynamic DNS Update.

As you probably know, Dynamic Update allows a client to publish resource records into a server. And we use this to publish our globally unique address record. And this is one of the more conventional uses for Dynamic Update. In addition, we take our service records, the records like the pointer record, the text record, the SRV record, that convey information about the services that we're offering, and publish those into the DNS as well.

Now, we have this distributed system of databases just ready to accept our services. Which ones are we going to use? Well, if you manage an enterprise network, chances are you might set one up. And we've gone ahead and set one up too. And it turns out it's pretty big. That's right, .Mac now supports dynamic DNS.

This is included with the standard.mac service, and each user gets their own name, user.members.mac.com. Within this domain, they can publish the names of any number of machines that they own, and any number of services that they wish to advertise. This server was built from the ground up to support wide area Rendezvous, so the software is highly tuned, and unless you come from Virginia Tech, their rack of extras will make you drool.

But it turns out, if you're not supporting half a million users, you don't need anything like that. In fact, a standard DNS server will work just fine, and that's what we do with our Tiger server offering. We use bind9, the tried and tested DNS server, and include a UI that makes setting up wide area Rendezvous even easier.

Now, when we're registering into these servers and potentially across the internet with .Mac, this of course creates a whole new range of possibilities for the visibility of our services. With .Mac, services are truly globally visible. When you publish your name and your services, anyone on the internet can discover them.

You don't have to set your network up this way. If you are managing an enterprise network, you probably don't even want that. You probably want your services registered securely behind a firewall, and DNS offers us that kind of flexibility. Using techniques like split namespaces, you can do much as you do with your website, having your publicly visible website as well as an internal website that's only visible behind the firewall.

This brings us to another advantage of using the domain name system. Not only are there so many technical advantages, but we also get this wealth of administrative expertise. There are already thousands of people, many of them are in this room, who know how to set up a DNS server. And guess what? Now you're also a wide area Rendezvous administrative expert.

If you're an administrator deciding how you're going to set up your wide area Rendezvous network, or you're an application developer planning to publish your services into the dot max system, it's worth thinking a bit about what kind of visibility you want and what this visibility means for you.

Well, let's take the extreme example, the .Mac example. When you publish your services, anyone can find them from anywhere, but that's where it stops, at discovery. Once someone discovers the service, they'll have to connect to your service, and it's up to you to have the kind of access control and security that's appropriate for your application.

So what's the message? Secure your apps. But as it turns out, this discovery mechanism doesn't actually introduce any new vulnerabilities. If a hacker wants to, if you're providing a service, they could find you even without this kind of discovery. What this does is it just makes it easier for those with legitimate reasons to find your services and be able to interact with them.

Now, one area that's particularly challenging in terms of visibility is networks that are behind NAT gateways. As you might know, a NAT allows a single public IP address to be shared amongst a number of private addresses. For example, an airport base station plugged into a DSL line often acts as a NAT.

Now, the NAT detects outbound connections, say one of the machines talking to a web server, and it'll change the addresses in the packets to make them look right, and it'll remember this outbound request, so when a reply comes, it'll know which machine behind the gateway to send it to. Unfortunately, there's no way for the NAT to know when a machine behind it is actually providing a service, and there's no way for machines outside of the gateway to connect to these machines with their private addresses.

Now, the reality of networking today is that machines are more and more finding themselves behind these NAT gateways, and it's simply not acceptable to force them into this cloud of isolation if they're in this kind of a network configuration. That's why we've created a NAT traversal protocol. It's a very simple protocol that allows a machine behind a NAT gateway to learn its public IP address and to request a public port that... It can then maintain with a lease life and a refresh, much like DHCP. And this effectively allows machines behind the NAT gateway to be able to accept connections, incoming connections, from outside of that gateway. Thank you.

I'm glad to hear that you're all enthusiastic about this. And of course, following in the Rendezvous tradition, this is an open specification, which is now available in a preliminary form on our websites. And if you're interested in using this in your products, by all means, come talk to us. Now, this protocol is highly complementary to Wide Area Rendezvous, but it turns out that the Rendezvous stack is also the ideal place to implement it.

In Wide Area Rendezvous, we use the protocol to find what our public IP address is, so that when we register our names in the DNS, we're registering a public address that can be reached from anywhere. When an application registers a service using our service registration APIs, we'll go ahead and take care of the NAT mapping for them. We'll maintain the leases and the refreshes, and all of this is completely hidden from the client. You don't even have to worry about it.

Now if for some reason you don't want this, if you don't want a port map for you, just register your service in the local domain only, and we won't do any kind of wide area registration for you, we won't create any NAT mappings for you, but your service will continue to work on the local network.

Now, this protocol gives us huge flexibility in terms of the range of visibility. And all of a sudden, we can have a person registering a service on one side of the globe and someone discovering it on the other. And as this physical distance increases, we clearly need some kind of authentication mechanism for publishing our services.

Take, for instance, the .max service. If we had this without any kind of authentication, someone could register something, say a photo share, in my domain. Other people will discover it, think it's mine, and when they resolve it, they will actually get directed to this imposter's machine. And who knows, we might end up finding pictures that I just don't want my grandmother to see.

Fortunately, DNS standards provide us with an easy solution for this. We use the Transaction Signature Resource Record, also known as a T-SIG. And what this is, is a cryptographic hash of the dynamic update, which includes all of the messages, pardon me, all of the records and the services that we'll be publishing, as well as a shared secret known by my machine and the server. And this effectively allows the server to determine that I do, in fact, have the authorization to publish the data. publish records in a given domain.

Now, all of this is available with Wide Area Rendezvous, and in the .Mac case, it just works seamlessly. But it's not required as part of the protocol. If you're setting an open network that's behind a firewall with a relatively small number of users, you might decide that you don't even need authentication. You got by with AppleTalk for years without it, and you trust your employees. You don't have to have it. You have that kind of flexibility. Now, looking at all these different pieces, the authentication, the NAT traversal, the dynamic updates, the queries, we get a more detailed architecture.

of the Wide Area Rendezvous system. And what this really is, is A novel combination of existing technologies in a way that provides a very valuable and powerful experience. But if you look at this long enough, and believe me we did, eventually you'll find some holes. Let's look under the discovery side.

With local Rendezvous, we have this notion of a long-lived query. When we start a browse, say in iChat, you get all the answers that are available on the network, and your list immediately populates. But this browse, this query, maintains for the length of time you have that window open. So as new services become available, or old services go away, your list is updated. So, the Rendezvous is live, it's snappy, and it provides that great experience that we all like. Unfortunately, there's no equivalent with unicast DNS.

We have a couple options here. We could deal with stale data, we could maybe add a refresh button to your application, and if you've ever heard Stuart talk before, you know you're more likely to see a pig fly out of your PowerBook. Or we could pull the server very rapidly and find out about changes that way.

Now, that would make us fall back into the chattiness that plagued AppleTalk, and it would completely preclude this kind of scalability that we need for a half a million users in .Mac. So it looks like the DNS standards got us pretty close, but they stopped a little bit short of giving us the solution that we need.

As it turns out, DNS actually comes through by offering its own extension mechanism. This is called EDNS0, and it's a standard way of enhancing the DNS protocol to provide new functionality as it becomes necessary. We use this extension mechanism to create long-lived queries. This is a special kind of query where we ask the server to give us all of the answers that it knows, and then to continue to tell us as new answers become available, or answers that it previously gave us become invalid. This provides the same kind of browsing experience that we have on the local network, while still being high performance and highly scalable. Similarly, on the registration side, we've got a piece missing under dynamic update.

With Dynamic Update, we publish a resource record into the database, and it stays there until we deregister it. Which works fine some of the time, but imagine I plug my laptop into the Ethernet jack, and I register a bunch of services, and then I unplug the cable. Well, guess what? Those services stay up there on the DNS, even though my machine is no longer reachable, and they'll stay there indefinitely.

For this problem, we end up with the same stale data problem, and we address this too with the EDNS0 extension mechanism. We add a lease life to resource records so that we tell the server to publish them and hold them for a certain amount of time, which we can periodically refresh if we need to.

And then if the machine becomes disconnected from the network or the power goes out or what have you, before too long the server will realize that the machine isn't there anymore, the lease has expired, and it will actually go ahead and remove those records from its database. Now, these extensions are done with DNS's native extension mechanism, but they clearly require some kind of modification to the server. And there are a couple ways we can make this happen.

In the .max servers, because they were designed specifically for wide area Rendezvous, these extensions are supported natively. It can do long-lived queries and it can handle lease lives just like it can standard queries and standard dynamic updates. But we design these extensions so that they can also be implemented as a side process running next to a stock unmodified name server.

This is what we do with our Tiger offering. We use bind9, which is tried and tested and it works great. And next to it, we will have a process that understands the long-lived queries, understands the lease lives, and essentially acts as a broker between the clients and the servers. And specifications, preliminary specifications for these extensions are posted on the website, and you're welcome to take a look at them and implement them in your servers if you so choose.

Looking at implementation, it's worth taking a look at what kind of application implementation and what kind of application changes need to be made to take advantage of this. In our discovery APIs, you might have wondered why we have this domain parameter. After all, it's always just been local. Well, now you see why.

In fact, we've encouraged you as developers to not explicitly specify a domain when you make your registration calls and when you make your browse calls. Just pass the empty string and let us pick something for you. And up until now, that's always just been local. But now that we have this new capability, we can make intelligent choices for you about where to browse and where to publish services. For example, a default browser registration call might take place both on the local network and in a user's .mac domain. Now, of course, if you have explicit needs, by all means, pass an explicit domain.

If your service really only makes sense in the context of the local network, then just pass local. Likewise, if you want to be looking in a specific .mac member's domain, perhaps for some kind of a collaborative application or a game, then just pass that domain. that member's domain.

If you want to, we have calls that will provide a list of available domains that you can browse and register in, and you can actually let your client pick one in a graphical user interface. These enumeration calls have been around all the time, and up until now they've only returned local, but now they'll return local as well as one or more .mac domains, and possibly even other domains that we learn about from our network environment. Enough of hearing me talk, let's take a look at how some real applications use this stuff. Can we go to the demo, please? Are we-- demo three? Thank you. Here we have a tiger machine.

Here we have a Tiger machine. And as you can see, I'm in the .mac prefs pane, and there's this new tab called Domains. This allows us to turn on the .mac DNS service. I've checked it on here and you can see the name of my computer: portable.kiren.members.mac.com. kiren.members.mac.com is my personal domain where I can register in, and portable is the name of this machine that I've set in our sharing prefs pane. Now this is a standard DNS name, you can use it in the connect to dialog, you can use it in the terminal, anything that takes a DNS name.

We can also use Rendezvous for browsing, of course. We don't have to use this name explicitly. We can take a look at Safari in the Rendezvous tab, and sure enough, I'm actually not seeing anything, I'm not seeing any Rendezvous shares here. Let's see if we can't figure out why that's happening.

I have a machine at home and I want to be able to see its website and I thought it was publishing into .Mac and I know I have Apple Remote Desktop turned on there. So let's see if I can't actually get into it and see what's happening. Now, here too I could enter the name of my home machine, but I don't have to.

Here we have an unmodified application, Apple Remote Desktop, that does Rendezvous browsing and doesn't specify an explicit domain. So the system goes ahead and publishes both locally and in my .map domain. And here we can see my desktop machine with its IP address here, which is not on our local network. And I can go ahead and add it. And here we see the difference between discovery and actual access. Anyone can discover that I have Apple Remote Desktop, but you still need the correct authorization to access the machine. And now I can connect to it.

Here too we can see that I have .mac turned on, .mac domains turned on, and that's why I was able to see it from here in the conference room. And you can see its name, desktop, in my same personal domain. Now, let's take a look at why web sharing wasn't working.

Well, that would explain it. It's not turned on. So we can look back in our Safari browser here, and Safari has a long-lived query established with the server, which means that it's asked for all the answers, and in fact there weren't any, but the server will continue to tell it as new answers come about. So, if I go ahead and turn on web sharing here, it'll fire up Apache, register my services both on my local network at home and in my .Mac domain. Go ahead and turn it on. It takes a few seconds for Safari to launch, and there it is.

It's amazing to think about how many things have to happen there. The registration has to send the records to the DNS server. The DNS has to notice this change and send the notification to my machine here. And it's still just as snappy as it is on the local network. You can see it disappear and reappear. It actually takes longer for Apache to fire up than it does for the registration to take place.

And we can go ahead and double click on it and resolve the service to the IP address and the port of my machine back home. And there you can see the web page that's running on my desktop computer. Now, I like this WIP web page and I think I'm actually going to print out a copy.

Let's see. I don't see any printers here on the network. Let's see if I can add one. Go ahead and add. Oh, what's that? Because the printer sharing is also doing the same default browsers and registrations, it's able to look in my .mac domain and see this printer that's registered at home and actually go ahead and print to it.

So, can we go back to the slides, please? Seeing this work in real applications allows us to look at this architecture and say that it really is a solid architecture that makes great use of existing technologies and provides a really powerful technology for all of you guys to leverage.

At the end of the day, most of the stuff is really just implementation details. What this is, is really fundamentally DNS service discovery. It's the message format that we've had before. It's the same APIs that you guys already have in your applications. And most importantly, it's the same user experience that all of us and all of our customers have come to love. I'm really excited about this technology and I'm even more excited to see what you guys do with it. But this is really just a part of what's new in Rendezvous for Tiger. So with that, I'd like to turn it back to Stuart Cheishir.

Thank you Kiren. So, next big announcement, which I think will make a lot of people very happy, is Rendezvous on Windows. So what's there? We have a system service daemon running in the background, just like on OS X. We have a client DLL that clients link with in order to communicate with that daemon, and we have Java support as well for Java clients.

In the developer preview that we have on the developer.apple.com web page, we have a couple of sample clients to illustrate how you can use this. One is a plugin for Internet Explorer that gives you a Rendezvous icon in the toolbar, very much like in Safari where you can browse to find Rendezvous services.

We also have a printer setup wizard to illustrate how you can find printers and set them up effortlessly in Windows. But of course the big news here is we have the header file and the stub library for all you developers to link with your applications, so you can advertise services and add Rendezvous menus and Rendezvous browsers in your application software.

You can get it today from the developers.apple.com website in macos10/rendezvous. And if you'd like to license this installer, like maybe the way some of you license the QuickTime for Windows installer, then send us an email and let us know. So now I'm going to show you a quick demo.

And we will need-- We need this demo machine, the VGA connection, please. All right. Let's run Internet Explorer and see what we see. Oh, that was quick. We have... We have one of these Axis cameras on the network. This runs Linux. Axis is the world's leading maker of network cameras, and they've now decided to adopt Rendezvous.

We have one of Axis's print servers here, plugs in the parallel port, turns your printer into a network printer. What else? We have this little printer thing from Intercon. Let's try connecting to that. And a lot of these devices in the past would have had a serial port that you plug a terminal into and you configure it in a VT100 terminal, and that's very '70s.

But the serial port and the VT100 terminal was kind of the universal user interface of the 1970s. And the universal user interface of this decade is the web browser. So a lot of these devices that don't have any screen or keyboard are configured through the web browser, which is great if you can find it. And of course, Rendezvous gives you the answer, so we can find all of these things and they show up just like they do in Safari.

But the thing that I'm sure you'll all want to see if you've ever tried to use a network printer is this. So let's see what we have on the network. We'll click Next. There's an HP LaserJet somewhere in this building, not mine. But we have the SEH Intercom print server plugged into this old Epson printer here.

and it recognizes that it's a Stylus Color 740, and now we're ready to set up a printer. I actually wanted them not to have all these next and back buttons. I just want one button here that says, "I'm feeling lucky." So that was it. Effortless setting up of Windows printing. So on that note, let's go back to the slides, please.

So as well as Windows, we also have support for the Unix platforms, for Linux, FreeBSD, Solaris. Same story. There's a background daemon, there are system scripts to start it up at boot time, there's a shared library for clients to link to, and there's the same header file as Mac and Windows, and there's the same Java support, so the same Java applications will run unchanged.

We don't have an installer on the website, but that's available in Darwin, and if you check out the top-of-tree Darwin code and run make install in the POSIX folder, it will install those five or six files where they need to go. So let me show you a quick demo of that. Let's go back to the VGA feed, please.

So if you've looked in the Darwin project in the clients folder, we have a sample command line client to exercise all of the DNS, SD, APIs. You can browse, you can register, you can resolve. It's about 400 lines of C, and it's a big switch statement that does all the different calls. So if you're using Rendezvous, then that's a good place to start, to just copy and paste the little chunk of code that you need. And of course, it compiles and runs on Linux just the same. And I'm going to show just a simple, let's browse for HTTP.

Any advertised HTTP servers, and then we see the same things that showed up in Explorer and in Safari. And if we look for things that are offering IPP printing service, we will see those two show up. So, the same APIs there, and we're really excited talking to the people who make web browsers and other software that runs on Linux to start adding these calls into their applications so that they can have Rendezvous menus as well. Okay, back to the slides. And with that, I would like to invite Roger Panthos to come up on stage and tell you all about using Rendezvous from Java.

Thank you, Stuart. So my name is Roger Panthos, and I work with Stuart and Kiren at Apple on Rendezvous. And what I'd like to do today is spend about 10 minutes telling you about the Rendezvous interface that we've built for Java. So from the point of view of a Java applications programmer, the most interesting, kind of the most fun thing to do is service discovery.

And so that's what the work we've done kind of centers on. What it consists of is a new API, a new set of classes for Java that gives you access to the complete set of service discovery facilities that Rendezvous offers. What that gives you is complete access to the entire service discovery system.

And that's linked to the system implementation of Rendezvous, which means this is a system-level implementation. This is not running in your Java program as in previous zero-conf implementations. So it means you get the benefit of the system-wide resource record caching. It means you get the performance that every other client gets. It means you get the benefit of all the additional work we've done in our reference server on things like duplicate suppression, the efficiency, and all the bug fixes we've made to MDNS.

Now, the Java support is also built in to our reference implementation. When you build it on Windows or on Mac OS X or on Linux or on FreeBSD, you get the Java support as well. And when we deliver Rendezvous on a platform, we deliver the Java support. And so our intent is that if you have Rendezvous on your platform at all, and you have a Java VM, then a Java application can run on your platform and it can use the Rendezvous APIs. So let's talk about the Rendezvous APIs a little more closely.

So the first thing that my little Browse for Printers does is it sends a message to my factory class, DNSSD, sends it a browse message, and it's sending it _IPP, look for printers. It's also passing it a reference to itself, because it implements the browse listener interface.

One of the methods that the BrowseListener interface defines is service found. You can see what's going to happen here is it's going to ask Rendezvous to go find all the printers. Rendezvous will do that, and then it's going to call this implementation back with the results. In this case, all it's doing is printing out the results it finds in the console. But that, in a nutshell, is Rendezvous programming in Java. This is browsing. Once we find something, we want to register it, or rather we want to resolve it.

And so resolution is the same kind of deal. We've got an interface, which is a resolved listener. It defines a callback, which is service resolved. And so you send a message to the DNSSD, and it gets resolved. Registering service, again, very similar. You send the DNSSD a register message, I guess, with it saying, "Hey, I want to register a website that's called me.

It's an HTTP thing. We're going to pass it to this reference." We implement the register listener callback, and we get called back once the registration is complete. So we could spend some more time talking about the API, but I thought it might be cool to have a demo. So let's go over to demo two here on screen. And here it is. We can, let's hide this guy.

Not yet, but pretty soon. Okay, so I guess when you're bringing up a Rendezvous on a new platform for the first time, it's kind of traditional to create a browser. And you can see Stuart, we've got the browser from Cocoa here. I wrote a little browser in Java as well. And so here's my Java app. It's a couple of pages of swing code. And you can see it's looking in the, I just lost my mouse. I Maybe we're... There we go.

Okay, we're good. So it's looking in the local domain here, and it's found a number of different services that are being advertised. So you can see we've got a Java application here. It's using Rendezvous. It's finding all kinds of different services. So that's kind of interesting. But then we decided to have a little more fun.

And so what I built was kind of the world's simplest peer-to-peer chat program. That's called Simple Chat. And so I'm going to run it here. And what you can see is going on is that we've got this pop-up menu here. And right now, it only sees a single thing, which is itself.

But if I could get Stuart to double-click on the Windows machine here, I'm going to... We've got a whole bunch of machines up here. But if we can get Stuart to run Simple Chat on Windows, Stuart is actually... His name is also Tim. It's kind of his nickname. And so he's typing away in there, and... We borrowed Tim's PC, and I can send him a message in theory.

And if we want to switch over to the VGA feed for a second on demo three, we can see it running on-- on Linux machine. And we can see it running under Windows, I hope. There it is. So, that's So if we could switch back to demo two just for one more second.

Simple Chat is actually, it's really small. It's only like four pages of code. But it's nice in that it illustrates three major aspects of using Rendezvous. First of all, registration. When you run simple text, it registers itself on a network as an instance of simple, I think, underscore P2P chat.

The next thing it does is it wants to populate this menu of things it can talk to. And so it browses for instances of P2P chat, finds itself in a bunch of other things. And then third, when you actually select something from that pop-up menu, then we resolve the service. We discover the host you're running on, discover the port you're running on, and from there on in, we just send UDP packets back and forth.

Now, just as with every other Rendezvous browser, this is live. And so as you can see, I've got Tim up there in the pop-up menu. What I'm going to ask Stuart is, is quit Simple Chat on his machine, and you'll see Tim disappears, and it goes back to Apple. So of course, it's live, just like any other Rendezvous service. So.

The next step is for you folks to start playing with this stuff. If we could go back to the slides, please. How are we going to do that? Well, first order of business is documentation. Documentation, of course, is in Javadoc format. It is provided on the TigerSeed, so if you've installed the TigerSeed, you already have it on your disk.

In addition, for those who are not running Tiger, or perhaps running Darwin, using Darwin on Linux, or perhaps on Windows, we actually provide the Javadoc as a makefile target, and so you can generate the Javadoc yourself. And of course, as a last resort, we also have a mailing list, and so it's rendezvousatlist.apple.com.

If you just go to list.apple.com, you can find that mailing list. I know many of you are already signed up to that. So that's how to find out how to use it. Some of you are probably wondering how you actually get it, or maybe more to the point, how your customers get it. So let's talk about delivery.

So at the basic level, the Java support, as an additional piece to Rendezvous, consists of two files. One is a jar file, which contains the Java classes, the implementation of our interface. And that jar file is platform independent. It's the same on all platforms. The next part we have is a JNI library, a Java Native Interface Library.

And that is designed to adapt the platform independent Java classes to the specific instance of the DNS SD DLL that you're running on on whichever platform. And our intent is to deliver both of these onto the machine when you install Rendezvous. And so this, for most of you, should be a detail.

The other thing is we are shipping with Tiger, and as Stuart said, we are also shipping it with Windows. And so our intent is that when we deliver Rendezvous to customers in binary form, that the Java libraries will be there and you'll be able to depend on them. So that, in a nutshell, is the Java APIs. I hope that you try them out, you send us feedback, and you build some great stuff with them. Thank you very much.

Thank you, Roger. We're getting close to the end. Time to wrap up. We have really no changes to the main APIs. The only new ones we have I want to tell you about quickly now. When you advertise a service, you can attach name value pairs to that service, and when you resolve, you retrieve those name value pairs. And those can be useful to store various attributes that describe the service. Particularly with printers, they store attributes like the version of PostScript and things like that that the client might want to know.

Those text records have to be formatted as standard DNS text records, and that's not difficult. It's length, byte, and data, but we just made some helper functions. So now when you advertise a service, you create an empty text record, you do set value, set value, set value, and then you pass that text record you've created to the standard DNS service register call. When you resolve, and when you receive a text record off the wire, we have a couple of functions to tell whether a certain key is present. And to get the value for a given named key. Those are the only new APIs we have to add.

At the higher levels that build on top of the DNS SD.h API core foundation, they have some minor changes which they talked about at their session on Tuesday. And I would like to go back to the Podium demo machine, not the VGA, the Mac you have here. And I am... In the few minutes we have remaining, I told people if they brought things to the Plugfest last night, we'd try to show them on stage, and we got a lot more things than we expected.

This is a music device from Roku. Really nice. I'm going to buy one of these with my own money when they start shipping them. Really nice, bright, fluorescent display on it. Control it with a remote control, play your iTunes music. But that's not what I'm going to show you today. I'm not going to show you music playing.

What I'm going to show you is what they used in development, which is If you go to the Connect to Server menu in Terminal and select Telnet, you see the sound bridge shows up because for development purposes they have a Telnet interface to it, and you So same kind of problem, how do you configure this thing? Well, now it just shows up in the Connect to Server menu in Terminal. I said that the serial port was the user interface of the 70s, and the web browser was the user interface of the 90s.

Something I think is a very interesting direction that the world is going is a network protocol called VNC, for virtual network computing. It's a way of seeing the screen of a remote machine. And this little box here is some rack mount equipment for music studios to mix music. And inside it's a PC, it's got a VGA port on the back so you can hook up a keyboard and a monitor, but you really don't want to be sitting cross-legged on the floor with a monitor on your lap plugged into this thing in the rack.

So it would be much nicer if you could access this over the network. Well, it runs a VNC client, which is nice, but how do you know what IP address it has? Well, the answer is... I don't really care what IP address it has, because it does Rendezvous. And we just select that, and it finds the address.

This is a beta unit, so sometimes the display doesn't show up. The other thing I found that was very interesting is There are lots of other things on this network advertising Rendezvous VNC that I didn't even know about. So, don't know what that's about, but I think Building a user interface in a web browser for configuring a device is something that's very easy to do, but sometimes a web interface doesn't give you everything you want, whereas VNC lets you push the pixels you want.

So I think Rendezvous-advertised VNC is going to be an interesting direction for future interfaces for network devices. So on that note, let's go back to the slides, and we will wrap up. For more information, Craig Keithley is our developer relations evangelist. He's the man to go to with all of your questions.

If you've got technical developer questions about making things work or design questions or hints, the Rendezvous mailing list is a great resource. Not just Apple people, but hundreds of other third party developers are on that list, and it's a great community for people working together to solve their problems. Of course, one of the big benefits of Rendezvous is when multiple people do things that interoperate.

So, being the only VNC client that advertises with Rendezvous is less useful than having all VNC clients and servers advertise the same service type with Rendezvous. So, community communication is very important. On the Tiger CD you have this documentation, and if you go to the ADC home reference library page, then you can click around the links. There's a lot of sample code and documentation there as well.

Quick run through the URLs. Zeroconf.org is the umbrella website for the zero configuration networking efforts. It builds on multicast DNS and DNS service discovery as two of the enabling technologies. Of course, we have the Apple developer pages that also have links to these sites at developer.apple.com. The mailing list I already mentioned, very important. And if you're not tired of hearing me talk yet, you can come back at the end of this month. I'll be giving a Rendezvous tutorial focusing on cross-platform Rendezvous at the O'Reilly Open Source Convention in Portland, Oregon at the end of this month.