►
Description
Lightning Talk: State of IPFS Public DHT - presented by @guseggert at IPFS þing 2022 - Content Routing 1: Performance - https://2022.ipfs-thing.io
A
Hey
everyone,
I'm
gus,
I'm
a
I'm
a
ipfs
steward.
I
mostly
work
on
kubo,
so
we're
gonna
talk
about
the
the
public
dht
so
to
review.
What
what
juan
was
talking
about.
The
main
functions
of
the
dhc
are
content
or
like
converting
a
sid
into
a
into
a
set
of
peer
ids.
We
actually
look
it
up
by
the
multi-hash
it
also.
The
dht
also
holds
peer
id
addresses
and
ips
records,
and
these
are
the
main
implementations.
A
A
A
So
70
is
kubo
5
of
the
hydros
which
I'll
talk
about
in
a
second
as
well,
so
the
the
hydras
are
something
that
pl
runs
to
help
speed
up
content
routing.
Basically,
we
we
have
a
bunch
of
peer,
ids,
basically
flood
the
whole
network
with
a
bunch
of
peers
that
share
a
database
that
stores
content
routing
records
so
that
a
lot
of
peers
in
the
network
know
a
lot
about
all
the
other
records.
A
A
So
yeah
there's
two
two
main
clients
in
kubo
that
we
use
the
traditional
client,
which
does
you
know
the
lookups
that
one
was
talking
about.
The
logarithmic
cops
and
we've
also
got
the
accelerated
dht
client,
which
caches
the
entire
routing
table
in
memory,
which
means
lookups
are
really
fast
because
you
don't
have
to
do
any
extra
hops,
but
it
also
means
you've
got
to
cache
the
entire
routing
table
in
memory
and
one
of
the
big
downsides
to
that
is
before
it's
even
usable.
A
So
this
this
is
a
stat
that
we
monitor.
That
shows
the
the
time
it
takes
a
random
node
in
the
network
to
look
up
some
content.
You
can
see
over
the
past
year.
We
did
some
work
on
the
hydras,
so
it
went
down
a
lot
but
currently
to
look
up
a
single
record.
It's
about
160
milliseconds.
A
A
So
yeah
that's
with
the
standard
client.
So
if
you
use
the
accelerated
dht
client,
everything
goes
a
lot
faster
once
it's
bootstrapped
because
you
only
have
to
you
only
have
to
make
a
request
to
one
one
peer:
you
don't
have
to
do
hops
and
provides-
or
if
you
do
a
big
bulk
of
provides.
It's
a
lot
faster
too,
because
you
already
know
exactly
who
to
provide
those
records
to
so
yeah.
These
are
some
links.
I
can
send
this
these
slides
out
afterwards,
if
you're
interested
in
looking
at
these.
A
These
are
different
groups
of
people
who
collect
the
metrics
on
the
dht.
So
dennis
has
this
nice
crawler
called
nebula,
or
he
publishes
a
bunch
of
statistics.
I
think
they're
daily
now
about
like
who's
on
the
network
and
how
big
it
is
and
and
different
performance
characteristics
and
then
max
from
the
p2p.
He
he
maintains
the
rust
the
p2p
implementation.
A
I
wanted
to
show
too,
let's
see
so
we
also
have.
This
is
our
grafana
dashboard
for
the
hydras,
so
you
can
get
an
idea
of
this
like
how
much
work
the
hydras
are
doing
so
like,
for
example,
these
are
per
second,
I
believe,
there's,
like
average
requests
per
second,
so
we
you
know,
we
process
a
lot
of
requests
on
the
hydros
millions
per
second-
and
you
can
see
like
down
here,
we've
got
this
is
the
size
of
this.
A
Is
the
number
of
records
that
we've
cached,
so
we've
got
around
a
billion
records
in
the
last
week
that
we've
got
in
our
database.
A
Go
back
here
yeah,
so
we've
still
got
a
bunch
of
work.
We
can
do
on
the
accelerated
dht
client
as
well.
Like
I
mentioned
it
caches
everything
up
front
which
kind
of
sucks,
because
I've
actually
run
it
a
few
times
and
it's
killed.
My
router
because
it
very
aggressively
looks
up
every
peer
in
the
network.
A
Which
is
fine
if
you're
running,
you
know
some
dedicated
infrastructure
for
it,
but
if
you're
running
it
locally
on
your
laptop
or
something
that's,
that's
really
is
painful,
but
I
think
we
can.
We
can
get
a
middle
ground
where,
like
basically
it's
just
a
cache
of
records,
so
we
can
you
know
we
can
we
can
build
this
cache
as
we
go.
We
don't
have
to
do
it
all
up
front.
A
So
that's
that's
one,
one
area
that
we
can
definitely
improve
and
then
there's
a
bunch
of
constants
in
there
that
the
accelerated
dht
client
was.
We
didn't,
spend
a
whole
lot
of
time.
Writing
it.
So
there's
a
lot
of
constants
in
there
that
we
can
research
and
probably
improve
on.
A
A
You
can't
split
apart
the
system
into
two
different,
like
you
can't
say
like
oh,
that
machine
over
there
has
this
this
hash,
and
also
you
can't
like,
if
you
could
like
right
here,
if
you
could
batch,
who
has
it
with
their
addresses,
you
could
reduce
the
chatter
a
little
bit
and
then
there's
a
there's
also.
I
think
we
talked
about
it
earlier
and
in
stand-up.
There's
a
there's,
a
big
look
up
table
that
we
use
for
bootstrapping
the
rowdy
table.
That's
like
400
kilobytes,
that
kind
of
sucks.