►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
My
talk
will
be
about
the
decentralized
nut
hole
punching
and
it's
especially
about
the
measuring
the
dc
utr
success
rate
dc
otr
stands
for
direct
connection
upgrade
through
relays,
and
I
will
get
to
this
in
a
second
in
this
talk.
I
will
briefly
describe
well
not
really
briefly,
but
I
will
describe
how
the
whole
punching
process
works
in
the
scope
of
the
peter
p
and
then
we'll
lie
out
how
we,
how
our
measurement
setup
looks
like
and
how
we
do,
how
we
want
to
measure
the
success
rate
of
these
hole
punches.
A
A
First
of
all,
big
shout
out
to
max
who
has
already
done
two
excellent
talks
on
whole
punching.
The
first
one
is
in
foster.
I
highly
recommend
that
one,
if
you
want
to
dive
really
deep
into
the
technical
details
and
in
the
protocols
and
so
on
and
another
one
in
in
paris
where
I
also
was
lucky
enough
to
be
part
of
this
talk
so
highly
recommend
both
of
them.
If
we
want
to
have
more
information
than
I'm
about
to
present.
A
So,
what's
the
motivation
behind
hole
punching,
we
want
to
have
full
connectivity
among
all
nodes
of
the
p2p
network,
despite
nets
and
firewalls,
and
the
requirements
for
us
are.
We
don't
want
to
have
any
centralized
infrastructure,
it
should
work
with
quick
and
tcp
and
also
maybe
webtrend
webrtc,
and
it
should
nicely
integrate
into
the
lib
p2p
stack
so
in
general,
what
are
nets
and
firewalls
just
a
brief
introduction.
A
A
A
A
A
And
for
this
I
will
now
explain
the
dc
utr
protocol.
So
this
is
what
lipid2p
uses
to
facilitate
this,
this
whole
punch
mechanism,
and
for
this
we
need
a
relay
which
is
publicly
reachable,
and
so
this
works
as
follows:
plb,
on
the
right
hand,
side
first
of
all
detects
that
it's
behind
the
net
and
is
not
publicly
reachable.
It
connects
to
relay
and
requests
something.
That's
called
or
reserves
a
spot
on
this
on
this
relay.
A
So
pure
beef
searches
for
like
any
relay
any
real
limited
relay,
gets
a
reservation
at
this
relay.
That's
how
it's
called
and
also
then
has
some
a
multi
address
that
looks
like
this.
The
smart
address
is
passed
to
peer
a
through
some
other
means
or
pa
gets
gets
to
know
this.
This
other
multi
address
npra
also
connects
to
this
relay
and
asks
this
relay
hey.
Can
you
facili?
Can
you
forward
traffic
for
me
to
this
pb
and
with
in
this
case
right
now?
A
So
pb
sends
out
this
connect
message
and
starts
a
timer
to
measure
the
round
trip
time
which
will
become
important
in
a
second.
This
connect
message
gets
routed
through
the
relay
ends
up
at
pier
a
pa,
receives
this
connect
message
and
sends
its
another
connect
message
back
this.
This
connect
message
in
turn
contains
the
multi
addresses
of
peer,
a
like
the
the
publicly
reachable
ones
like
public,
ips
and
por.
A
Any
of
these
events
have
occurred.
Both
start
this
whole
punch,
as
previously
they
try
to
connect
each
other
simultaneously.
The
routers
update
their
state
tables.
They
pass
paths
somewhere
in
the
internet,
not
depicted
here
right
now.
The
packets
pass
through
both
routers.
They
look
at
the
state
tables,
everything's,
fine
and
both
are
connected.
So
this
is
like
in
a
nutshell,
how
this
yeah,
how
this
whole
point
or
like
this
direct
connection,
upgrade
through
relay
protocol
works.
A
A
So
how
do
we
measure
it?
And
if
I
said
it's
deployed,
we
can
have
a
look
at
the
agent
version
uptake
janus
also
already
showed
one
of
these
graphs
earlier
today.
This
is
one
of
the
more
recent
time
frames
here,
so
we
have
the
on
the
x-axis
we
have
the
date
and
on
the
y-axis,
the
number
of
dht
server
peers
and
each
line
corresponds
to
one
of
these
most
recent
agent
versions
from
0
14
to
0
10.
A
and,
as
you
can
see
after
the
go,
it
still
says:
go
ipfs,
but
after
kubo
version
0.13
was
released.
There's
a
steady
increase
of
phd
server
appears,
and
this
roughly
corresponds
to
a
rate
of
one
new
dhd
server
period
per
hour,
and
our
first
idea
was:
we
could
just
use
this,
so
this
is
from
also
from
network
crawls.
We
could
just
use
these
network
rows
and
the
peers
that
we
detect
through
these
crawls
to
just
hole,
punch
them
every
yeah.
A
Every
time
we
detect
a
new
one,
we
can
just
like
try
to
hole,
punch
them
and
try
to
create
a
direct
connection.
However,
these
are,
as
I
said,
dh
server
piece
and
they
are
already
publicly
reachable,
and
so
we
need
a
way
to
find
peers
that
are
behind
nets,
which
is
actually
quite
hard
to
do,
because
they
we
cannot
reach
them
and
we
can
actually
not
see
them
from
the
internet,
and
for
this
we
have
another
setup
which
I
will
get
to
in
a
second.
We
have
this
repository
here.
A
A
Everything
that
I'm
about
to
present
is
there
also
the
analysis,
code
and
yeah,
so
the
components
for
our
measurement
setup
consist
of
a
honeypot,
a
server
and
a
set
of
clients,
and
I
think,
maybe
the
most
interesting
ones.
One
is
the
honey
pot.
As
I
said,
we
cannot
see
peers
behind
nets,
so
we
need
a
way
to
attract
peers
behind
nets,
to
connect
to
us
so
that
we
can
detect
them
and
can
try
to
via
facilitate
a
hole
punch
with
them.
A
So
these
honeypots
are
just
usual
dht
server,
peers
that
we
are
currently
running
on
on
one
of
our
servers.
They,
what
the
only
thing
that
they
do.
Is
they
announce
it's
themselves?
Well,
we
only
have
one,
so
this
honeypot
only
announces
itself
to
the
network,
and
it
does
that
by
walking
the
dht.
This
means
the
same
methodology
that
the
crawler
is
using.
A
So
it's
just
enumerating
the
dht
quite
slowly
and
it's
a
very
stable,
pier
and
the
hope
is
that
we
pass
by
every
dht
server
appear
in
the
network
and
since
we
are
stable,
we
get
like
the
honeypot
gets
inserted
into
the
routing
tables
of
these
other
remote
peers,
so
that
when
peers
behind
nets
want
to
interact
with
the
dht,
they
get
routed
to
our
honeypot.
And
this
way
we
can
over
time
get
to
know
a
lot
of
clients
that
are
behind
nets.
So
that's
the
idea
and
the
sunny
part
if
it
detects
a
inbound
connection.
A
A
So
you
could
query
the
server
for,
or
the
in
the
server
creates
the
database
for
these
peers
that
we
have
detected
that
are
behind
nets
and
after
we
have
done
a
hole,
punch
or
perform
the
whole
punch,
we
can
also
track
the
results
back
and
then
the
clients.
On
the
other
hand,
we
have
one
in
rust
and
one
and
go
and
another
shout
out
again
to
max
and
also
eleanor
who
is
working,
who
has
been
working
on
these
on
the
rust
implementation
of
these
clients.
A
It
tries
to
connect
to
to
these
peers
that
are
behind
nets,
and
if
this
was
successful
or
not
it
just
reports
back
the
the
outcome
of
this
whole
punch.
The
architecture
roughly
looks
like
this.
As
I
said,
the
honeypot
walks
the
dht
and
by
walking
the
adhd
we're
increasing
the
chance
that
pierce
dcgtr
capable
piers
behind
nets
connect
to
the
honeypot.
A
As
soon
as
we
get
the
inbound
connection,
it
saves
the
connection
to
the
database
and
the
server
just
exposes
the
data
from
the
database
to
the
clients
and
the
clients
actually
do
the
whole
punches
and
reports
back.
The
outcomes
did
I
forget
any
something
I
don't
think
so:
yeah,
okay
and
yeah
we're
monitoring
all
of
that.
Well,
we're
not
monitoring
the
clients
specifically,
but
the
honeypot
and
the
server
component
and
yeah
you
can
find
it's
publicly
accessible.
You
can
find
it
under
this
url
on
the
right
hand,
side.
A
The
conditions
are
that
this
the
clients
are
support
the
dc
otr
protocol
and
that
they
actually
listen
on
a
relay.
So
these
are
the
two
conditions
for
for
that,
and
now
I
think
probably
the
most
interesting
graph
is.
How
successful
is
that?
As
I
said,
it's
just
running
on
my
own
personal
home
network
and
I'm
this
client
on
my
home
network
has
performed
roughly
thirteen
thousand
three
hundred
hole
punches
to
two
and
a
half
thousand
unique
peers.
So
every
pier
was
roughly
hole,
punched
five
times,
probably
and
yeah.
A
The
success
rate
is
around
72
percent.
Well,
28
have
failed,
which
is
not
as
good
as
max
says,
for
instance,
reported
in
the
foster
presentation
that
he
reported
a
success
rate
of
90
percent,
but
I
think
I'm
not
I'm
not
sure
about
the
measurement
setup
that
he
was
reporting
on
the,
but
I
think
that
it
was
a
little
bit
more
controlled
than
this
one.
A
This
is
actually
the
success
rate
to
like
random
peers
in
the
whole
ipfs
network,
and
I
think,
if
you
take
this
into
account,
this
is
already
a
pretty
good
success
rate
in
my
opinion,
but
yeah
we
can
talk
about
this
afterwards
and
I
think
also
another
interesting
result
already.
So
if
the
so,
we
are
trying
to
hole
punch
as
another
pier,
but
if
the
first
direct
connection
fails,
we
actually
try
it
a
second
time
and
the
third
time,
and
only
then
we
stop
this.
A
This
whole
punch
attempt
and
as
and
this
shows
this
graph
that
we
could
actually
stop
after
the
first
attempt.
So
in
97
of
the
cases,
the
first
attempt,
if
the
whole
punch
was
successful,
it
was
successful
within
the
first
attempt
and
only
two
and
point
three
percent
and
zero
point.
Four
percent
were
successful
with
the
second
try
or
the
third
try.
So
you
could
argue
that
if
it
doesn't
work
the
first
time
it
won't
work
the
second
or
third
time
either.
A
A
So
this
could
become
a
yeah
interesting
if,
if
performance
becomes
a
problem
at
some
point-
and
also
this
is
a
quick
graph
that
I
created
yesterday,
which
takes
into
account
the
round
trip
time
measurement
and
how
successful
it
is,
depending
on
the
round
trip
time
measurement.
So
I
could
imagine
that
if
I
wanted
to
hole
punch
appear,
so
I'm
not
right
now
on
ice
and
if
I
wanted
to
hole
punch
another
pier
also
in
iceland,
but
the
relay
pier
is,
for
instance,
somewhere
in
australia.
A
We
want
to
know
the
dependence
on
tcp
and
quick
connection,
upgrades
quick
hole
punches,
and
we
also
want
to
compare
the
go
and
rust
implementation
a
little
more
and
also
when
we
deploy
more
clients
to
the
network
or
well
to
to
home
networks.
We
also
want
to.
We
want
to
let
those
clients
to
hold
punches
each
other
so
that
we
have
the
control
about
both
parts
of
the
of
the
hole
punch
appears
and
we
as
yeah.
This
implies
that
we
want
to
deploy
the
clients
to
multiple
or
more
vantage
point
as
right.
A
A
This
form
will
ask
you
for
some
stuff,
like
what
router
are
you
using
and
what
the
network
topology
looks
like
if
you
have
something
to
tell
and
yeah,
because
this
whole
punch
success
rate
depends
a
lot
on
the
type
of
net
that's
using
and
that
the
router
is
using
so
having
information
about
that
will
help
us
later
on.
In
the
data
analysis,.
A
B
A
Right,
yeah
totally.
This
is
something
that
I
wanted
to
show
with
this
graph
that
so
so
this
this
would
be
true
if
the
assumption
holds
that
if
we
have
a
long,
rounded
time
that
the
success
rate
is
lower,
but
this
graph,
as
I
said,
implies
that,
but
it's
not
very
very
clear
that
it's
actually
the
case
yeah
yeah
yeah.
Definitely
we
could
try
yeah
totally.
C
C
Yeah
way
to,
I
don't
know,
make
that
measurement
more
more,
accurate,
perhaps
or
even
like
try
to
dive
deeper
into
you
know
in
these
failure
cases
it
has
been
another
convenient
discrepancy
between
the
equity
measurements
of
the
two
peers
and
when
they
started
sending
their
sim
buckets
and
that's
why
it
eventually
failed
right
and
obviously
the
longer
the
delay
the
further
away.
The
numbers
are.
C
A
I
was
also
about
to
say
that
maybe
it's
also
the
opposite.
I
don't
know
the
thing
with
these
attempts
is
that
each
attempt
has
its
own
round-trip
time
measurement,
so
we've
already
got
three
round-trip
time
measurements,
so
the
first
attack
with
the
first
attempt
we
are
doing
this
connect,
connect,
sync
thing
and
got
one
round
trip
time
measurement,
and
then
we
try
a
hole
punch.
A
A
A
Yeah
my
mind
has
to
go
through
yeah,
but
I
mean
yeah,
even
if
I
knew
the
the
ping
to
this
to
the
router.
I
don't
think
this
will
bring.
This
will
help
me
much
because,
because
of
the
synchronization,
I
still
need
to
so
how
long
should
I
wait
for
the
sync
package
then
to
reach
the
other
peer
again
so.
B
A
D
A
C
A
A
A
Yeah
exactly
so,
this
is
the
these
would
be
the
next
steps
just
to
to
find
out
why
these
fail
and
like
there's
also,
I
think
what
you
honest,
ask
some
failure
reasons,
and
I
can
imagine
that
so
some
some
nets
actually
don't
allow
hole
punching
like
if
you
have,
if
you're,
behind
a
symmetric
net,
for
instance,
this
won't
work.
And
yes,
some
other
reasons,
as
we
just
discussed,
could
be
the
rtt
measurement,
which
is
not
not
quite
accurate
and.
C
A
I'm
not
not
running
it
only
from
my
home
and
and
extrapolating
to
the
whole
network
would
also
be
something
that
yeah
could
change
these
results,
and
but
I
mean,
I
think,
also
janice.
You
also
said
there's
a
couple
times.
This
could
be
a
game
changer
being
able
to
connect
directly
to
peers
behind
nets
in
the
in
the
peer-to-peer
world
and
already
having
72
from
my
from
my
network.
A
A
A
When
pier
a
connects,
oh
hang
on
here,
we
go
so
pra
connects
to
peer
b
through
this
relay
and
pb
notices
that
and
immediately
starts
to
directly
connect
to
a
without
starting.
This
whole
punching
process,
because
before
we
try
to
just
peer
b,
just
tries
to
directly
connect
to
peer
a
with
the
publicly
reachable
ip
addresses
and
then
eventually
times
out,
and
I
think
for
the
tcp
and
quick
transport.
A
The
timeouts
are
five
seconds,
and
only
after
this
time
out,
ump
starts
this
whole
process
by
opening
this
dc
otr
stream
and
sending
the
connect
messages
and
so
on,
and
this
is
also
something
that
I
saw
in
yeah
in
the
data
which
is
just
not
oh,
sorry
not
depicted
here,
hang
on
and
which
could
be
something
that,
instead
of
waiting
for
this
direct
connection,
to
succeed
or
or
fail.
In
this
case,
we
could
also
just
start
the
whole
punch
directly
and
wait
and
raise
raise.
A
B
A
B
A
A
A
The
data
itself
is
just
on
the
server
that
we
are
running,
and
so,
if
you're
interested
I'm
happy
to
dump
the
data-
and
I
think
if
we
want
to
package
this
up
into
like
a
publication,
we
would
also
like,
in
this
into
a
scientific
publication,
would
also
publish
the
data
sets
as
well.
So,
but
it's
not
only
on
github
right
now,.
A
You
mean
how
many
of
these
limited
relays
are
in
the
network
already.
This
is
roughly
visible
in
this
graph.
So,
as
jeropo
said
already,
since
0.11
we've
got
this
limited
relay
capability
and
I
can
imagine,
if
you
add
up
the
numbers
from
0
11
to
zero
field
14,
you
get
a
pretty
accurate
number
of
how
many
relay
servers
there
are
in
the
network
already-
and
this
goes
up
to.
I
don't
know
a
couple
of
a
few
thousand-
probably
maybe
two
or
three
thousand
four
roughly
like
that.