Tip:
Highlight text to annotate it
X
ANNA: --this tech talk.
This is Stuart Cheshire.
He got his undergraduate degree at Cambridge, and then
we were inflicted with him at Stanford.
And then he's head networking at Apple, and he invented zero
configuration networking.
And of course, the marketing people had to
change the name twice.
STUART CHESHIRE: I'd like to start off by asking for quick
show of hands.
Who here has heard me give presentations about Bonjour or
zeroconf before?
OK.
Just two or three.
That's good.
So I won't be boring too many people, then.
I want to remind everybody here that this is the first of
the Google Tech Talks that is going to be recorded and
published on Google Video on the public internet.
So you're free to ask any questions you like, but don't
ask any questions that relate to proprietary, secret Google
projects that you don't want the public know about yet.
So I'm Stuart Cheshire, as Anna said.
And zero configuration networking is something I've
been working on for almost 10 years now, really as a result
of the frustration I had with networking devices, computing
devices, that were just too hard to use.
And it wasn't such a hard problem to solve.
I just got tired of waiting for somebody else to do it and
decided I was going to have to do it myself.
I want to thank Tim O'Reilly, who's been huge supporter of
this, and recognized the potential here, and I
persuaded me to write a book about it, which is coming out
next month.
It's already appearing on Amazon.
We don't have a cover picture yet, so we know what the
animal's going to be.
I mention that because it's the question
everybody always asks me.
No, I don't know what the animal is yet.
[LAUGHTER]
STUART CHESHIRE: But he's been a huge supporter and has done
a lot of work evangelizing this.
So the goal here is that I want networked devices to be
like buying a table lamp.
You plug it in, you turn it on, it works, right?
Nobody ever has a table lamp that doesn't work because they
didn't configure the subnet mask correctly.
It's just insanity.
And AppleTalk did this 20 years ago.
So we know it's technically possible.
It's just that the IP community didn't care about
ease of use like that.
I mean, to be honest, if you were running a Unix machine 10
years ago, you had bigger problems than worrying whether
you got your subnet mask right.
There were harder things to configure than that.
So what do we mean by zeroconf?
What I'm going to be talking about today I expect right
now, immediately, will be of sort of academic interest to
this crowd.
I expect most of you are here out of curiosity.
Because what Google does today, with Gmail and Froogle
and web search, is very resolutely at the grand scale
of networking, of big data centers and global scale
networking.
And I really inhabit the complete opposite end of the
spectrum, where it's literally as simple as two laptops
plugged together with an ethernet cable and they want
to communicate.
The wide area networking right now, with the excitement about
the web, I think is being served pretty well, but it's
the local area stuff that's being badly neglected.
So we're interested in a couple of laptops.
Maybe an ethernet hub and a printer.
Maybe some wireless networking.
And of course, we'd like to scale this
up as far as practical.
But we're not trying to compete with today's managed
infrastructure networks.
Because when you get to a network of a hundred machines
or a thousand machines, you start to need some kind of
policy and management, and we're not trying to
compete with that.
The kind of things we're aiming at--
and I've brought some demo gear along here.
One of the fun things about this is that whenever
companies make zeroconf products, quite often they
give me one for the testing and we do a bit of debugging,
and then I end up putting it in my demo bag for afterwards.
And everything here except one is actually
not an Apple product.
Which is the other thing that makes me really excited is we
could do Apple Talk all over again at Apple, and nobody
would really care.
But getting the message out to the broader community is
what's important.
So a lot of these things are low cost, very limited memory,
slow processors, and that means we
need a simple solution.
And many people have recognized the difficulty of
ease of use in IP networking, but the problem is they
couldn't rein in their ambition to throw in every
feature they could think of, and you ended up with
something that was unimplementable.
I mean, sure you could implement on a desktop PC with
a gigabyte of RAM and a gigahertz processor, but in
simpler devices, even if you could make the code fit, the
complexity of debugging it just turns out to crush this.
When you're building a network protocol, the way to succeed
is just uncompromising simplicity.
Because if you're going to have an ecosystem of thousands
of devices, the opportunities for mistakes and
incompatibilities just mushroom.
So you have to start off with something that's absolutely
simple if you hope to succeed and solve that problem.
This is a design principle I learned at IETF meetings, that
a protocol is complete not when there's nothing left to
add, but when there's nothing left to remove.
And that quote predates network by a long time.
That's a quote from a Frenchman, I think, called
Saint-Exupery, and it was a quote about aircraft design.
And you'll see that in an aircraft, it definitely makes
sense, that it's complete when you can't think of anything
else to remove.
One question that I still have to ask after nearly 10 years--
or the question I have to answer- is why IP?
And I've laid out a goal right now of what we want to do in
terms of ease of use, and there are many ways we could
solve that.
And the way that I believe is the right way is IP.
So if we look back 20 years in the history of wide area
networking--
and most people in this room are probably too young to even
remember this-- there were many, many competing standards
for wide area networking.
And the good news is they all died and they're all obsolete,
largely forgotten, and TCP/IP has one.
In the same area 20 years ago, you look at what you had on
your personal computer.
You had all these different connectors.
And the good news is that those all have died and faded
into obsolescence.
But the problem today is you look at the back of your
computer now, and it's still bristling with all these
incompatible connectors and communication technologies,
all for local area communication.
And what are we, as a networking community, as an
engineering community, doing about this problem?
We're making even more different, incompatible ways
of connecting things.
So my belief is that in the wide area, we can all see the
benefits now of adopting a single standard technology
that everybody supports, and the benefits of doing that in
the local area should be clear.
And I'll take a step even further and say the local area
protocol should actually be the same one that we've
adopted for the wide area.
And some people in this room are probably
thinking he's crazy.
That's stupid.
Why would you want to be setting up all that
configuration?
And the little thought experiment here is, well, if
we could make IP so it didn't need configuration, maybe it
could do the job that we do today with things like USB.
So what do we need to do to do easy networking with IP?
Well, all of this is very straightforward and very
obvious, and if you walk out of this talk today saying,
none of that was very clever, that was really obvious, then
you've got the point.
Because that really is the message I want to get across.
It really is straightforward and obvious.
So to do IP networking, you need an IP address.
You're not going to do much networking
until you have an address.
So that's the first problem to solve.
Once you have an address, you can communicate, but human
beings don't really want to be typing in numbers.
So we want naming.
And the third thing we want is the ability to browse the
network and discover what's there.
And traditionally, today on an IP network, we don't have very
good browsing.
But Apple Talk did, and we want to get back to that level
of ease of use that we had on small
networks with Apple Talk.
So, very simple solution, here, because we want the
simplest, most reliable, most easy to implement solutions.
And again, a lot of the inspiration comes from the way
Apple Talk used to work.
Pick a random address, send an ARP request, if nobody answers
that request, then you say, hey, no one's using this
address, it's mine.
That's how you allocate self-assigned, link local
addresses in IP.
After many years of the wrangling and debate in the
IETF, we published the RFC for that this year, so that's now
an IETF standard, and it's very straightforward.
These addresses are only good on the local link.
Nobody on the other side of the planet can use that to
talk to you.
But if all you need to do is print a document from here to
there, an address on the local link may be perfectly adequate
for what you need.
This first showed up in Windows 98 and Mac OS 8.5, so
this has been around for five years now, and people are
probably familiar with these 169.254 addresses.
And normally when people see them, they curse and kick the
computer, because the network's broken.
And it's understandable why people would think that,
because you're kind of seeing one leg of a
three legged stool.
And until the other two legs are in place, having the
random IP address doesn't seem to buy you very much.
IPv6 already has link local addressing.
What we're doing here is not competing with IPv6.
We fully support IPv6, but we also recognize that many of
today's devices still only do IPv4.
Macs do v6.
Linux does v6.
Even Windows does v6 now.
But many of the lower cost devices that we want to be
able to communicate with don't.
So now we've got a bunch of random addresses.
So in principle, the devices can communicate.
But you don't want to be shouting IP addresses across
the room and typing them in.
So we want naming.
Now, we're following the same principle before of
simplicity.
Just as before, we wanted the simplest way to get an IP
address when we didn't have a DHCP server, we're now looking
for the simplest way to do naming when we don't have a
DNS server.
So we use the same DNS query syntax, the same packet
format, the same naming and record types, but we multicast
it to every machine on the local link, and each device
runs a little responder that's listening for those requests.
And when it sees a DNS query for its name, it says, hey,
that's me, and it gives a standard DNS response.
And from the point of view of a DNS client, a resolver
client, it barely has to know what's even gone on here.
Because it sent its DNS query to this address--
22400251--
which happens to be a multicast address, but the DNS
client doesn't really need to understand what that means.
And then you get a response coming back which has the
answer that you're looking for.
So it looks very much like a normal DNS query, but without
the server on the network.
Now there are some rules that have to be followed, here.
The devices have to cooperate with each other.
If they both want the same name, then they both can't
have it and there's some conflict resolution
that goes on there.
But from the point of view of the querier, it's more or less
a standard query.
And that gives you, now, the ability to use conventional
style host names in your web browser, on the command line.
You can SSH to my computer.local.
And all of those places that you would normally use host
names today, you can now use .local host names.
And just like with the link local addressing, we carved
off a chunk of the IP address space and said anything
starting 169.254 is defined to be link local scope only with
no global significance.
We did the conceptually similar thing with the DNS
name space, where we carved off a subtree of the DNS name
space and said that anything that falls under .local is by
definition local significance only.
And the upside of that is that anybody can use
one of these names.
You don't have to pay $35 a year or
register it with anybody.
The downside is that privilege that you have is also afforded
to everybody else, as well.
So you trade off the central authority and the money for
the requirement to at least collaborate and cooperate with
the peers around you and not be hostile.
In a hostile environment, this is not the
solution you'd want.
Multicast DNS showed up in Mac OS 9.2, in Mac OS 10.
NICTA, a research organization in Australia, wrote the
version for Linux as an NS switch plugin.
And in Bonjour for Windows from Apple, we have a name
service provider plugin that implements .local
name look up as well.
So that's good.
We've got back to, sort of, feature parity with what
people expect of internet networking, which is IP
addresses, names that you type in.
But you have to know the name, and you have to type it
correctly, and if you mis-type it, it doesn't work and nobody
really tells you why or suggests what
you should have done.
So what we want to do is even go beyond that, to just browse
and discover what's on the network without having to know
in advance.
And I'm not claiming that we're the first people to
think of this.
The list of attempts to do discovery protocols over IP
just goes on.
I think every permutation of resource and service and
discovery and location, in all possible
orders, has been used.
And when they ran out of those acronyms, they
made up other ones.
And why did they fail?
Well, I think they all couldn't resist the urge to
keep making things more complicated.
And when you're building one client and one server, you can
put them on a test network and test them and debug them.
But when you're developing a standard that's going to be
used by thousands of devices--
many of which will never appear on the same network
until that happens in some customer's home--
the matrix for exhaustive testing of all combinations
becomes impossible.
And if you can't do exhaustive testing, your only assurance
that it's going to work is to keep the protocol so simple
that there's almost no way to make it go wrong.
And there's always ways to make things go wrong, but you
have to ruthlessly eliminate every possible opportunity for
things to be misinterpreted or implemented differently.
And it's a bit sad, because we're not inventing this for
the first time.
We actually have Apple Talk to copy, that sets an example of
how this can be done.
So I don't want to dwell too much on the failures.
Let's talk about what we've done.
So in this whole presentation, if there's one thing that I
would say is not the obvious part, it's this.
And that was the insight that we've already agreed that
devices are going to need link local addressing, and they're
going to need some kind of naming.
So multicast DNS is the answer for that.
Having agreed that these little devices have got to
have those two bits of code in them, maybe we don't need a
complete third body of code for doing discovery.
Maybe we can actually repurpose some of that code
that they have to have anyway.
And that was the breakthrough, realizing that we can do
service discovery using the semantics of DNS queries, and
we don't need to invent a new protocol.
And then we can run that DNS over the multicast DNS support
that we've already created.
And the insight here is that we can put together some
existing properties of DNS that are not new.
They just haven't been used in this way before.
And one of those is that a DNS query can
return multiple answers.
If you have a multihomed host, you do a query, you get more
than one IP address.
This is normal.
Another function of DNS is PTR records.
They're normally used for mapping addresses to names,
but in fact it's a pointer.
It's a link from somewhere in the name hierarchy to
somewhere else in the name hierarchy.
So we can use those.
And the third property of DNS is something called SRV
records, which have been around for about five years.
They're not new.
They're supported by BINE 8 and BIND 9.
And what an SRV record does is it doesn't just give you the
host way a service runs.
It gives you the port number.
And that just fixes a little oversight in the way DNS was
structured.
The reason you can't run more than one web server easily on
a machine is because they can't both have port 80.
And this hard coding that a particular service always has
to be on a particular port is because the directory service
doesn't tell you which port to use.
When you type www.google.com into your browser, it tells
you the IP address of google.com's web server, but
it doesn't tell you the port number to connect.
So you end up pulling this number out of the air and
saying it must be 80.
Well, if the directory service can tell you that number, you
then remove that limitation, and you can run any number of
instances of any service type on a single machine, and
they're not fighting over the same well-known port.
So that is the framework of DNS service discovery.
And using those operations, we provide three API functions.
You can register the existence of a
service that you're offering.
Clients can browse to find all the named instances of a
particular service type that they know how to use.
And then, at the time of actually using the service,
you resolve that name to the address and port number.
Because in a world of DHCP or link local addressing,
addresses are not stable.
Names are relatively persistent and stable, but
addresses could change day to day, minute to minute.
So that's why the service discovery doesn't find
addresses, it finds names.
And then at time of use, you resolve
the name to an address.
So I'll run through a quick example.
A printing client knows how to speak the IPP printing
protocol, so it asks a question of the network,
effectively saying, I speak IPP, who out there knows how
to talk my language?
Who's willing to talk to me?
And it issues this query on the network.
In this case, it's .local, which means multicasts on the
local network.
But because this is a standard DNS query, that could be
google.com, and it would be a unicast DNS query to the name
server to ask the same question.
The answer we get back is, in this case, we've got four
example records structured like that.
And the first label of each of these records is the user
friendly name.
DNS host names are traditionally letters, digits,
hyphens, no upper case, no spaces.
The DNS protocol itself doesn't have that limitation.
It's a convention for host names that you have to type on
the command line.
And given that you don't type these things on the command
line, we're free of that restriction.
So any UTF8, Kanji, whatever characters you want are fully
supported, and they go in the DNS packets as UTF8.
Apple Talk, you used to have a structured name space with
name, type, and zone.
And we have a similar thing here.
We have the first label is the user visible name.
The second two labels define the service type.
In other words, the application protocol that this
service uses.
And then the rest of the DNS name is the domain where that
service is being advertised.
A bit more on service types is warranted.
A lot of service discovery protocols that have being done
before are organized around device discovery.
Because as a human being, that's the way you naturally
think about things initially, is find me the bits of
hardware on the network.
I want that to a printer, but you think of the printer as
been this physical thing.
From the point of view of your software, it doesn't care
about plastic and metal.
It cares about entities on the network that speak a protocol
that it understands.
And if this is an Apple Talk printer that doesn't do IP,
well then, it's not a printer, as far as I'm concerned,
because I can't talk to it.
So don't find me printers.
Find me things that I can talk to.
And a print service might be offered by a computer that's
got a USB cable to a printer.
So the notion of what really is a printer and what's not a
printer is a little bit slippery.
But the notion of what implements the IPP protocol is
much better defined.
There is a list of these registered service types, and
it's up to about 250 registered application
protocols that are advertised and browsed for using DNS
discovery, or Bonjour, as Apple likes to call it.
I mentioned resolving.
I'll quickly cover that.
So let's say we want to use the sales printer.
And that has been set as our default printer.
But every day when we print, the IP
address could have changed.
So at print time, we do this query.
We ask for the SRV record, and we ask for the text record.
And the SRV record tells us that it's on port 631 at a
host called myprinter.local.
And by the magic of DNS, it can put extra, helpful
information in the reply that you didn't ask for, if it
thinks you're going to need it.
So with one round trip to the printer, we get this
information.
We know the address.
We know the port.
And the text record contains additional name value pairs.
In this case, it tells us that this printer supports the
postscript page description language.
A real text record for a printer is about half a K
long, and tells you whether it does color, and double sided,
and stapling, and all the attributes of the printer.
The full support for this third leg of Zero
configuration networking appeared in Mac OS 10.2.
And it's open source.
And it's real open source in spirit, not just in name.
The CVS server we have is public.
Day to day, any time any engineer at Apple checks in
code, you see it in the public CVS server.
So you see things in the CVS server before they actually
ship with OS 10 systems.
The code is intentionally written to be very, very
portable, so it runs on POSIX systems like Linux, like
Solaris, like FreeBSD.
It runs on Windows.
It runs on Windows CE.
It runs on VxWorks for little embedded devices.
And there's a simple adaptation layer.
So the core code needs to send packets, receive packets, set
timers for future events.
And if you want to run this on a different operating system
or a different environment, you just have to implement
that adaptation layer.
One of the things that plagued Apple Talk was a reputation
for chattiness, and that was somewhat deserved, somewhat
not deserved.
But we want to avoid doing that.
So one of the things that does differentiate multicast DNS
from Apple Talk is very, very aggressive techniques to limit
the chattiness on the network.
There's opportunistic caching of everything that the
responder sees, in case you want to know about that later.
When you do a query, you list the answers you already know,
because in Apple Talk you would query for the list of
laser writers, and you might get 20 responses.
But because packets get lost, you retransmit the query and
you get the same 20 responses again, over and over again.
In multicast DNS, we have a way of listing the known
answers so that all those guys don't answer a second time.
And it gives the machines you missed the first time around a
chance to answer without being stomped on.
When you've got a lot of machines on the network, you
can get in a situation where the fast ones always beat the
slow ones, and then the slow machines are the ones whose
packets get lost when the queues overflow.
So you can get systematic failure where the slow devices
are always being missed.
So actually suppressing the ones you know about and giving
the slow ones a chance to answer is very important.
We have duplicate question suppression.
So if I browse for printers and then you want to print,
you don't have to do the same query, because it's already in
your cache.
Lots of other techniques.
We don't query the network at a steady rate.
We do exponential back off.
So if you leave the printer browser running, it'll back
off to one query per hour.
So it's very light load on the network.
Now, if you're querying once per hour and you plug in a
printer, you want to know about it.
You don't want to wait an hour for the next retry.
And we don't want to have refresh buttons and things in
the user interface, because that would just be horrible.
So when a new service comes on the network, it announces its
presence so that it shows up immediately in browsing
clients, and then those announcements have a similar
exponential back off.
So lots of things like that.
With the long TTL in the cache, you run the risk of
having stale services remain.
After somebody's turned the printer off, it's still
showing up in the list. So one way to solve that is to have a
short time to live, so things expire quickly.
But that costs you in terms of network bandwidth.
So we took a different approach where we let things
stay in the cache, but when you try to use them and the
connection fails, we use that as a hint to feed back into
the cache management algorithm to say, I think this thing
that you told me about is actually gone.
Can you check again for me?
And then taking that even further, the other clients on
the network witness your failure to use this service
and your attempt to reconfirm its existence, and they update
their caches as well.
So typically what happens if somebody does unplug the
printer is you try to print, you fail, you look back in the
list and it's gone.
You now have a mental model of what happened.
You say, oh, somebody must have turned the printer off.
The truth is they turned it off half an hour ago.
But the point is, you have a mental model that doesn't make
you frustrated.
If you tried to print and failed, and you looked back in
the browser and it's still there, well, then you start
getting annoyed with the computer.
So this is kind of self-healing.
Everybody else on the network gets their list updated, so
only one person goes through this and everybody else get
the benefit.
There's a question back there?
AUDIENCE: Could you comment on how the other clients are
getting their list updated?
I haven't heard any methods described so far
for how they do that.
STUART CHESHIRE: The question was how the other clients get
their list updated?
And the answer is that as well as sending queries by
multicast, we send answers by multicast as well.
So all clients are party to the exchange that's going on.
They see the queries.
They see the answers.
When they see the answers, they cache them.
When they see a query that doesn't yield an answer they
were expecting to see for that query, than that gives them a
hint that that data in their cache is probably false and
ought to be purged.
So this is where I will show a bit of my demo hardware.
And I know today that Google's main business model right now
is in the wide area services.
But I predict that in the future, with the way Google is
getting in so many business areas, right now your focus is
getting information to a web browser on a desktop computer.
But that's really just the tip of the iceberg.
And when we start looking at video and images and music,
and wanting to get this data to all kinds of devices all
around the house-- to the television, to the hi-fi, to
little tablets that you carry around, to things we might not
have thought yet-- then the ability to seamlessly throw
all this stuff together and have it self-organize and
self-configure is going to be critical for
those products to succeed.
And many attempts to do things like that today, things that
plug into your hi-fi and play music, have just been
horribly, horribly difficult to use.
And if you look at the reviews in magazines and on the web of
these things, the journalists are absolutely scathing.
I've seen reviews where a journalist spent an afternoon
struggling to get a particular music player to work, and then
just gave up.
And the review was not that it was hard to use, but he
couldn't make it work, and he sent it back.
So let's see--
I'm going to start off with one of my favorite things.
This is a little network camera made by Axis.
And one of the other reasons that this is one of my
favorite things is that it also does power over ethernet,
so no power brick.
You just plug it in, and I run Safari, and
this thing runs Linux.
AUDIENCE: Yes.
You lost your--
STUART CHESHIRE: Ah, OK.
Let's do--
So this thing should be booting up, now.
There you go.
And one of the reasons that USB is popular is because you
just plug it in and it works, and it's a low power device,
so you don't need a power brick.
And now, I know that USB is entrenched, and I don't expect
that to change.
But in sort of some fancy, academic parallel universe, if
we'd done this about 10 years ago, then maybe we wouldn't
even need USB for many of these things today.
Because zeroconf provides the plug and play for this.
Power over ethernet provides the power.
You've now got something that is every bit as easy to use as
USB, except the cables can be a hundred meters long and the
speeds can be a gigabit per second.
So you've got something much, much more capable than USB
without sacrificing the ease of use.
So I plug this in.
I have no DHCP server.
I don't know what its IP address is.
I don't care what it's IP address is.
I don't care what its name is.
Because Safari just found that we have a network camera.
Access 211.
And what Safari did there was when I clicked on the Bonjour
list, it did the browsing operation I talked about.
It said what out there on the network speaks HTTP?
And the camera said, I do.
So Safari displayed the name.
And then when I double click here--
Now, if any of you have spent the afternoon it normally
takes to get a network camera working, you'll appreciate
what I just did here.
Those of you who haven't are kind of looking at me, saying,
I don't get what was so special about that.
You plugged it in and it worked.
Of course, that's what it's supposed to do, isn't it?
And you're right.
That is what it's supposed to do.
And it's just tragic today that so many devices don't.
Now, sticking video in a web page is kind of convenient,
because the web browser has become the kind of universal
user interface for devices today.
If it doesn't have a screen and a keyboard, the web
browser is how you configure it.
20 years ago, the universal interface was the serial port
on the VT100 terminal, and we've moved beyond that.
But we do have this problem that without zeroconf, you
don't know what address to type in, which leads us to
this crazy situation where things ship from the factory
with certain hard coded addresses, and then the manual
tells you what the address is, and if that address is not on
your subnet, you have to reconfigure your machine's
networking settings before you can communicate with it.
And if you were trying to read the instructions on the
company's website, you've now just lost your connection to
the website, so you can't see the next page of the
instructions.
And if you plug two of these things in, they can't both
have the same address.
This is just clearly so much better.
But video on the web, it's a pragmatic thing.
But the other thing I was very excited about this camera
doing is it's a camera.
It's a network device.
So it doesn't just offer HTTP service.
It also offers RTP, streaming video over UDP, and QuickTime
player, in QuickTime 7, actually browses for--
if we go Open URL and pull down this menu, it finds RTP
sources on the network, and what we're now seeing is video
not wrapped inside an HTML, HTTP wrapper, but just raw,
native RTP video streaming over UDP packets.
And any application protocol you have can be advertised
using Bonjour, using DNS service discovery, and clients
can browse for that.
Question?
AUDIENCE: Say you've got a program, and you want to find
the second camera, and you want to get
it right every time?
STUART CHESHIRE: The question is how you
find the second camera?
Well, you give the cameras names, if I'm answering your
question right.
And then Even though the address has changed, the names
are persistent, so you look it up by name.
And that's how you find the first, second, third, tenth,
whatever it is.
The entities have names, like files in the file system.
AUDIENCE: It has to be smart enough to take that
configuration string and hold onto it.
STUART CHESHIRE: Well, this device, it ships from the
factory with a default name.
But through the web interface, you can then configure it to
choose the name that you want.
So out of the box, it calls itself Axis 211.
What you would do as a typical user, if you have more than
one of these, if you are sort of building a security system
for your house, you would call them garage,
garden, front porch.
You would give them user-meaningful names, and the
web UI is an ideal way to do that.
That's very convenient.
Question?
AUDIENCE: What happens if you plugged two of these in with
the [UNINTELLIGIBLE].
STUART CHESHIRE: The question is what happens if you have
two plugged in?
Before a device advertises its name, it does a query.
If something answers that query, then it appends -2 on
the end of the name.
So out of the box, if you plug ten of these in, they become
Axis 2, 3, 4, 5, 6, 7, 8, 9, 10.
But if you have that many, your first step is typically
to rename some of them.
Now, you don't have to.
If you've got two, and you've got Axis and Axis 2, and you
know which one is which, then Axis 2 may be a perfectly fine
name for you.
So there's no obligation for you to change it, but there's
that option, if you'd like to give it a
user-meaningful name.
Question at the back?
AUDIENCE: Does that name have a timeout?
So if, let's say, both those queries go at the same time.
Both of them don't [UNINTELLIGIBLE].
STUART CHESHIRE: The question is about the race condition,
if two devices do it at the same time.
At the end, I'll show the URL, but there's a URL,
zeroconf.org, which has links to all the documents and
specifications, and the other related websites.
But when two devices query, they see
each other as queries.
And seeing another simultaneous query for your
name is also treated as a conflict that is result with a
tie breaking algorithm.
AUDIENCE: From the user experience, is this just an
extension of a USB, like a [UNINTELLIGIBLE]?
STUART CHESHIRE: Is it just an extension of USB?
I would say it's a lot more than just USB, because you can
have many more devices.
You're not limited to six feet of cable.
Because this is IP, it's agnostic to the underlying
communication hardware.
So it can be ethernet.
It can be 802.11 wireless.
It can be IP over FireWire.
In future, it can be whatever new things the
hardware guys invent.
And that's the great benefit of using IP, is that whenever
a new piece of hardware comes out, it inherits this huge
wealth of IP based application software that's
already been written.
You bring out something like Bluetooth, which is emulating
the serial port-- it's not an ethernet
style packet interface.
It's a virtual serial cable.
Well, Apple had to write the Bluetooth file exchange tool,
and doesn't the world have enough file
exchange tools already?
We have FTP, NFS.
We have Samba.
We have Apple Share.
We have SCP.
What we need is--
AUDIENCE: We could use one more.
Why don't we just do that?
[LAUGHTER]
STUART CHESHIRE: You're spot on, there.
The same is true of printing protocols.
We would definitely need a good IP printing protocol.
AUDIENCE: Just one more.
[LAUGHTER]
STUART CHESHIRE: But let's do it once and get it right, and
not have to keep reinventing the wheel.
That's my point, and I think we agree on that.
So before we run out of time, let me quickly run through
some of the other stuff I have here.
So one of the things I told you was you can do this wide
area, as well as .local.
So if I turn on my wireless interface here, and in the
Bonjour preference pane, I have added my home domain,
stuartcheshire.org, in my list of default browsing domains.
And what this just did here was, unknown to Safari, it did
a call saying, I want to browse for network services of
type HTTP, and the code behind the scenes did a DNS query for
http.tcp.stuartcheshire.org.
And these are just some example ones that I put for
illustrative purposes.
None of these advertised services are actually coming
from my house, which is one of the things I wanted to
illustrate.
So you can include references to any host name and port and
service you want.
So we can double click that, and it's going to take us off
to the BBC website.
But any organization can advertise static services like
this just by typing the lines in the DNS file.
So when you stay in the Hyatt hotel, they could advertise
some static pages all about the hotel.
They have that television channel that tells you about
the restaurants and the gym and the
swimming pool, and things.
Well, they could do a very similar thing where they have
a web page about the hotel.
San Jose airport could have a web page announcing flight
departure times.
And because it's so location based, they could actually
fill that with advertising for the book shop in the coffee
place, because they know you're sitting in the airport
waiting an hour for a plane to catch, so
maybe you want a coffee.
So there's lots of opportunities there when we
have a way to communicate with the users.
In the days of Unix machines, there was a message of the day
when you log on, and now with laptops and DHCP and wireless,
we've lost that kind of message of the day ability to
communicate with the people who are
connecting to the network.
AUDIENCE: I'm not sure I follow what's going on here.
How far out on the internet are you going?
STUART CHESHIRE: The question is, how far out into the
internet is this going?
Obviously, it's not querying every name
server in the world.
What it's doing is if the DHCP offer contains a domain, then
it will query that domain, and the user can also manually add
domains, as I did, to manually augment that automatic search
list. So if we look through the packet sniffer here, when
I ran Safari, you would have seen a query go to google.com,
because I'm assuming google.com, was in the DHCP
packet, and if google.com's name service said I have
nothing for you, then nothing gets displayed.
But that's the bootstrap mechanism how the client knows
which domain to query.
So actually, I'll bring that web page up again, because I
can use that to show another little example.
If you've ever tried to use a network printer, you'll
probably have experienced the grief with that.
It's as bad as a network camera.
I'm actually going to delete this printer, because I want
to show you--
and this is interesting.
I'm actually finding all of Google's Bonjour printers in
this building.
[LAUGHTER]
STUART CHESHIRE: I actually want to--
I'm going to delete that.
OK.
So that's more like the configuration a user would get
out of the box.
They've got their new computer, and they don't have
a printer, and they want to print something.
And this is the little Apple AirPort Express Base Station.
It looks like a power brick for some sexy Apple product.
And it is a power brick, but it's also a wireless base
station, and a print server, and a music
server in the same housing.
I'll plug it into here, so you can see it.
Before I do that, maybe I'll show you one of the other
things it does.
I'll show you the music, as well.
AUDIENCE: [UNINTELLIGIBLE]
STUART CHESHIRE: I think I'm OK.
I didn't actually have one of these still in the wrapping
today, but one of the things I like to do is get somebody to
time me actually taking the shrink wrap off the box and
getting it out and plugged in.
So this is factory default.
I haven't set it up.
I plugged it in, and--
AUDIENCE: You might be running into a security feature of our
local access points.
STUART CHESHIRE: Well, it shouldn't block the
ability of this to--
AUDIENCE: You might be surprised.
[LAUGHTER]
STUART CHESHIRE: I think maybe FCC regulations about the
unlicensed spectrum is unlicensed for a reason.
[LAUGHTER]
STUART CHESHIRE: Well--
AUDIENCE: Stick it outside the window, and it might work.
STUART CHESHIRE: It definitely looks like something is
blocking the wireless.
But I'll do it over ethernet, instead.
So I'm sure most of you here have seen iTunes, and--
[LAUGHTER]
STUART CHESHIRE: No.
It was just a bit slow, I think.
So in iTunes, I just pulled down this menu, here.
I select the new sound output device.
I click Play.
[MUSIC PLAYING]
STUART CHESHIRE: And normally, this takes me about 90
seconds, including getting the cellophane off the box and
unwrapping it all.
And if any of you have tried to set up some of the UPnP hub
media players, you know it takes you more than 90 seconds
from shrink wrap to having music coming out.
So that's the music side of it.
Let's go back to the printing.
So we still have no printer selected.
Failed the "is it plugged in" test. Let's connect the cable.
So I plugged the printer into the USB port, and we'll see
now, what else do I have to do.
Do I need to run some wizard?
Some setup assistant?
Do I need to reboot anything?
No.
So soon as that finishes booting up, under Bonjour
printers, there's my printer.
I click Print.
So that is the out the box is experience.
Now, in this case I'm using a USB printer plugged into an
AirPort Base Station.
But if you buy any network printer made in the last
couple of years from pretty much any printer company--
HP, Lexmark, Canon, Brother, Xerox.
I'm probably missing some.
They have native Bonjour support.
They advertise themselves.
They show up in the print menu.
And if they have web configuration pages, then they
show up in Safari.
AUDIENCE: Do I need a driver for each Bonjour printer?
STUART CHESHIRE: The question is about drivers.
And this actually comes back to the question earlier about
file transfer protocols.
What the world desperately needs is a good network
printing protocol over IP.
And that's kind of a layer above Bonjour.
The idea of Bonjour is that it's a foundation to let
people build application protocols.
Now, I am working with the printing team at Apple, and we
are trying to work on that.
But I make a distinction that that's not Bonjour.
That's a printing protocol.
What happens right now is because all the printer makers
want to differentiate their products, they all have a
different driver with different features and
different color matching.
And I think they feel that if there was just a standard
protocol for printing, than they
wouldn't be able to innovate.
The real answer might be that we need printers to support
some basic protocol for guest printing.
Somebody comes to your house and they just
want to print a document.
And they don't care about perfect color matching.
They want to print out the Google Maps driving directions
so they can get home, and it doesn't have to color correct.
But at the same time the printer makers can make
drivers that you can install if you do want to use the
extra, optional features.
That, I think, is the answer to that.
PostScript is a good answer, but PostScript doesn't appear
in low end printers.
When I go to conferences and IETF meetings and things like
that, I just look in the print dialogue, and all high end
printers do PostScript, and PostScript is PostScript, and
I can print.
Typically at an IETF meeting, what you're printing is 80
column, monospaced text.
It's not exactly the most challenging print job.
This is the Roku SoundBridge.
I think this is $99 now.
This sort of works the other way around.
Instead of the Mac pushing music to this, you kind of
attach this to your hi-fi.
It's got a little remote control in its display.
Afterwards, people are welcome to come and talk to me, and we
can play with some of these things.
Here's one of the new Axis cameras that's even smaller.
This one's Linux.
You can telnet to this and run Emacs and edit the
configuration files, and things.
Some more print servers.
Here's a parallel port one.
Here's a little USB one.
This one is smaller than its own power brick, which is a
pretty cool.
I mean, if anything is just like crying out for power over
ethernet, it's got to be this, right?
This is USB on one side, ethernet the other side.
This is a print server.
This is one of my favorites.
This is a serial port to ethernet converter.
And they love this in the data centers, where you've got all
this old rack mounted equipment with serial ports on
it, and you have it running these waterfalls of serial
cables everywhere to go to some terminal
concentrator or something.
Well, with these, you just click them into the ethernet
and advertise telnet service that shows up.
And those of you who have got Macs around here may not have
seen this in terminal, but if you go connect to server, then
you get this little browsing window, and here are three--
well, here are some machines here at Google that are
advertising themselves as telnet service.
Now, I still need a user name and a password
to connect to them.
And Rose is my machine at home, because with the wide
area browsing, it's showing up there as well.
So this thing shows up in the telnet list in terminal, but
the reason I love this is we had one of our Bonjour
presentations at Apple, and I was proudly saying how the
code is only 100k, and in this era of multi-megabyte bloated
applications, I'm feeling pretty smug about that.
And the guy says, no, you don't understand.
This has got 16k of flash memory, and of that, 9k is the
HTML pages of the web UI that I server.
And in the remaining 7k, I've got ethernet driver,
ARP, IP, UDP, TCP.
[LAUGHTER]
STUART CHESHIRE: DHCP client, DNS client, telnet server, web
server, and you have 700 bytes left to do Bonjour.
So forget my source code.
We go to the white board.
We kind of brainstorm the absolute most cut down
implementation we could think of that might have all the
optional efficiency features, but would
generate the right packets.
And he did it, and this is called the SitePlayer.
And if you go to siteplayer.com, that's where
they sell these.
And this is a Bonjour device.
It may not be the most sophisticated Bonjour device
in the world, but he did it in 800 bytes.
So that was pretty cool.
It is now at 12 o'clock, so those of who've got other
meetings to go to, I won't be offended if you take off.
But I'm happy to stay here and answer any more questions.
[APPLAUSE]
AUDIENCE: [UNINTELLIGIBLE]
STUART CHESHIRE: Why is the download 14
megabytes for Windows?
There's something about Windows installers, and when
you localize it for 26 languages, you end up with
lots of duplicate copies of the code, there.
And it should be more like about 1 megabyte, but I
personally don't know how to fix that.
If there's some people with Windows expertise that know
how to slim that installer down, that would be good.
Question over here?
AUDIENCE: Are you familiar with Avahi?
STUART CHESHIRE: Am I familiar with Avahi?
Yes.
Avahi is a GPL open source implementation of the Bonjour
protocols, and it's absolutely great.
Not as good as mine, of course.
But actually, the right they're going, and the rate
that they're adding new features and fixing bugs, they
could well overtake Apple's implementation.
They're really good guys, and they know the
protocols inside out.
And we talk to them on a regular basis, because they
find timing errors that we have, and race conditions, and
ambiguities.
And we're working together with them.
AUDIENCE: Can you browse services from other browsers,
like Firefox?
STUART CHESHIRE: Can you browse from Firefox?
Well, that was actually one of the things that I was hoping
to talk about today, because somebody from
Firefox works at Google.
AUDIENCE: Hello.
STUART CHESHIRE: Hello.
[LAUGHTER]
STUART CHESHIRE: Yes.
We have Bonjour browsing in Safari.
With the Bonjour for Windows plug in, we have it in
Internet Explorer.
But Firefox is clearly the dominant force in
web browsers today.
It may not numerically eclipse Internet Explorer, but in
terms of impact that it's having, and the fact that it
runs on Mac and Windows on Linux means that it's
something that I really, really want to get a Bonjour
browsing menu into Firefox.
AUDIENCE: Can you advertise a default [? browse ?] service
and somehow get from your local area [UNINTELLIGIBLE].
STUART CHESHIRE: Can you advertise a default route?
AUDIENCE: [UNINTELLIGIBLE]
STUART CHESHIRE: The answer I have to that is we're really
trying not to compete with existing
technologies that work well.
And a home gateway with a DHCP server in it is a perfectly
fine way for clients to get an address, and get a
configuration, get the name server address, and all the
other information it needs.
So at the addressing level, we're not competing with DHCP.
Link local addressing is the safety net for
when DHCP isn't there.
The multicast DNS and the service discovery are useful
and still applicable, even if you do have a DHCP address.
But the addressing is there as the fallback for the DHCP, not
as a competing replacement for it.
AUDIENCE: [UNINTELLIGIBLE]
STUART CHESHIRE: The question is about the .local TLD.
And I could do a whole hour long talk about
IETF politics here.
[LAUGHTER]
STUART CHESHIRE: But there's a lot of
controversy in the IETF.
The DNS extensions working group felt that local name
spaces were a bad idea.
They thought that RFC1918 that defines the Net10 and the
other private address spaces was a bad idea.
And they said that DNS would not make the same mistake that
RFC1918 had made.
Now, their view is that every device in the world needs a
globally unique name.
NAT is evil.
Private addresses are evil.
The point of the internet is that everything is reachable
from everything else.
And I completely agree with that goal.
That's a wonderful goal.
That's what the internet should be.
And things like NAT do really interfere with the ability to
make good products.
Things like iChat AV for the video conferencing has to go
to extraordinary lengths to try to work around the
problems that NAT creates, and even then, it doesn't
work all the time.
So I have lost sympathy for that point of view.
Where I disagree with them is in order to just print this
page, my printer did not need a globally unique, globally
addressable DNS name that I pay $35 a year to
register.com for.
And that was where we disagreed.
And they said, well, don't use IP.
Use USB, right?
It's almost demeaning to the grand IP to be used for such a
mundane, local communication task.
Some lesser protocol should do that.
And really, it was a purview of the DNS extensions working
group to define the standards for how DNS works.
And they abdicated that responsibility and said, sort
of, let chaos reign.
And that's a problem.
Now, the reality is that with all the printers, and the
cameras, and the Macs, and Bonjour for Windows, and
everything doing .local, and Linux as well, nobody is going
to allocate .local right now, because it
would just cause chaos.
But I wish it hadn't turned out that way.
I wish we could have done it more with the support of the
IETF of community.
AUDIENCE: Do you have a
certification program for license?
STUART CHESHIRE: Do we have a certification program?
Yes.
If you go to, in fact I was going to--
That's my final slide.
The zeroconf.org website is a good place with links to the
other ones.
Apple's public facing website is apple.com/bonjour.
The developer related information is
developer.apple.com/bonjour.
And that's where you'll find the conformance test. So if
any one of these devices was to put the Bonjour logo on the
packaging, they have to run that conformance test.
There's no cost for that licensing program.
It's purely Apple wanting to maintain the standard, so that
when you as a customer see the Bonjour logo on a printer, you
know that it really means something and it's not going
to be a frustrating experience.
Because Bonjour needs to stand for more than just sort of a
checklist feature.
Yes, we implement this and this and this, but it's turned
off by default.
Well, if it's turned off by default in the factory, then
it's not providing any benefit to the user.
So we have some requirements.
Like out of the box, the printer has got to show up.
And if you do all those things, then you
get used the logo.
All right.
I'll take one last question, there.
AUDIENCE: You mentioned Avahi.
Would you mind briefly giving the state of the rest of the
independent [UNINTELLIGIBLE]?
STUART CHESHIRE: I don't know all of them anymore.
This thing has mushroomed so big that I don't actually know
everything that's going on anymore.
Avahi is the best one I know.
Arthur Van Hoff, of Marimba and Java fame, did a complete
Java implementation of multicast DNS.
Novell did one entirely in C#.
There are others I've heard of that aren't really complete,
but Avahi is the one that I know of that really does
challenge Apple in terms of its completeness and its
robustness.
All right.
Well, thank you all for coming.
[APPLAUSE]