►
From YouTube: IETF106-TUTORIALIP-20191117-1345
Description
Service Discovery for IP Applications
This tutorial covers the three fundamental operations of DNS-based service discovery: Offer, Enumerate, and Use. It includes the APIs available on multiple platforms to access these operations along with both local service discovery using Multicast DNS and wide area service discovery using conventional unicast DNS.
Slides at:
https://datatracker.ietf.org/meeting/106/materials/slides-106-edu-sessf-service-discovery-for-ip-applications-00
TUTORIALIP meeting session at IETF106
2019/11/17 1345
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
My
name
is
Joe.
Shaw
I
did
my
degree
in
computer
science
at
Cambridge.
I
did
my
PhD
at
Stanford.
While
I
was
there.
I
was
one
of
the
few
Mac
users.
Everybody
else
was
running
Linux
and
I
got
tired
of
all
the
other
Stanford
computer
science
PhD
students
coming
to
use
my
computer
to
print
because
they
couldn't
figure
out
how
to
do
it.
A
I
I
was
quite
vocal
about
the
terrible
state
of
ease
of
use
for
IP
back
then
compared
to
Apple
talk
where
you
just
pull
down
the
Apple
menu
and
click
on
the
chooser
see
a
list
of
printers
pick.
One
I
became
co-chair
of
the
ITF
zero
configuration
working
group.
I
served
a
term
on
the
IAB.
I
wrote
The
O'reilly
book,
you
see.
A
There's
there
a
configuration,
networking
and
I
am
currently
a
distinguished
engineer
at
Apple,
so
apple
talk
in
the
80s
was
well
known
for
its
ease
of
use
and
what
we'd
like
with
zero
configuration
IP
is.
Nobody
ever
has
to
type
an
IP
address,
not
to
configure
a
device
to
set
it
up
and
not
to
connect
to
some
service
on
some
other
device,
and,
if
you
think
about
today,
nobody
has
to
type
MAC
addresses.
We
have.
This
protocol
called
ARP
that
maps
from
IP
addresses
to
MAC
addresses.
A
Why
do
you
care
if
you're
making
products
it
lowers
the
support
costs
if
people
are
not
calling
because
they
can't
make
it
work?
It
saves
you
money.
People
are
not
returning
the
product
because
they
can't
make
it
work.
It
makes
entirely
new
product
category
as
possible,
which
would
not
be
possible.
There
would
not
be
a
market
for
them
if
they
were
so
difficult
to
use,
nobody
bought
them
and
perhaps
last
but
still
interested.
It
makes
products
that
are
a
pleasure
to
use
instead
of
a
pain.
A
These
are
some
pictures
from
when
Apple
introduced
air
print
you
tap
on
print,
and
you
see
the
available
printers.
Nobody
types
in
an
IP
address.
Apple
uses
zero
configuration
networking
for
things
like
air
print,
airplay
home
kits.
You
don't
see
anything
in
those
UI
where
the
user
has
to
type
in
the
IP
address.
Of
what
they're
connecting
to
this
is
especially
critical
for
devices
that
have
no
screening
keyboard.
Think
about
Wi-Fi
access
points.
A
The
only
way
you
can
configure
and
manage
a
network
device
with
no
screening
keyboard
is
over
the
network,
so
you
have
to
have
absolutely
reliable
networking,
because
if
it
can't
be
reached
over
the
network,
there
is
no
way
to
reach
it.
20
years
ago
we
had
serial
ports
and
you'd
connect
a
vt100
terminal
to
its
and
manage
it
over
the
command
line,
and
there
are
still
some
products
like
that.
But
more
and
more
we
want
to
move
to
a
world
where
we
don't
need
a
serial
port
as
a
crutch
to
make
a
networking
work.
A
So
how
do
we
realize
this
vision?
There
are
three
supporting
technologies.
The
first
one
is
you're
not
going
to
do
much.
Ip
networking
without
an
IP
address.
Dhcp
is
great.
If
you
don't
have
a
DHCP
server,
you
don't
the
product
to
fail.
So
that's
where
self-assigned
link-local
addressing
comes
in
this
is
really
simple.
In
v4
and
in
v6
you
pick
a
random
address
within
the
designated
range
you
send
an
ARP
or
neighbor
discovery
request
to
see
if
it's
already
in
use
and
if
it
is,
you
pick
a
different
one
and
try
again
so
that's
great.
A
A
Dns
is
great
if
you
have
DNS
setup
and
you
have
the
infrastructure
to
do
that,
then
that's
a
great
way
of
naming
devices
just
like
with
link
local,
addressing
where
we
want
to
fall
back
when
DHCP
is
not
available.
We
want
to
fall
back
when
DNS
is
not
available,
and
that
is
multicast
DNS,
which
adopts
as
much
as
possible
the
same
naming,
syntax,
the
same
record
types
and
as
much
as
possible.
A
The
same
semantics
except
it
is
just
done
using
multicast,
where
the
query
in
client
sends
a
multicast
to
all
devices
on
the
local
link
and
if
any
match
that
name,
then
they
respond.
You
can
name
your
devices
with
anything
ending
and
dot
local
and
the
dot.
Local
is
what
signifies
to
the
underlying
resolver
infrastructure,
to
look
this
up
with
multicast
on
the
local
link.
A
So
once
this
is
in
place,
you
can
type
printer
dot
local
into
your
web
browser
to
access
the
printers
web
UI
to
check
the
ink
levels
and
things
like
that
or
for
developers.
It's
super
convenient
to
be
able
to
log
in
with
SSH
without
having
to
remember
IP
addresses
they
can
access
their
devices
by
name
on
the
local
network.
A
So
the
third
thing
we
need
is
discovery,
and
there
are
three
basic
operations
in
discovery
that
I
call
offer
enumerate
and
use.
Offering
is
the
step
where
a
device
that
has
a
listening,
socket,
TCP,
UDP,
quick
SCTP,
any
other
protocol.
If
it's
listening
for
incoming
requests,
then
it
can
advertise
that,
on
the
network,
clients
that
are
looking
for
that
type
of
service
can
then
browse
or
enumerates
the
instances
on
the
network
that
can
meet
their
needs
and
then
finally,
having
picked
one
either
the
human
user,
picking
one
or
with
machine-to-machine
applications.
A
Some
algorithm
chooses
the
appropriate
one,
maybe
just
the
first
one.
It
finds
in
some
case
as
having
made
that
choice.
The
third
step
is
actually
using
it,
which
means
finding
the
IP
address,
making
a
connection
and
so
on.
Sometimes
this
happens
once
sometimes
discovery
is
just
used
for
onboarding.
A
device
onto
the
network
I'll
give
an
example
with
the
homekit
products
that
do
home
automation
when
you
get
them
out
the
box
they're
advertising
a
service
type,
which
basically
says
I,
am
a
non
configured
device
waiting
to
be
set
up.
A
The
client,
in
this
case
an
iPhone
browsers
for
that
finds
those
devices
communicates
with
them
over
the
network,
using
the
setup
protocol
and
once
that
done
they're
now
set
up,
they
are
no
longer
done
configured
device.
In
other
cases
where
you,
for
example,
select
your
default
printer,
then
you
may
do
that
selection
once
but
every
time
you
hit
command
P
and
print
to
that,
you
may
do
that
multiple
times
per
day.
A
So
this
discovery
stuff
sounds
nice.
One
of
the
things
we
want
to
keep
in
mind
here
is
very
constrained.
Devices
I
talked
about
home,
kits,
building,
automation,
IOT,
a
lot
of
these
devices
have
limited
resources,
we've
already
decided,
we
need
DHCP
and
self-assigned
addresses.
We
need
DNS
and
multicast
dns
for
naming.
If
we
can
leverage
that
code
that
we
have
any
way
to
do
discovery
as
well,
then
that
saves
us
having
a
whole
new
body
of
code.
A
So
let's
get
a
bit
deeper
into
the
three
operations
they
talked
about.
The
first
step
is
offering
a
device,
a
service
running
on
a
device.
A
piece
of
software
uses
the
discovery
API
to
publish
DNS
records,
describing
the
service
and
those
three
record
types
are
PTR,
SRV
and
text.
You
might
ask
what
are
those
records?
Well,
when
I
show
you
the
next
steps
that
will
become
apparent.
A
So
imagine
you
are
trying
to
prints
on
your
iPhone
using
AirPrint
and
you're.
Looking
for
printers
that
support
IPP,
you
send
out
that
query
on
the
network
and
you
get
back
in
this
case.
There
are
four
different
devices
that
answered
each
with
different
names
and
the
user
can
then
take
a
look
at
that
list
and
decide
which
one
they
want
to
use.
A
This
is
the
browsing
or
enumeration
step
once
the
user
has
picked
one
we
go
to
the
next
step,
which
is
actually
using
it.
So
in
this
case
we
look
up
the
SRV
record
and
the
txt
record
for
that
name
that
the
user
picked.
The
SRV
record
tells
us
the
target
host
and
the
port
on
that
host.
The
txt
record
gives
us
a
bunch
of
key
value
pairs
that
describe
other
attributes
of
the
service.
A
In
this
case,
for
example,
it
says
the
page
description
language
that
this
printer
supports
is
PostScript
also
by
the
magic
of
DNS
additional
records.
Even
though
the
client
didn't
ask
for
the
address
record
of
the
printer,
the
responding
device
knows
that
he'll
probably
need
that
information
so
for
the
target
host
referenced
in
the
SRP
record,
it
has
an
additional
record
giving
the
address
of
that
to
save
the
client
doing
another
round-trip
to
look
it
up
notice,
the
port
number
in
the
SRV
record.
This
is
incredibly
helpful.
A
This
frees
us
from
having
to
use
fixed,
well-known
ports.
If
you
want
to
run
multiple
instances
of
a
service
type
on
the
same
device,
they
can't
all
have
the
same
port,
and
this
leads
to
very
complicated.
Workarounds
HTTP
has
the
host
header,
which
lets
a
server
act
as
multiple
virtual
servers,
but
it's
kind
of
awkward
IPP
has
similar
demultiplexing,
but
every
application
has
to
invent
this
demultiplexing.
If
you
just
run
each
instance
on
its
own
port,
it's
much
simpler
and
that
wasn't
possible
with
well-known
har
code,
hard-coded
ports,
but
service
discovery.
A
So
going
back
to
these
results,
let's
take
a
little
bit
of
a
closer
look
at
that
name
on
the
left.
It
is
a
structured
name
made
up
of
three
parts.
The
first
part
is
the
user
friendly,
visible
name
of
that
instance
of
the
service.
It
is
arbitrary,
utf-8
text.
It
can
contain
uppercase
lowercase
spaces
punctuation,
anything
you
can
represent
in
utf-8.
A
Typically,
users
don't
have
to
type
this
name
when
they
connect
to
a
service.
Typically,
they
using
a
graphical
user
interface
and
they
click
or
tap
on
it.
So
keeping
it
short
and
easy
to
type
is
less
important
than
have
it
be
descriptive.
When
you
set
up
the
device,
you
name
it.
However,
you
want
and
having
done
that
naming
then
other
clients
just
select
it
by
tapping.
The
second
part
of
the
name
is
the
service
type,
which
tells
us
what
it
does
and
the
final
part
is
the
domain.
A
So
let's
look
at
those
three
in
a
bit
closer
detail,
starting
with
the
instance
name.
There
are
two
kinds
of
names
at
play
here.
There
are
the
host
names
and
the
service
names
host
names
are
what
we're
used
to
thinking
about.
With
DNS
they're,
often
typed
on
the
command
line
with
things
like
SSH
commands
in
terminal
windows,
and
it's
definitely
convenient
to
have
those
to
be
short
and
memorable
and
easy
to
type
and
it's
good
if
they
don't
have
spaces.
Pickers
shells
get
confused
with
spaces
in
arguments.
A
A
Because
multicast
DNS
has
name
conflict,
detection
and
automatic
renaming,
so
let's
consider
three
different
scenarios:
one
is
the
average
home
user
has
one
printer.
They
don't
need
a
12
character,
MAC
address.
If
the
printer
is
called
HP
LaserJet,
then
that's
their
printer.
Now
imagine
a
small
dentist
office
where
they
have
two
printers.
They
have
one
and
it
works.
Fine
and
later
they
decide
to
get
a
new
on
the
second
one
they
add
will
detect
the
name,
conflicts
and
call
itself
HP
LaserJet.
A
Now
most
people
in
the
dentist
office,
without
even
thinking
about
it,
will
very
instinctive
to
remember.
That's
the
old
printer
I've
been
using
for
years
and
the
new
one
is
printer,
no
confusion.
Two
different
MAC
addresses
much
harder
to
remember
than
the
new
one
is
number.
Two
third
scenario
is:
imagine
you
have
ten
printers
well
at
this
point.
Memorizing
ten
MAC
addresses
is
no
use
to
anybody.
A
So,
let's
move
on
to
the
second
part,
the
service
type-
this
seems
very
simple,
but
there
are
some
subtleties
here.
This
is
not
displayed
to
the
user.
This
is
something
only
programmers
see,
so
there
is
no
value
in
rich
text
here,
they're
limited
to
15
characters,
letters,
digits
and
hyphens,
just
like
traditional
host
names.
That
is
a
big
enough
space
that
they're
effectively
unlimited
the
allocated
first-come-first-served
and
there's
no
risk
of
running
out.
On
the
other
hand,
the
identifier
space
is
short
enough
that
it's
not
wasteful
in
packets,
particularly
for
these
IOT
type
applications.
A
The
second
half
the
label
is
the
protocol
type
string.
This
was
inherited
from
the
definition
of
DNS
SRV
records
in
retrospect.
Looking
back,
it
probably
isn't
necessary
and
it
causes
confusion,
but
it's
a
legacy
from
what
we
adopted
and
the
rule
is.
If
the
protocol
runs
over
TCP
attention
underscore
TCP
and
everything
else
is
under
school
UDP
and
that
would
include
things
that
actually
don't
use
UDP,
but
they're,
pretty
rare
things
like
quick,
actually
run
over
UDP.
So
that's
why
the
world
is
divided
in
two,
there
is
TCP
and
there
is
UDP
and
nothing
else.
A
Now
the
semantics
of
the
surface
type
string
are
really
important
because
they
encode
two
things:
they
encode
what
the
service
does
and
how
it
does
it.
What
it
does
is
a
user
meaningful
concept
like
say,
printing.
That
is
something
somebody
understands,
but
there
are
many
ways
of
printing
there's
IPP.
There's
the
old
LPR
protocol.
There
is
a
collection
of
proprietary
printing
mechanisms
that
traditionally
use
port
9100
variously
called
apps
or
Couture
jetdirect.
If
you
discover
an
IPP
printer,
but
your
client
doesn't
support
IPP,
that's
no
use
to
you.
So
it's
not
sufficient.
A
Just
to
have
the
logical
service
that
the
user
wants.
You
actually
have
to
have
a
compatible
implementation,
and
this
is
important.
The
other
way
around
as
well
I
can
give
an
example.
The
music
streaming
protocol
built
into
YouTube
into
iTunes
is
actually
just
HTTP
GET.
You
can
share
your
music
library
on
your
home
network
and
other
clients.
Just
do
HTTP
gets
to
fetch
it.
So
at
some
level
the
protocol
is
HTTP
but
semantically.
This
is
not
something
you
would
use
a
web
browser
to
view.
A
There
is
no
HTML
formatted
text
for
a
human
to
look
at
so
the
service
type.
For
that
is
not
HTTP.
It's
a
different
string.
It's
D
a
ap
digital
audio
access
protocol,
even
though
Wireshark
would
look
at
it
and
decode
it
and
perfectly
well
say
this
is
HTTP
semantically.
It
is
a
repurposing
of
HTTP,
so
the
service
type
encodes
both
what
the
user
perceives
they're
doing
and
the
protocol
that's
being
used
to
do
it
here
are
some
examples:
IP
p
is
printing
ssh,
remote,
login,
remote
frame
buffer
is
VNC
screen
sharing.
A
A
It's
important
that
these
service
types
don't
collide.
So
Ayana
maintains
a
free
registry
like
many
of
the
other
registries,
they
maintain
and
it
is
first-come,
first-served
within
reason.
Unless
there's
an
abusive
number
of
excessive
registrations,
there
are
no
restrictions
on
getting
a
service
type
assigned,
and
you
just
fill
in
the
form,
and
you
get
one
and
it's
yours
in
perpetuity.
It
doesn't
have
to
be
renewed
every
year,
like
a
domain
name
before
shipping.
A
A
So
when
you're
not
using
dot
local,
when
you're
using
some
other
domain,
then
normal
DNS
that
we
know
and
love
comes
into
play.
Services
can
publish
their
information
using
DNS,
update
and
clients,
discover
it
using
DNS
queries
and
DNS
is
the
largest
distributed
global
database.
That
I
think
the
world
has
ever
seen.
So
it
is
incredibly
scalable.
We
use
it
for
storing
host
names.
We
can
use
that
same
distributed
database
for
storing
service
information.
A
We've
been
doing
this
for
many
years
at
the
IETF,
and
you
may
have
used
this
without
even
thinking
about
it.
If
you
print
out
your
boarding
pass
or
print
out
an
internet
draft
to
read
sitting
here,
you
can
find
the
printer
in
the
terminal
room
and
you're
not
in
the
terminal
room
you're,
not
on
the
same
local
link
as
the
terminal
room,
but
it
still
works
and
if
it
didn't
work,
people
would
grumble
and
curse.
Stupid
multicast
DNS
doesn't
work
across
links,
but
when
it
does
work,
nobody
pauses
to
think
what
just
happened
there.
A
A
A
So
now
we
look
up
this
special
query
with
the
prefix
lb
DNS
SD
prepended
onto
meeting
dot,
ITF
dot
org,
and
we
do
a
PTR
query
and
what
that
is
asking
of
the
DNS
infrastructure,
specifically
asking
the
people
who
run
the
authoritative
server
for
meeting
dot.
Itf
tour
dog
is,
do
you
have
any
service
discovery
information
and
if
so,
where
should
I
look?
And
here
we
get
an
answer
and
it's
a
sort
of
self
referential
referential
answer.
A
It
says:
look
in
meeting
dot
ITF
go
talk,
but
because
it's
a
pointer
it
could
direct
you
to
services.
Itf
dog
or
wherever
in
this
case
it's
simply
self
referential
answer
pointing
to
itself.
So
now
we
know
where
to
look.
We
can
start
looking
at
services
and
one
of
the
questions
that
people
often
ask
me
or
what
are
the
assumptions
I
hear
people
have
is
that
you
have
to
be
quotes
on
the
ietf
network
and
that's
sort
of
a
loosely
defined
term.
What
does
it
mean
to
be
on
the
ietf
network?
A
What
is
the
ITF
network?
Dns
is
global,
so
here's
an
example
doing
the
exact
same
query
sent
to
Google's
quad
8
service,
and
it
gives
the
same
answer.
The
answers
that
you
get
from
dns
for
public
names
don't
depend
on
where
you
are
now
VPN
and
internal
DNS
accompanies
does
muddy
the
waters
a
little
bit
here,
but,
broadly
speaking,
for
public
names,
you
can
look
them
up
on
any
resolver
in
the
world.
That'll
consult
the
same,
authoritative
service
and
get
the
same
answer
so
now
we
know
where
to
look.
A
This
is
what
happens
when
you
go
into
system
preferences
on
a
Mac
and
click,
the
plus
button
to
add
a
new
printer.
It
does
a
PTR
query
on
the
network
and
here
at
the
ITF
we
find
one
printer
call
term
printer.
They
could
have
named
that
a
bit
nicer
with
capital,
letters
and
things,
but
that's
what
they
chose
to
do.
So
when
you
do
this
on
your
Mac
and
click
plus.
This
is
how
it
the
ITF
meeting
you'll
see
that
printer
show
up
when
you
actually
want
to
print
this
is
the
user.
A
You
then
look
at
the
SRV
record
for
that
printer
and
you
find
that
it
is
implementing
that
printing
protocol
on
port
9100
and
there's
the
ipv6
address
and
you
can
print
if
we
do
the
same
thing
on
iOS.
It
does
the
query
and
it
prints
notice
here
that
iOS
is
using
IPP.
So
it's
a
different
service
type
and
the
port
number
is
different.
So
same
hardware,
different
protocol,
different
ports,
same
results
Turner
on
paper.
A
Now
those
of
you
who
are
watching
closely
would
have
noticed
something
there
in
the
query
that
the
iPhone
did
it
has
this
prefix
Universal,
which
is
a
subtype
of
IPP
subtypes,
are
a
little
used
feature
of
service
discovery,
but
I
want
to
mention
them
here.
For
completeness,
because
they
can
be
useful
if
you
need
that
subtypes
are
aware
of
narrowing
the
scope
of
what
you
find.
A
But
the
mandatory
to
implement
format
is:
it
must
support
URF,
because
that
way,
you
know
that
your
device
may
not
be
able
to
send
post
group
for
PDF
or
JPEG
to
this
printer,
but
in
the
worst
case
it
can
send
a
raster
image
and
the
printer
will
print
it.
So
the
underscore
Universal
subtype
of
IPP
is
the
subset
of
IPP
printers
that
also
implements
URF.
A
So
now
get
on
to
how
you
can
use
this,
it
is
included
I'm
sure
everybody
knows
in
Mac,
OS
and
iOS,
and
has
been
for
more
than
15
years.
Most
Linux
distributions
include
the
avahi
LGPL
implementation,
Android
started,
including
it
in
2012
and
Windows
10
in
2015
added
their
own
native
DNS
service
discovery.
Ap
is
the
best
way
to
get
started.
If
you
just
want
to
play
with
this
and
prototype
is
to
use
the
DNS
SD
command-line
tool
which
is
installed
on
Macs.
A
A
This
is
not
intended
for
you
to
embed
it
in
scripts
and
use
it
in
production
software,
but
as
a
quick
and
easy
way
to
kick
the
tires
and
see
whether
this
works
for
you,
it's
a
very
low
overhead
way
of
trying
things
out
and
if
any
of
you
are
interested
in
seeing
this
in
more
detail
afterwards,
we
can
sit
down
and
do
some
experiments
together.
It
supports
the
three
operations.
I
talked
about,
offer,
enumerate
and
use
the
are
option.
A
You
say
the
type
you're
looking
for
in
the
domain
you
care
about,
and
the
result
you
get
back
is
the
list
of
names
and
then
finally,
the
lookup
or
resolve
step
that
you
do
prior
to
connecting
you
tell
it
name,
type
and
domain,
because
that's
what
you
learn
from
the
browser.
What
you
get
back
is
the
target
host
and
port.
A
A
In
terms
of
API
usage,
if
you're
writing
an
application,
we
recommend
that
you
don't
specify
domain
just
past
null
or
empty
string
and
that
lets
the
underlying
system
apply.
The
users
defaults
most
of
the
time
that
will
just
be
local,
but,
as
you
saw
at
the
ITF
meeting,
where
you
get
hints
from
the
network
that,
in
addition
to
local,
there
may
be
other
domains
that
have
interesting
things
for
you
to
find.
If
you
pass
null,
the
system
will
do
the
union
of
all
those
discoveries.
A
So
here
are
some
examples
which,
for
those
of
you
who
have
Mac's
or
windows
with
Bonjour
windows
installed,
you
can
try
these
on
different
terminal
windows,
on
one
machine
or
on
different
machines.
That
example
shows
advertising
a
service
called
test
of
service
type,
underscore
test
browsing
to
find
those
instances
and
finally,
looking
up
the
connection
information.
A
So
that's
how
you
prototype
with
the
command
line
tool
for
programming
you'll
want
to
use
C,
API,
s'
or
Java
or
Python,
or
whatever
language
you're,
using
I'm
going
to
talk
here
about
the
C
API
that
are
defined
in
DNS,
underscore
SD
dot
H.
That
is
what
has
been
used
since
we
started
doing
this
on
Mac,
OS
and
iOS.
If
you
install
MD
and
SD
on
Linux,
it's
the
same
API.
A
Similarly,
when
they
did
their
own
implementation,
they
had
a
slightly
different
API
and
the
documentation
is
there
but
I'm
going
to
talk
about
the
C
API
so
that
I'm
most
familiar
with
here?
This
is
how
you
register
a
service.
There
are
a
bunch
of
parameters.
The
first
parameter
is
actually
an
out
parameter.
That
is
the
result
of
doing
this.
Call.
That
is
a
service
discovery
reference.
There
are
some
flags
which
are
optional.
Typically,
those
are
zero.
You
can
specify
an
interface
index
if
you
want
to
constrain
it
to
one
physical
interface.
A
Again,
normally
you
just
pass
0
you
advertise
on
all
interfaces.
You
specify
the
name
type
domain.
If
you're
advertising
a
service
on
a
different
host,
then
you
can
do
that.
That's
for
proxies!
Typically
don't
be
null.
You
specify
the
port
you're
listening
on.
If
you
have
any
key
value
pairs,
then
you
pass
a
txt
record,
and
this
is
all
of
these
routines.
Take
a
callback
function
which
gives
you
a
synchronous
notifications
of
events.
A
Now,
if
you
compare
this
function
with
the
Browse
function,
you'll
see
a
bunch
of
the
parameters
are
the
same,
but
with
some
missed
out
you
don't
specify
the
name,
because
you
don't
know
the
name
that
you're
looking
for
you,
don't
specify
host
and
port,
but
the
other
parameters
take
the
same
form
and
likewise
for
resolve.
It's
extremely
similar.
A
You've
now
specify
the
name
you're
looking
for,
but
things
like
the
port
and
the
text
record
are
the
results
you
get
when
your
callback
is
invoked.
So
one
thing
you
may
have
noticed
here
is:
all
of
these
calls
are
asynchronous
and
that's
because
networking
is
at
its
heart
asynchronous.
If
you
browse
the
network
for
services
and
the
ethernet
cable
is
not
connected
or
the
Wi-Fi
non-associated
you're
not
going
to
find
anything,
and
it's
not
helpful
for
the
call
to
fail
and
the
application
has
to
then
have
a
retry
loop.
A
Maybe
wait
for
the
configuration
to
change
it's
much
easier
to
have
the
API
just
handle
that.
So
when
you
start
a
call
going,
that
call
will
run
until
you
change
your
mind
and
tell
it
to
stop
and
any
changes
in
the
environmental
configuration
that
happened
during
that
time.
I
just
handled
automatically
the
way
that
a
synchrony
is
handled
because
over
the
years
there
have
been
many
different
models
of
asynchrony
threads
used
to
be
in
fashion,
but
it
can
be
difficult
to
get
that
right
with
race
conditions.
A
A
The
way
you
integrate
this
into
whatever
system
you're
using
is
you
extract
the
underlying
file
descriptor
from
this
SD
reference
object,
and
then
you
add
that
file
descriptor
to
whatever
your
event
handling
mechanism
is
and
then,
when
you
get
notified
that
there
is
data
readable
on
that
file,
descriptor,
you
call
DNS
service
process
results.
It
will
parse
that
data
and
call
your
callback
function
as
appropriate.
A
If
you
get
the
open
source,
M&F
responder
codes,
that
I
pointed
you
to
earlier,
then
in
there
is
the
source
code
for
the
DNS
SD
command,
and
that
is
a
great
source
to
crib
little
code.
Snippets
for
the
thing
that
you
want
to
do.
The
the
main
function
of
that
is
basically
a
big
switch
statement
for
each
of
the
operations,
and
you
just
pick
the
case
in
that
switch
statement.
That
applies
to
what
you're
doing
and
that
will
show
you
how
to
register
browser
resolve.
A
A
synchrony
is
really
important
for
a
good
user
experience
and
you
may
notice
that
you
will
not
find
a
refresh
button
anywhere
in
any
of
the
network,
browsing
API,
a
UI
that
Apple
ships
and
that's
because
it
simply
calls
the
API.
The
Browse
call
runs
asynchronously
as
things
come
and
go,
the
results
are
updated.
If
you
do
a
browse
with
no
networking,
you
find
nothing
you
associate
with
Wi-Fi.
You
find
some
results.
You
turn
Wi-Fi
off.
Those
results
go
away
again.
A
If
you
roam
to
a
different
access
point,
then
the
old
results
go
away
and
new
results
are
discovered.
This
continuous
change
monitoring
will
happen
indefinitely
for
as
long
as
you
leave
that
browser
running
for
hours
days
weeks
in
principle,
if
you
can
write
an
application,
please
don't
browse
for
weeks,
that's
really
hard
on
the
network,
but
if
you
did
it
would
work.
A
The
asynchronous
results
are
worth
mentioning
in
a
bit
more
detail.
They
also
give
us
something
really
useful
for
free,
and
that
is
event
notification.
There
are
many
systems,
then,
in
addition
to
everything
else,
they
have
a
completely
separate
publish/subscribe
mechanism
for
events.
Well,
we
don't
need
that
because
having
the
ability
to
do
continuous
operations
that
are
updated
as
the
environment
changes
means
that
those
give
us
notifications
as
well.
So
here
is
an
example.
You
have
some
service
on
the
network.
A
It
registers
its
service
to
published
on
the
network
as
date
Rebeck
that
service
changes,
let's
say
the
ink
level
in
the
printer
or
the
paper
in
the
paper
tray.
It
can
call
DNS
service,
update
record
to
update
its
text
record
with
new
data
and
a
client
that
wants
to
be
informed
of
those
changes
as
they
happen,
uses
DNS
service,
query
record,
which
is
not
a
one-shot
query.
It's
an
ongoing
monitoring
operation.
A
It
will
continue
giving
you
callbacks
until
you
cancel
it,
and
that
would,
for
example,
allow
a
client
to
monitor
the
ink
level
of
the
printer
and
see
it
going
down
over
time
without
having
to
continuously
Paul
every
five
minutes
or
every
five
seconds
to
find
out
the
data.
So
if
you
need
something
like
this,
this
is
an
incredibly
simple
and
powerful
mechanism.
A
This
works
for
both
local
and
remote
services
for
local
services.
When
the
publisher
updates
the
record,
a
multicast
announcement
is
sent
out
to
all
the
peers
on
the
local
network
and
listening
clients
get
a
callback
notifying
them.
The
remote
case
is
more
interesting
and
this
was
more
work
to
build.
A
So
some
tips,
if
you're,
building
browsing
UI,
you
don't
need
a
refresh
button.
We
really
request
that
you
don't
leave
browse
operations
running
indefinitely.
There
is
a
temptation
when
your
application
launches
to
start
a
browser
in
the
background
and
keep
it
running
so
that
you
keep
a
data
structure
in
memory
hot
just
in
case
the
user
wants
it.
That
is
very
expensive
on
the
network,
particularly
Wi-Fi
multicast
on
Wi-Fi
is
very
inefficient
and
very
slow
and
consumes
a
lot
of
airtime.
A
Unicast
Wi-Fi
goes
up
tens,
hundreds
in
theory
up
to
1.3
gigabits
per
second
and
higher.
Now
with
Wi-Fi.
Six
multicast
is
down
at
the
single
digit
1
to
6
megabits
per
second.
So
a
single
multicast
takes
as
much
airtime
as
100
unicast
s'.
It
is
very,
very
expensive,
so
casually
browsing
in
the
background
can
consume
a
lot
of
shared
network
resources.
So
the
better
way
to
do
it
is
if
the
user
brings
up
a
browsing
UI,
for
instance,
they
tap
the
air
print
button.
That's
the
time
to
start
browsing
show
the
results.
A
So
we
really
recommend
that
you
bring
up
a
window
showing
brows
results
rather
than
displaying
it
in
a
menu
that
then
shuffles
around
underneath
the
user's
mouse,
and
the
final
step
is
that
there
is
a
very
deliberate
conscious
reason
that
we
have
the
three
basic
operations
use
enumerate,
offer
user
numerate.
They
are
they're
separated
so
that
they
can
be
done
separately.
The
enumerate
step
will
find
everything
on
the
network
and
show
the
use
of
the
names.
A
At
that
point,
you
don't
need
to
look
at
the
IP
addresses
because
the
user
hasn't
chosen
which
one
to
connect
to
yet
or
in
the
case
of
software.
The
software
client
hasn't
chosen
which
one
to
connect
to.
So
it's
only
when
you
actually
want
to
connect
that
you
then
look
up
the
address
for
that
particular
service.
A
In
many
cases,
you
browse
the
network
to
find
something.
So
the
familiar
example
is
setting
up
a
printer.
You
go
into
the
printer
preferences,
you
click
plus,
you
add
a
printer,
some
tips
here.
We
have
seen
people
make
this
mistake
when
you
find
the
printer,
if
you
saved
the
IP
address
well
with
DHCP.
That
might
be
a
different
address
tomorrow.
A
If
you
save
the
address
and
port
well
with
dynamic
ports,
the
port
number
might
be
different
tomorrow.
So
the
right
way
to
think
about
this
is
late.
Binding
store,
the
name,
type
domain,
tuple
of
the
service
that
were
selected
and
then
at
time
of
use.
You
look
that
up
to
the
current
address
and
port.
That's
in
use
at
that
moment
in
time.
A
A
A
But
if
you
browse
the
network
and
resolve
everything,
you
find
you're
finding
all
the
information
about
all
the
services-
and
that
is
a
very
expensive
operation,
especially
as
I
said
on
a
shared
network
like
Wi-Fi,
where
you're
consuming
everybody
else
has
shared
resources.
To
look
at
this
information
that
you
probably
won't
need.
A
Another
thing
to
note
is
when
you
resolve
modern
devices
may
have
multiple
addresses.
They
may
have
v4
and
v6.
They
have
may
have
link
local
and
larger
scope
addresses
and
if
you
just
take
the
first
one
and
that
doesn't
work
and
then
you
fail,
that's
not
a
good
user
experience.
We
have
known
this
for
a
few
years.
Now
we
highly
recommend
you
follow
the
guidance
for
happy
eyeballs.
A
A
You
simply
tell
it
the
service
name,
type
and
domain
you
want
to
connect
to
and
it
will
handle
resolving,
getting
asynchronous
results,
sorting
the
candidates
into
a
logical
order
trying
each
address
in
turn
if
it
doesn't
get
an
acknowledgement
after
some
number
of
milliseconds
moving
on
to
start
a
second
parallel
connection
attempt
to
the
next
candidate
and
so
on.
So
we
really
recommend
you
use
api's
that
implement
happy
eyeballs.
It
gives
a
much
better
user
experience.
A
So
this
is
the
point
where
I
often
have
people
say
this
doesn't
sound
so
hard.
We
can
just
we
invent
our
own
broadcast
protocol.
We
don't
need
to
use
this
and
I
understand
why
it
seems
that
way,
because
it
doesn't
seem
like
it's
very
hard.
You
you
broadcast
some
packets.
You
listen
you
answer
and
when
we
started
this,
it
didn't
seem
that
hard
appletalk
did
name
binding
protocol.
We
thought
we'll
do
the
same
thing
a
year
or
two
work.
A
A
One
obvious
one
is
that
Wi-Fi
is
very
lossy,
so
you
have
have
retransmission.
Okay,
no
big
deal.
Everybody
knows
retransmission
an
exponential
back-off.
There
are
questions
about
how
you
tune
and
tailor
that
to
give
the
right
performance,
Wi-Fi
multicast
is
also
very
slow.
So
we
have
a
lot
of
techniques
to
maximize
the
efficiency
of
how
we
use
the
network.
One
is
if,
if
you
do
a
multicast
query
for
IPP
printers
and
I
see
it,
then,
because
all
the
responses
are
sent
by
multicast
and
I,
see
those
responses
and
I
opportunistically
cache
them.
A
If
you
do
a
query,
I
will
see
the
same
answers
you
do
so.
If
later
the
user
on
this
iPhone
presses
the
air
print
button,
we
don't
need
to
do
another
browse
because
I
got
to
piggyback
on
the
Browse
that
you
did
and
I
already
have
the
results.
So
duplicate.
Query
suppression
prevents
multiple
devices
on
the
network
from
doing
the
same
query
to
minimize
network
traffic.
A
We
have
long
cache
lifetimes
so
once
you've
seen
something
it
stays
in
the
cache
for
a
long
time
now,
I'll
come
back
to
how
we
manage
that
because
of
retransmission
there.
If
you
do
it
naively,
every
time
you
retransmit
you
get
the
same
set
of
devices
answering
so
you
say:
I'm
looking
for
IP
printers
and
you
get
10
replies.
Well,
there
might
be
packet
loss,
maybe
there's
one
that
you
missed
so
Yuri
transmitted
and
you
get
the
same.
10
replace
and
Yuri
transmit
and
you
get
the
same
can
replace.
A
This
is
very
wasteful,
so
the
queries
include
known
answer
lists
which
in
effect
say
this
is
what
I'm
asking
for
this
is
what
I
already
know.
So,
if
you're
in
the
list,
you
can
keep
quiet,
is
there
anybody
else
that
I
missed
I,
don't
know
any
other
discovery
protocol
that
implements
known
answer?
Suppression,
there's
also
duplicate
answer
suppression
which
comes
into
play
when
you
have
proxies
now
for
various
fault,
tolerance
and
reliability,
reasons
and
other
reasons.
A
I'll
come
to
later,
you
can
have
proxies
on
the
network
that
answer
on
behalf
of
other
devices
and
you
can
have
multiple
proxies,
but
you
don't
want
them
all
answering.
So
the
answers
are
delayed
by
a
random
interval
and
the
answering
devices
also
listen
for
answers.
So
if
they
were
planning
to
answer,
but
then
they
see
the
same
answer
come
from
somebody
else,
they
can
suppress
their
own
answer.
So
this
is
another
one
of
the
techniques
that's
used
to
minimize
the
amount
of
multicast
traffic.
A
Now
I
talked
about
the
exponential
back-off
for
queries.
Again,
if
you
do
this
naively,
you
get
a
very
poor
user
experience,
because
you
query,
you
query
again:
you
wait
a
bit
longer.
You
query
again,
you
wait
even
longer
pretty
soon.
It
settles
down
to
a
quiescent
query
rate
of
no
more
than
one
query
per
hour.
A
A
Another
aspect
is
we
manage
name
uniqueness,
which
is
why
you
don't
need
to
have
names
unique
from
the
factory.
You
don't
need
MAC
addresses,
you
can
have
simple
names
and
if
the
name
is
detected
already
in
use,
then
the
API
will
rename
your
service
with
a
two
at
the
end
or
if
you
prefer,
it
will
call
your
callback
function
and
give
your
code
the
opportunity
to
pick
a
new
name.
A
So
I
talked
about
the
long
cache
lifetimes.
This
is
good
for
efficiency,
but
it's
not
good
when
things
go
away
now,
if
a
service
shuts
down
cleanly,
it
sends
goodbye
packets
on
the
network,
but
suppose
the
power
fails.
Then
it
goes
away
without
saying
it's
going
away
and
that
data
will
remain
in
caches
now,
as
long
as
the
user
doesn't
try
to
use
the
service,
that's
kind
of
benign
it's
sort
of
like
if
the
tree
falls
in
a
forest
and
nobody's
there,
do
they
care.
A
But
at
the
moment
that
user
actually
tries
to
use
that
service
and
it
doesn't
work,
that's
when
they
get
frustrated
and
if
they
get
an
error,
saying
can't
connect
and
they
go
back
to
the
browser
and
it's
still
there.
Then
they
get
really
frustrated.
So
we
do
this
lazy
cache
cleanup
where,
if
there's
a
connection
failure
we,
even
though
the
cache
record
might
have
45
minutes
to
go,
we
decide.
We
don't
trust
that
and
we
do
a
couple
of
queries
and
if
it
doesn't
answer,
we
remove
it
prematurely
from
the
cache.
A
So
by
the
time
the
user
goes
back
to
the
Browse
UI.
That
thing
has
disappeared
and
they
at
least
now
have
a
mental
model
of
what
happens.
They
think,
oh
somebody
just
turned
it
off
and
they
walk
down
hall
and
find
the
printers
turned
off.
Well,
that's
nest,
not
necessarily
true.
Maybe
it
wasn't
just
turned
off.
Maybe
it
was
turned
off
half
an
hour
ago,
but
it
doesn't
matter
because
the
user
at
least
has
a
mental
model
about
what
happened
and
what
to
do
about
it
that
isn't
frustrating
a
refinement
beyond.
A
That
is
that
if
you
try
to
print
and
fail
and
remove
the
printer
from
your
list,
because
it's
turned
off
I
passively
eavesdrop
on
that
transaction,
I
see
you
querying
I
see
no
response.
Coming
back,
I
update
my
cache
as
well,
so
one
user
discovering
that
something
is
not
visible,
serves
to
inform
all
the
devices
on
the
network
to
update
their
caches.
So
this
is
how
we
get
rapid
addition
and
removal
of
entries
without
a
high
burden
of
polling
on
the
network
and
then
a
final
thing.
That
is
really
important.
A
If
you
want
a
good
user
experience
is
mobility.
When
you
put
a
device
to
sleep,
it
sends
goodbye
messages,
saying
its
services
are
no
longer
available
with
an
asterisk
I'll.
Come
back
to
that
and
when
you
wake
it
up
it
renounces.
When
you
change
your
connectivity,
then
it
reissues
queries.
It
renounces
services,
and
that
includes
even
subtle
cases
where
you
roam
to
a
different
access
point.
You
may
be
on
the
same
Wi-Fi
network
name
with
this
same
IP
address
and
the
same
default
router
address.
A
But
if
you
switch
access
points,
the
multicast
domain
you're
in
may
be
different
with
a
different
set
of
services
handling.
All
of
these
things
in
your
own
code
is
really
subtle,
which
is
why
you
benefit
if
you
use
a
very
mature
implementation
that
has
done
all
these
things.
I
said
the
little
asterisk
about
going
to
sleep.
One
of
the
things
that
we
support
is
a
sleep
proxy,
so
you
can
have
a
device
if
it
supports
wake-on-lan
when
it
goes
to
sleep,
it
notifies
a
sleep
proxy
of
what
its
services
are.
A
What
its
name
is,
what
port
it
listening
on
and
that
sleep
proxy
can
then
act
on
its
behalf
and
wake
it
up
on
demand
that
way,
you
can
have
devices
that
offer
services
on
the
network
that
are
available
even
when
they're,
asleep
to
save
power,
and
finally,
using
these
existing
api's
gives
you
remote
discovery
like
we
use
at
the
IETF.
It
also
allows
discovery
via
this
thing
called
the
discovery
proxy,
which
I'll
mention
so
here's
the
example
I
was
talking
about
with
a
sleep
proxy.
A
You
may
have
a
USB
printer
plugged
in
with
printer
sharing,
but
the
Macs
are
sleep,
the
sleep
proxy
on
the
network,
answers
on
its
behalf
and
wakes
it
up
when
the
client
wants
to
talk
to
it.
A
discovery.
Proxy
is
what
lets
you
do.
Discovery
of
legacy,
multicast
DNS
devices
from
multiple
hops
away.
Now,
if
this
phone
on
the
Left
sends
multicast
queries
on
the
local
link,
it's
not
going
to
find
the
printer,
because
it's
not
on
the
same
link.
A
Now
at
the
IETF
we
have
expert
volunteers
who
run
the
network
and
the
DNS
and
the
Amanar
you
put
the
records
in,
but
for
normal
users.
We
want
to
automate
this
and
that's
what
the
discovery
proxy
does.
It
acts
like
an
authoritative,
DNS
server,
except
when
the
client
sends
it
a
query.
Instead
of
consulting
a
zone
file
that
was
typed
in
by
hand
by
an
administrator,
it
uses
multicast
DNS
on
the
local
link
to
discover
what's
available
and
then
uses
that
to
generate
the
unicast
answer
back
to
the
client.
A
So,
using
that
we
wouldn't
need
the
NOC
volunteers
at
the
IDF
to
manually
manage
these
records
so
to
wrap
up.
There
are
some
links
in
the
PDF
that
you
can
download.
If
you're
making
a
hardware
device,
then
I
strongly
recommend
you
do.
Link
local
addressing
here
are
the
RCS
that
tell
you
how
to
do
that
for
v4
and
v6.
A
There
is
a
bunch
of
new
work
going
on
the
wide
area.
Unicast
registration
builds
on
DNS,
dynamic,
updates,
with
an
addition
that
Ted
Levin
has
been
working
on
called
Service
registration
protocol,
which
basically
builds
on
DNS
updates
by
using
6/0
public
keys
to
give
a
really
low
overhead,
simple
first-come,
first-served,
but
secure
naming
system
where
any
device
can
claim
a
name
but
having
claimed
it
and
installed
the
key.
It
gives
you
some
protection
against
some
other
device
coming
along
later
and
masquerading
as
that.
A
Dns
stateful
operations
is
the
foundation
for
the
query.
Side
features
we've
been
building,
and
that
includes
push
notifications
for
asynchronous
change,
delivery
and
the
discovery
proxy
which
lets
you
automate.
This
export
of
local
multicast
dns
information
to
the
wider
space,
and
if
this
seems
like
a
mountain
of
information,
you're
right,
it
is
the
final
link.
There
is
the
roadmap
documents
which
gives
you
an
overview
of
how
all
these
pieces
fit
together.
A
You
can
get
the
source
code
from
the
ITF
hackathon
github
page,
that
includes
the
source
code
for
the
command-line
tool.
There
is
a
great
tool
called
discovery,
which
is
a
graphical
version
which
is
a
free
download
from
the
Mac
App
Store
and
then.
Finally,
if
you're
building
a
hardware
products,
you
can
get
the
Apple
Bonjour
conformance
test
for
free
and
run
that
to
validate
your
design,
because
that
is
designed
to
catch
many
of
the
common
implementation
mistakes
we've
seen
over
the
earth.
A
So
the
action
here
is,
if
you're
writing
a
piece
of
software
that
currently
expects
the
use
of
the
type
in
a
name
or
an
IP
address.
You
can
carry
on
doing
that,
but
add
a
button
for
browsing
as
well,
so
the
user
can
pick
from.
What's
available,
if
you're
building
a
hardware
product
do
link
local
addressing
because
that
what
gives
your
product
bulletproof
reliability,
even
when
things
like
DHCP,
are
not
available
and
use
the
conformance
test
as
a
verification,
so
that
is
the
end.
A
B
Sorry,
no
questions
yeah
the
first
one
actually
is.
If
our
ten
printers
right
bring
at
the
same
time,
they
will
rename
it
their
name.
If,
on
you,
know,
one
to
two
hundred
ten,
yes,
but
how
physically
you
can
identify,
which
printers
with
printer
printer,
you
can
print
a
test
page
which
physically
a
pizza
but
for
IOT
devices.
How
can
do
that
is
only
the
way
is
Madras
right.
B
A
A
There
are
a
couple
of
ways
this
is
done
in
practice.
One
is,
if
you
buy
a
device
and
then
buy
another
one,
the
next
one
is
number
two
and
then,
if
a
week
later,
you
buy
another
one,
that's
number
three.
So
simply
by
virtue
of
the
fact
that
you
had
two
device
on
the
network-
and
you
add
a
third
one,
and
now
you
have
a
device
number
three
on
the
network.
Well,
the
one
you
just
added
is
device
number
three.
So
in
many
cases
that
is
not
confusing.
A
If
you
are
getting
10
things
or
a
hundred
things
out
of
a
box
all
at
the
same
time
in
connecting
them,
then
you
are
absolutely
right
in
case
the
service
discovery
protocol
is
not
going
to
tell
you
which,
as
which,
in
the
case
of
IOT,
there
is
typically
I
know
with
the
home
kit.
Stuff
is
what
I'm
familiar
with,
but
there
are
many
IOT
home
automation,
building,
automation,
protocols.
There
is
normally
a
command
to
have
a
device,
identify
identify
self
by
blinking
a
status
light.
A
So
in
your
list
of
things,
if
you
see
number
three
and
you
click
identify,
you
see-
which
one
has
the
light.
Blinking
I
still
think
that
saying
device
number
three
and
seeing
the
light
is
blinking
and
maybe
getting
a
post-it
note
and
putting
a
three
on
it
is
easier
than
putting
a
12-digit
MAC
address
on
it
and
then
having
to
somehow
remember
all
those
MAC
addresses
in
your
head
and
remember.
This
is
often
only
the
bootstrap
step.
This
is
the
out-of-the-box
configuration
what
you
typically
do
with
a
bunch
of
IOT
devices.
A
Is
you
give
them
names
like
bedroom
light
switch
downstairs
hallway,
you
don't
know
user
wants
to
see
a
list
of
MAC
addresses
in
their
home
automation,
application.
They
want
to
see
descriptive
names,
so
so
that
is
a
case
of
the
out-of-the-box
configuration
step
and
then
to
answer
your
second
question:
what
happens
when
you
replace
it?
That
is
an
excellent
example,
say
printer
number
five
breaks
and
you
go
out
and
you
replace
it
with
an
identical
printer
because
you
love
the
printer.
It
was
great
that
the
employees
in
your
company
loved
it.
A
We
just
want
another
one,
the
same
you
buy
one
exactly
the
same,
you
give
it
the
same
name
through
its
web
UI
or
whatever
configuration
tool.
You
put
it
on
the
network
and
then
because
the
names
are
the
primary
identifier
they
could.
They
identify
the
logical
service
on
the
network.
Then
the
employees
come
to
work
next
day
and
they
print
on
printed
number.
A
Five
and
prints
number
five
answers
and
the
paper
comes
out
and
the
fact
that
the
atoms
have
been
replaced
with
new
atoms
doesn't
change
the
fact
that
the
service
is
providing,
which
is
printing
paper
in
the
copy
room.
On
the
third
floor,
that
service
is
the
same,
even
though
the
physical
thing
has
changed
and
being
able
to
give
a
new
thing,
the
old
name,
so
it
takes
over
that
role
on
the
network
is
a
really
useful
capability.
A
C
Isn't
even
a
question,
it's
mostly
a
comment
as
Stuart
said
seriously,
registration
is
easy,
don't
be
intimidated
by
the
Ayane
format
you
have
to
fill
out,
but
please
don't
please
be
sure
that
all
you
need
is
a
service
name.
Just
ask
the
service
name.
Don't
also
ask
for
the
port.
You
save
yourself
a
lot
of
hassle.
A
Yes,
I
that
the
foremast
lots
of
questions
ports
are
in
short
supply.
If
you
ask
for
a
well
known
port,
expect
a
grilling
about
why
you
need
it.
If
you
leave
the
port
number
blank
and
say
I
want
a
service
type
you'll
get
a
a
big
cheers
from
from
my
honor
saying,
thank
you
for
not
wasting
a
port
number
and
you'll
get
a
very
rapid
confirmation
of
your
allocation.