►
From YouTube: Beyond Swapping Bits: Driving speed ups to file sharing in P2P network with Alfonso de la Rocha
Description
Beyond Bitswap author, Alfonso de la Rocha joined to talk about how ResNetLab is diving even deeper into improving Bitswap performance.
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
Hello:
everyone,
I'm
alfonso
larotte,
I'm
a
research
engineer
here
at
protocol
labs
in
the
resnet
lab,
and
today
I
just
wanted
to
share
an
exciting
project.
We
are
running
within
the
resnet
lab,
where
we're
trying
to
drive
up
speed,
to
drive,
speed
ups
in
file
sharing
peer-to-peer
networks
and,
of
course,
trying
to
find
these
speedups.
We
started
with
ipfs.
A
So
when
we
started
the
first
thing
we
did
was
to
do
a
state-of-the-art
evaluation
like
any
other
researchers,
to
try
and
find
ways
in
which
we
could
improve
file
sharing.
But
we
realized
something
that
we
didn't
have
a
way
of
testing
our
ideas.
So,
of
course
we
had
an
infrastructure
with
a
lot
of
ipfs
nodes.
We
could
try
things
locally,
but
we
didn't
have
a
way
of
comparing
the
baseline
with
the
ideas
that
we
were
generating
and
that
we
were
prototyping.
A
So
the
first
thing
that
we
did
was
to
build
a
testbed
to
try
file
sharing
and
a
testbed
that
made
easy
implementing
new
prototypes
of
files
sharing
protocols
and
evaluating
their
performance.
So
if
you
want
to
try
it
it's
here
in
this
repo,
you
will
find
like
a
probe
and
a
test
bed.
The
testbed
is
the
actual
test
round.
A
I
don't
know
if,
if
you
know
tesla,
but
it's
an
awesome
project
within
proto
protocol
labs,
to
test
peer-to-peer
protocols
in
a
really
easy
way-
and
here
you
will
find
all
the
plans
that
we
are
using
to
evaluate
all
of
our
prototypes
and
also
you
will
see
a
python
notebook
dashboard.
That
actually
think
I
have
it
here
so
that
you
can
run
different
tests
over
the
test,
ground,
testbed
and
start
playing
with
your
file
sharing
implementations
over
ipfs.
A
So
within
the
project,
how
we
we
focus
our
methodology
is
in
the
following
way:
we
first.
If
we
come
up
with
an
idea,
we
first
write
an
rfc
so
that
we
open
the
idea
to
discussion
and-
and
we
can
like-
have
a
chat
with
different
people
to
see
if
the
idea
makes
sense
and
once
we
feel
comfortable
with
this
idea,
what
we
feel
is
a
prototype
and
then
a
proper
test
evaluation
over
our
testbed
and
today.
A
Go
to
these
issues
and
open
an
issue,
and
we
can
start
discussion
and
see
how
we
can
onboard
you
into
the
the
project.
But
let's
jump
into
the
rfcs
that
we
have
prototyped.
So
far
as
I've
said
we
started,
I
mean
our
aim
is
to
try
and
improve
file
sharing
in
peer-to-peer
networks
in
general,
but
we've
started,
of
course,
with
ipfs
and
by
starting
with
apfs
we're
starting
trying
to
improve
to
improve
bitstrap.
A
That
is
the
exchange
supermodel
in
ipfs,
and
the
first
thing
that
we
realized
is
that
whenever
you
want
content-
and
you
want
to
get
some
content
from
the
network,
what
your
note
does
is
save
itself
hey.
I
want
to
find
this
c
id
and
it
sent
one
message.
I
request
to
your
connected
peers,
saying
I
want
this
specific
content
and
if
your
peers,
your
connected
peers,
doesn't
have
it,
you
resort
to
the
dht
to
try
and
find
the
guy
that
is
storing
that
cid,
that
block
or
of
that
content.
A
So
we
realized
that
bitstrap
was
not
using
information
from
its
surroundings
to
to
try
and
make
more
efficient
that
look
up.
So
what
we
did
is
our
first
prototype
in
which
we
made
some
bitswap
nodes
that
they
listened
to
every
request
coming
from
their
connected
peers
and
from
the
network
and
keep
a
registry
so
that
the
next
time
they
want
to
find
a
specific
cid
they
would
go.
I
mean
they
would
check.
A
If
someone
had
asked
for
that
cid
before
in
our
surroundings,
because
potentially
then
they
will
have
the
content
and
we
would
directly
request
the
content
from
them
in
this
way,
speeding
up
the
discovery
of
popular
content,
because
if
someone
around
me
have
asked
for
that
content,
I
don't
need
to
float
the
network
with
a
request
of
hey
guys.
I
want
this
content.
A
I
can
go
directly
to
the
guy
that
I
know
that
have
requested
it
before
we
did
with
the
testbed
a
few
preliminary
tests
to
see
how
this
work
and
the
task
test
plan
that
we
designed
for
this
was
a
wave
soft.
So
we
had,
for
instance,
one
seeder
one
ipfs
node,
providing
content,
a
specific
content
and
then
leechers
came
in
waves
requesting
this
content
in
the
baseline
bitstrap.
You
see
here
in
the
left.
You
see
that
the
more
so
subsequent
waves
become
subsequent
leechers
of
the
waves
become
cedar.
A
So
that's
why
we
see
that
the
the
subsequent
waves
have
a
lower
time
to
fetch,
because
they
have
easier
an
easier
way
of
finding
the
content.
But
what
is
cool
to
see
is
how,
when
we're
using
popular
content
and
we're
inspecting
one
messages,
we
can
reduce
a
lot
the
time
to
discover
cids
and
to
discover
who
has
the
content
reducing
the
time
to
discovery
of
bitstrap.
So
this
was
the
first
rfc
that
we
prototyped
and
the
conclusion.
Of
course,
this
is
not
a
perfect
implementation.
A
It
probably
needs
a
lot
of
iteration,
but
the
conclusion
we
had
from
here
is
that
we
can
improve
file
sharing
by
getting
information
from
the
protocol
from
other
protocols
that
we
are
not
using
right
now
to
discover
the
content.
Then
we
said
http
uses
compression.
Why
couldn't
we
use
compression
to
make
files
share
to
make
exchange
in
a
future
pure
network?
So
again,
in
the
scope
of
bitswap,
we
tried
different
strategies
to
see
which
one
led
to
better
results.
A
A
It
wasn't
that
good
either
and
then
we
tried
the
strip
compression
and
we
said
why
trying
to
compress
messages
that,
in
order
to
send
them
through
the
leap
peer-to-peer
transport,
we
need
to
know
the
size
beforehand
and
we
wrap
the
the
liebherr
stream
into
a
compressor.
The
same
way
that
we
do
in
in
jcp
handler
in
http
and
so
that
every
byte
that
leaves
the
the
bitswap
stream
is
compressed.
And
here
is
where
we
found
something.
A
And
actually
what
we
realized
is
that
this
implementation,
it
wasn't
a
protocol
level
compression,
but
a
transport
level
compression
and
after
some
tests
in
our
test
bed
we
say
hey.
It
was
our
aha
moment
and
we
realized
that.
Maybe
if
we
added
compression
to
leap
youtube
peer,
not
only
pizza
could
benefit
from
it,
but
every
single
protocol,
application
building
on
top
of
of
ipfs
could
potentially
benefit
from
using
compression.
A
So
we
spent
some
time
trying
to
figure
out
where
it
made
sense
to
to
put
compression
in
the
lipid
triple
stack,
and
we
did
a
first
prototype
that
we
finished
last
week,
where
we
added
compression
after
the
muxers,
so
that
every
the
stream
of
bytes
coming
from
every
single
protocol
stream
is,
can
be
compressed
potentially
compressed
and
sent
through
the
transport.
We
are
right
now
running
the
tests
in
the
test,
with
different
data
sets
and
hopefully,
in
a
few
days
we
will
be
able
to
give
some
more
compelling
results.
A
But
if
you
want
to
start
playing
with
compression
and
and
would
you
want
even
to
implement
your
own
compressor,
this
is
a
non-breaking
change,
because
we
implemented
compression
inside
the
transport
upgrader.
Also-
and
you
can,
this
is
the
entry
point
if
you
want
to
start
playing
with
compressional
liquid
superior
again.
This
is
a
prototype.
Probably
it
needs
a
lot
of
intuition
and
feedback.
A
We
can
maybe
jump
one
and
one
note
further
and
find
the
cid
without
without
having
to
resort
to
the
dht.
So
this
is
what
we're
trying
right
now
we
are.
We
have
a
first
implementation,
that
is,
that
can
be
improved,
but
we've
seen
similar
behaviors
in
our
initial
tests
to
the
ones
that
we
are
seeing
with
the
want
message.
Rfc.
But
again,
you
are
more
than
welcome
to
help
us
with
this
and
trying
to
play
with
file
sharing
in
ipfs.