►
From YouTube: NEAR Core | Episode 04: Network P2P Connection
Description
Follow the latest from NEAR Protocol on,
Website: https://nearprotocol.com/
Discord: https://near.ai/discord
Medium: https://near.ai/medium
Twitter: https://near.ai/twitter
GitHub: https://near.ai/github
#WhiteboardSeries #Blockchain #FutureIsNEAR
B
B
B
There
is
some
sort
of
distance
between
every
pair
of
nodes
and
messages
are
being
rooted
through
this
network
and
trying
to
decrease
the
distance,
and
ideally
this
will
get
to
the
destination
fast.
In
theory,
this
is
done
with
cadembia.
We
are
doing
another.
We
are
having
another
approach.
We
are
doing
what
is
called
link
state
routine
protocol
and
which
the
idea
is
that
you
keep
each
node
in
the
network.
B
B
This
is
like
what
is
exposing
this
and
wikipedia
pages
the
overall
idea,
but
right
now
we
have
a
big
challenge,
which
is
this
network
is
decentralized
so
applying
naive,
algorithms
link
state,
routine
algorithms
won't
won't
work.
So
this
is
like
the
overall
idea
we
won't
be
discussing
today
about
routine
itself
person.
We
will
be
discussing
about
a
connection
between
pair
of
nodes,
so
I
will
start
by
going
through
the
code
and
discussing
each
part
of
it.
If
you
have
any
question
at
any
moment,
just
let's
try
to
do
this
way.
A
Marcelo,
so
it
seems
according
to
the
sessions
that
max
did
on
runtime.
It
seems
better
that
if
you
just
first
work
through
like
a
maybe
a
reasonable
chunk
of
the
code
or
like
whatever
material
and
then
if
people
have
questions,
they
are
you
stop
afterwards
and
then
let
people
ask
because
otherwise,
from
what
I
heard,
it
didn't
go
as
well,
because
the
progress
got
okay.
B
Let's
just
post
the
questions
in
the
chat
and
I'll
eventually
come
to
them
and
try
to
answer
them,
and
you
can
no
vote
like
that.
Okay,
so
let
me
share
my
visual
studio
code
and
this
is
it
okay?
Hopefully
you
can
see
the
code,
so
I
will
start
by
going
through
what's
relevant
for
networking
most
of
the
code
regarding
networking
light
leaves
in
the
shape.
So
when
you
make
the
window
smaller,
the
text
is
too
small
to
read
okay.
What
about
this?
C
B
B
B
So
yeah
we
set
the
network
adapter,
we
set
it
to
network
actor
and
it's
used
to
communicate
between
each
other.
So
it's
so,
let's
start
going
through
peer
manager
here
inside
the
network,
the
three
main,
the
logic
of
the
network
lives
in
peer
manager.
Rs
peer
peer
manager,
rs,
is
the
one
in
charge
of
control
of
controlling
from
the
from
high
high
level.
You
may
say,
for
it's,
the
one
in
share
of
controlling
network
prs
is
controlling
each
particular
connection
between
our
node
and
other
nodes.
B
That's
prs
and
routing
rs
is
controlling
the
logic
for
routing
messages
through
the
network.
It's
more
low
level,
so
today
we'll
be
discussing
pure
money,
rs
and
prs.
Regarding
connection
between
between
nodes,
we
are
using
overall
linear
for
for
handling
async
computation,
asynchronous
computation.
We
are
using
actics,
which
is
leverage
sharing
in
the
network
code.
Basically,
this
peer
manager
actor
is
itself
an
actor,
including
actor
and
when
the
peer
manager
is
started.
B
So
what
will
initially
happen
is
that
when
peer
manager
actor
is
started,
we
both
create
a
a
listener,
a
server
that
listens
for
incoming
connection,
and
we
start
several
processing
background,
and
the
most
relevant
process
here
is
monitor
peers,
which
will
be
checking
that
we
have
enough
peers
and
health
peers.
We
currently
currently
have
other
processes.
We
can
dig
into
them,
but
are
less
relevant
right
now.
B
B
This
is
this
function
is
called
with
relevant
with
relevant
parameters,
so
here
we
will
check
in
this
function.
If
we
can
actually
establish
the
connection,
we
have
a
certain
criteria
to
establish
a
connection
and
if
it
is
fulfilled,
we
try
to
start
it.
Basically,
let
me
step
aside
from
the
code
like
the
idea
is
that
we
want
to
have
so
for
not
to
be
healthy.
B
We
want
to
have
a
certain
number
of
connections
which,
basically
we
don't
want
to
pass
above
some
number,
because
it's
hard
to
maintain-
let's
say
hundreds
of
connections
right
now.
This
number
is
40,
but
at
the
same
time,
because
this
system
is
decentralized,
we
want
to
have
to
avoid
a
certain
type
of
attacks
such
as
eclipse
attack.
We
want
that
the
number
of
outgoing
connections
connections
created
by
ourselves
is
above
certain
number.
B
These
appear
where,
as
it
says,
this
is
a
set
with
the
with
all
the
peers
which
we
are
currently
connected
to
them,
and
these
are
peers
which
we
are
in
the
process
of
connecting
to
them.
So
yeah
this
okay,
let
me
go
back
a
little
bit.
So
if
this
function
is
is
okay,
we
try
to
connect
to
the
pier.
Otherwise
we
just
reject
that
connection.
B
B
So
this
is
how,
in
incoming
connections
are
created
for
outbound
connections,
let
me
go
to
in
this
process
in
monitor
peers,
which
is
a
process
that
is
running
in
the
background
you
can
check
here
in
the
in
the
end
of
this
function.
This
function
is
called
itself
again
after
some
time
out
which
increase
exponentially
and
after
some
time
it
just
ruined
every
some
period
of
time.
This
is
done
because
we
need
to.
We
want
to
start
fast,
connecting
to
several
peers.
B
So
in
this
function
we
check
for
the
health
of
several
of
of
nodes.
We
check
for
nodes
that
are
banned
and
should
be
unbunny.
Some
time
span
already
passed,
but
most
relevant
I
wanted
to
share
with
you
is
that
if
the?
If
the
note
requires
some
outbound
connections
like
if
we,
this
is
like
total
number
of
connections,
this
is
like
the
idea
here.
This
is
kind
of
complex
complex,
if,
like
the
main
idea,
is
that
we
want
to
have
a
certain
number
of
outgoing
connections.
B
That
is
that
the
number
of
withdrawing
connections
is
above
some
level,
but
at
the
same
time
we
want
the
number
of
connections
to
be
in
some
range,
because
nodes
will
be
connecting
and
disconnecting
between
each
other.
We
will
keep
a
range
of
ideal
number
of
connections
which,
right
now
the
default
is
30
and
35.
B
So
if
the
number
of
connections
is
in
is
in
this
range,
we
will
try
to
create.
So
if
the
number,
if
the
number
of
outgoing
connections
is
below
the
minimum
of
bones,
appears
expected,
we
will.
We
will
try
to
create
a
new
connection
but,
of
course,
always
satisfying
the
number
of
the
maximum
number
of
connections
and
the
ideal
number
of
connections.
But
let
me
like
they
the
the
point
of
having
these
ideal
connections
ranch,
which
is
determined
by
ideal
connections,
low
and
ideal
connections.
B
B
B
Here
regarding
the
ideal
number
of
connections
within
the
ideal
numbers
connection
is
above
some
level.
We
try
to
stop
some
connections,
and
here
we
have.
This
is
a
function
that
implements
several
logistics
to
select
which
connections
are
prefer.
Our
other
connections
like
older.
We,
we
try
to
reserve
like
to
keep
connections
to
older
nodes,
because
those
are
connections
that
have
been
more
more
more
important
in
the
sense
that
we
know
they.
B
They
probably
will
last
longer
and
will
last
longer,
but
at
the
same
time
there
are
other
criteria
such
as
we
want
to
maintain
outbound
connections.
Since
we
don't,
we
need
to
avoid,
we
should
try
to
avoid
being
eclipsed
and,
for
example,
when
nodes
are
archival
nodes
and
they
connect
between
each
other.
We
try
to
keep
those
connections
between,
because
connections
between
them
are
very
heavy,
like
the
the
traffic
between
them
is
very
heavy
and
we
try
to
keep
connections
between
them,
which
are
basically
created
manually,
so
so
yeah.
B
B
B
C
B
B
In
this
process
of
monitoring,
peers
is
but
album
bootstrap
needed.
This,
of
course,
will
will
be
true.
When
you
have
no
connections,
and
then
you
will
start
to
sample
random
peers
from
the
peer
store
which
is
populated
when
you
are,
when
you
start
the,
when
the
peer
manager
is
stuck,
is
started
and.
A
B
B
Is
it
here?
I
have
okay,
good
notes.
Okay,
here
we
have
already
a
list
which
is
loaded
from
json
config,
and
this
is
populate
the
peer
store
with
some
here
we
have
some
logic
about
how
to
maintain
peers
in
the
network.
Most
of
the
logic
is
to
keep
keep
this
persistent
and
safe
from
peers
that
try
to
attack
and
impersonate
other
peers
with
invalid
ip
addresses
and
ports.
B
But
the
point
is
that
we
store
appears
here
and
then
we
sample
from
there
from
the
beer
store
okay.
So
basically,
what
will
happen
is
that
when
we
are
trying
to
create
a
new
connection
either
if
it
is
in
common
or
outcoming
or
outbound
connection,
inbound
or
album,
we
call
this
function.
Try
connect
to
gear
which
have
part
of
the
information
we
need,
for
example,
when
the
connection
is
incoming,
isn't
bound,
we
don't
we
don't
have
yet
the
peer
information
or
edge
information.
B
But
first
I
want
to
to
talk
with
you
about
edges,
which
here,
which
are
a
basic
data
structure
that
is
created
for
every
edge
that
is
created
between
each
peer
in
the
in
the
network
when
two,
when
two
peers
connect
to
each
other,
they
create
an
edge
which
is
later
propagated,
and
it's
the
way
that
peer
knows
that
there
is
a
either
that
there
is
a
connection
or
that
there
is
no
connection
between
some
peers,
like
when
two
peers
start
a
connection.
They
store
their
peer
ids,
this
nonce,
which
is
the
complex
part.
Here.
B
B
This
means
that
the
edge
is
about
removal
that
there
is
no
longer
an
edge
between
two
piers,
so
other
nodes
will
only
trust,
of
course,
for
edges
that
contain
valid
signatures,
and
they
will
only
care
about
higher
nonce
h's
with
higher
with
higher
nouns,
and
they
will
know
if
they
are
being
created
or
deleted
by
the
parity
of
the
nouns.
If
the
not
if
the
edge
is
removed,
if
the
edge
is
removed,
we
also
need.
B
We
also
need
a
signature
from
the
pier
that
removes
the
edge
and
that
needs
to
sing
the
full
and
the
full
edge.
So
this
thing,
sorry,
let
me
come
back
this
signature
here.
This
number
here
is
signaling
the
these
three
fields,
the
pure,
the
both
peer
id
and
the
and
the
nouns
these
are
signed
by
the
signature,
and
this
signature
here
will
be
only
present
if
the
nouns
is
even
and
will
sing
the
same.
The
the
same
information-
okay
so,
but
only
only
one,
pier
is
required
to
see
in
a
removal
a
removal
edge.
B
Okay.
So
that's
what
edges
are
edge
info
is
just
partial
information,
just
the
noise
that
is
being
proposed
and
the
signature
from
the
peer
that
is
proposing
the
edge.
So
this
will
only
be
present
on
inbound
on
on
outbound
connections.
When
we
create
a
connection,
we
propose
a
an
edge
info
like
a
nonce
and
we
already
signed
it,
so
we
can
start
process.
B
So
when
we
call
this
function,
try
to
connect,
we
made
several
checks,
and
eventually
we
start
up
here.
So
basically,
we
will
have
an
actor
appearance
for
every
active
connection
that
that
exists
either
if
it
is
active
or
it
is
in
process
of
being
created.
Okay,
so
let's
go
to
peer
here.
Let's
analyze,
what's
going
on
in
this
place
like
this,
is
this
is
a
game,
an
actor
from
from
actics.
B
So
same
thing
applies
first,
when
it
is
created,
it's
called
the
new,
but
nothing
is
happening
here,
but
there
is
this
function
started,
which
is
the
function
in
this
first
call
initially.
So
like
eventually,
what
will
happen?
These
are
some
metrics
fetch
client
chain
information.
This
is
a
function
that
will
communicate
with
the
client,
probably
yeah.
So
we
have
some
pipes
between
every
actor,
almost
every
actor
in
the
in
our
code
like
there
are
pipes
that
connect
pier
manager
with
pier
pier
with
bo
client
and
pier
money
with
klein
and
v
client.
B
All
of
those
are
actors,
and
we
have
some
pipes
that
allow
us
to
communicate
between
them,
and
this
is
already
provided
by
acting
all
these
functions.
So
what
will
happen
here
is
that
if
we
are
an
outbound
connection,
we
will
so
if
the
beer
is
outbound
and
we
will
send
the
handshake
so
notice.
Let
me
go
here
just
a
minute,
so
here
in
the
outbound
tcp
connect
and
this
function
will
be
called.
When
we
try
to
establish
connection
from
other
peer,
we
will
eventually
call
act.
Try
pl,
connect,
we'll
call
it
without
bound.
B
We
already
have
some
massage
information,
some
edge
information,
which
is
computed,
and
we
should
compute
it
here.
The
proposed
nouns
okay,
so
so
only
when
the
peer
is
not
done,
we
will
try
to
send
hand
check.
This
is
to
avoid
ascending
double
lights
and
double
hand
check
within
each
other,
which
actually
might
happen
if
both
beer
tried
to
establish
a
connection
between
them
at
the
same
time.
This
is
something
that
might
happen,
and
it's
already
handled,
and
here
so,
let's
discuss
what
will
happen
so
the
most
important
function
here
in
prs,
probably
it's.
B
B
A
note
should
only
propose
a
removal
over
a
valid
and
created
edge.
You
should
not
propose
a
removal
on
top
of
an
invalid
active
edge.
This
is
to
avoid,
like
the
problem
that
we
are
covering
here,
is
that
a
malicious
peer
tried
to
bump
this
number
the
non-number
much
higher
and
create
overflow.
This
number
is
not
checked
for
our
flow,
or
this
number
is
not
not
checking
our
flow
and
honest
note
should
not.
B
For
honestly,
this
should
not
be
a
problem
very
likely,
because
this
number
will
be
bumped
in
one
for
every
new
connection
that
is
created.
So
so,
basically,
we
need
these
two
signatures
to
check
that
the
created
edge
is
valid,
and
then
this
signature
to
check
that
the
remove
edge
is
also
valid.
So
this
signature
will
be
always
on
will
be
signaling,
odd
numbers
here,
and
this
signature
will
be
always
a
signal
even
number.
B
B
C
B
B
B
I'm
not
in
the
right
stream,
okay
here
so
in
the
in
the
prs.
I
I
already
told
that
pierre
are
an
actor,
and
this
is
probably
the
most
important
point
of
the
of
beer
where
most
of
the
where,
where
the
logic
starts,
probably,
which
is
the
stream
handler.
This
is
receiving
information
from
the
from
the
network
and
before
starting
here.
Let
me
let
me
discuss
something
when
the
beer
is
created,
probably
in
peer
manager.
B
B
Basically,
this
collect
will
just
it
will
handle
some
corner
cases,
but
it
basically
used
redland
and
expect
that
the
buffer
is
full.
That
contains
the
full
message
and
then
just
pass
the
the
message
completely
to
the
to
the
to
the
peer
itself
and
the
message
that
will
be
received
here.
It
will
be
basically
the
the
the
full
stream
okay.
So
this
is
the
the
vector
of
of
received
and
decoded
by
the
by
the
codec.
B
B
B
B
The
main
data
structure
that
we
use
to
send
message
through
the
network,
all
measure,
all
type
of
data
structures
that
need
to
be
sent
and
our
sub
fields
here
might
be
very
deep,
so
most
of
the
fields
exposed
here
are
relevant
for
networking
like
at
least
this
first.
This
up
to
this
point,
these
are
basically
about
networking.
Mostly,
is
all
those
that
start
with.
Prefix
block
are
more
about
consensus,
and
there
are
a
particular
type
of
message,
that's
very
relevant,
which
are
rooted
message
and
we
will
be
discussing
them
probably
next
session.
B
So
here,
let's
discuss
how
handshake
works,
and
we
have
like
this
state
machine
for
for
every
forever
appear
like.
Let
me
yeah
this
code
already
pass
it.
We
just
deserialize
it.
There
are
some
type
of
failures
that
we
try
to
address
here.
If
the
handshake
fails.
For
some
reasons,
this
is
kind
of
complex,
mostly
because
when
we
handle
protocol
updates
sometime
when
the
handshake
itself
was
updated,
it
was
kind
of
hard
to
handle
that
case
not
hard
but
complex.
So
that's
where
all
this
complexity
comes
from
and
so
yeah.
B
Let
me
jump
up
to
this
place,
which
is
the
relevant
part.
We
keep
for
every
peer
and
it's
status,
which
is
like
some
sort
of
state
machine
either
we
are
connecting
it's
ready
or
it's
banned
and
if
it's
maybe
misbehaving
for
some
reason
right
now,
the
only
reason
we
are
banning
is
or
abusive
peer
peer
that
sends
more
than
some
amount
of
transactions
of
bytes
per
second.
B
Now
this,
for
example,
this
symbolic
target,
is
when
we
try
to
connect
to
appear,
and
we
believe
it.
It
contains
like
some
peer
id
and
some
address
and
that's
not
correct.
That's
no
longer
the
peer
id
that
is
running
in
that
address,
which
is
something
that
might
happen
if
a
validator
like
turn
off
the
node
and
start
with
different
others.
This
will
be
there.
B
This
part
of
the
code
will
probably
hit
so
when
we
are
connecting
and
receive
a
handshake
notice
that
a
handshake
is
sent
automatically.
When
we
create
a
connection
and
it's
an
outbound
connection,
so
we
automatically
start,
we
automatically
send
a
handshake.
Let
me
show
you
where,
where
it
is
sent,
because
okay
here
send
handshake,
will
choose,
create
we'll
just
create
the
the
handshake.
This
also
has
its
complex
code,
because
it's
handling
protocol
version.
Probably
we
will
want
to
clean
part
of
this
code,
mostly
because
the
more
hard
to
do
great
we're
already
done.
B
We
are
already
like.
We
can
do
blades
easier
now
and
we
can
simplify
this
code
closely
and
and
when
the
handshake
is
created,
we
just
send
it
over
there
over
the
network,
and
this
is
the
main
function
that
is
used
to
create
tools,
send
messages
directed
directly
to
another
to
another
peer
okay.
We
just
need
to
wrap
the
message
inside
this
peer
message
and
we
just
send
it
to
the
to
their
party.
B
So
when
we
receive
a
handshake
and
we
are
connecting
to
the
spear,
this
is
actually
the
first
state
and
in
which
we
are
in
the
state
machine
we
are
initially
connecting
to
up
here
and
when
we
receive
the
handshake.
Well,
we
process
it.
Let
me
let's
discuss
what
what's
the
information
sent
in
the
handshake,
we
just
have
a
version
all
the
supported
version.
This
is
also
for
credibility.
B
Some
information
about
us
information
about
the
peer
we
are
we
are
trying
to
connect,
and,
at
least
in
part,
this
is
about
also
as
well,
and
this
is
information
about
the
the
chain
this
well.
This
is
relevant
and
to
avoid
peers
on
different
networks
connecting
to
each
other,
and
it
also
contains
some
relevant
information
about
those,
and
this
is
the
edge
information.
B
This
is
partial,
partial
edge
which
is
sent
and
when
we
try
to
connect
to
another
pier
which
is
which
will
be
used
to
to
produce
the
final,
the
final
edge.
Eventually,
okay,
we
have
several
checks,
the
verified,
the
handshake
is
correct
in
case
it
is
not.
It
is
not
correct
if
this:
if
there
is
no
way,
then
this
can
be
fixed,
we
just
call
context
stop.
This
is
a
part
of
how
actics
work
on
actors.
B
We
have
access
to
this
context
and
if
we
call
stop
basically
it
will
stop
the
this
actor
from
the
asynchron
async
pull
and
before
and
before
fully
stopping
the
node.
It
will
call
the
function,
not
stopping
yeah.
It
will
first
call
function
stopping
and
when
this
function
ends,
it
will
call
function,
stop
it
this
function.
Well,
we
use
it.
We
have
some
like
here
regarding
metrics
but
most
relevant.
We
also
communicate
to
the
peer
manager
that
this
spear
is
no
longer
an
active
connection.
B
B
B
C
B
B
Here
we
just
just
check
that
that
the
nouns
we
will
be
using
is
the
one
we
proposed,
because
if
the
pure
type
is
at
bone,
we
just
send
a
handshake
and
we
are
receiving
the
the
second
part
of
the
of
the
hand
check
we
check
the
this
is
correct
and
we
then,
but
just
create
peer
information
and
and
most
importantly,
we
when
everything
when
everything
is
passed,
we
call
we
consolidate
this
connection.
This
will
happen.
B
If
everything
with
handshake
was
correct,
we
consolidate
the
the
connection
which
eventually
will
trigger
sending
the
handshake.
If
we,
if
the
beer
is
inbound
like
if
the
handshake,
if
the
connection
wasn't
initiated
not
not
from
us
but
from
the
other
peer,
the
beer
isn't
down.
When
the
connection
is
consolidated,
we
check
the
handshake
in
the
pure
manager.
Well,
you
can
check
all
the
events
that
might
be
triggered
with
android,
as
I
already
told
in
particular,
this
event
is
consolidate.
B
We
need
to
send
this
information
to
peer
manager,
because
peer
manager
itself
contains
important
data
structures
that
needs
to
be
updated
and
also
that
are
checked
to
to
be
able
to
check
if
that
connection
might
be
consolidated.
If
and
nothing
if
something
is
be
elected
or
not
here.
Well
again,
several
several
checks
checks
that
everything
is.
C
B
But
we
are
not
connecting
to
some
blacklisted
peer
that
we
are
not
connecting
to
some
vanity
or
active
peers.
Oh
that
we
are
not
connecting
to
appear
that
we
are
already
connected
to
this,
in
particular,
is
addressing
the
case
when
two
peers
start
to
connecting
each
other.
We
need
to
disassembly
wait.
B
And
the
other
will
make
pro,
will
progress
and
eventually
will
success
will
succeed
and
well,
if
not
this,
if
inbound
is
not
allowed,
we
will
not
accept
nuns
to
be
zero
either
so
yeah,
there
are
several
several
checks
that
needs
to
be
done
in
particular
in
particular.
This
is
interesting
because
this
will
trigger
another
part
of
the
state
machine
when,
when
the
last
nonce
that
we
know
is
greater
than
the
nouns
proposed
by
the
other
peer
we
will
reject.
B
We
will
not
fully
reject
the
handshake,
but
we
will
reject
that
proposed
nonce
and
instead
we
will
propose
a
higher
higher
nons,
because
otherwise,
that
connection
will
not
be
valid
and
will
not
be
used,
but
by
the
by
the
rest
of
the
network
and
and
this
this
is
other
set
like
when
we
like.
This
is
their
response.
B
B
We
have
a
special
type
of
message,
which
is
called
last
edge,
and
then
we
send
what
we
sent
the
last
edge
that
had
already
existed
within
us
notice
that
we
send
the
full
edge
so
that
it
can
be
verified
that
it
is
a
valid
edge
and
when
appear
receive
the
last,
the
last
edge.
If
it
is
indeed
correct,
if
it
is
indeed
a
has
higher
nonce,
we
just
updated
everything
like
we
resent
a
handshake
again,
you
can
check
it.
This
is
another
step
of
the
state
machine
like
you've
received
last
edge.
B
We
verify
everything
is
correct
and
then
we
propose
again
the
handshake
but
with
higher,
but
with
higher
nuns
notice
that
there
is
some
case
that
it's
not
explicitly
handled
in
these
in
this
state
machine,
which
is
when
both
peer
for
some
reason.
Let's
say
they
keep
their
identities,
but
they
lost
all
their
data,
so
they
lost
the
higher
numbers
they
had
within
them.
So
they
will
start
a
new
connection
with
nuns
one,
but
there
is
a
chance
that
the
higher
numbers
already
existed.
So
in
this
case
they
will
learn
it
from
other
peers.
B
In
the
network
we
haven't
discussed
this
yet,
but
we'll
probably
discuss
in
the
next
session
when
they
learn
that
they're
that
they're,
not
the
nons
of
of
the
edge
between
them,
is
higher,
has
higher
numbers.
They
will
trigger
this
process
of
updating
of
updating
the
edge
if
it
like
they
trigger
the
process
of
updating
the
action
and
if
it
fails,
they
will
disconnect
from
each
other,
and
maybe
they
can
start
to
a
new
connection.
If
they
do
not
update
timely,
then
you
know
any
nodes
so
well,
yeah.
Basically,
here
it's
the
like.
B
This
is
the
most
important
part
of
the
of
the
connection.
It's
happening
in
this
part
of
the
of
the
state
machine.
When
we
receive
the
handshake,
we
check
everything
is
correct
and
we
call
consolidate
on
the
pure
manager
and
send
hand
check
again
if
we
are
in
bounce
and
can
check
to
the
other
party.
Okay,
so
well,
we
already
have
some
other
some
other.
We
handle
other
type
of
of
incoming
messages,
but
only
when
the
connection
is
ready,
which
is
only
updated
at
this
point.
B
At
this
point,
when
the
connection
was
consolidated
correctly
and
we
marked
the
connections
ready
and
then
we
start
processing
other
types
of
messages,
otherwise
those
messages
were
just
discarded
so
well.
Disconnect
is
used
for
gracefully
disconnection
and
handshake
is
ignored.
At
this
point,
piers
request
er.
Well
here
I
guess
I
can
talk
about
discovery
of
the
of
the
network
which,
basically
we
we,
I
told
we
start
with
a
bootstrap
node,
and
then
we
use
send
this
type
of
message,
which
is
peers
request,
which
asks
for
for
what?
B
B
Pure
response
peers
peers
at
this
response:
okay
piercy,
we
asked
the
peer
manager
for
peer
request
and
in
the
answer,
and
it
will
contain
all
the
all
the
gears
now
this
it's
hard
to
navigate
for
for
this
code
in
optics,
because
you
cannot
navigate
like
this.
You
need
to
your
request
here.
This
will.
I
will
ask
for
healthy
peers
and
then
we'll
return.
The
list
back
to
the
period
itself,
which
will
be
later.
B
Sent
to
the
sent
to
the
to
appear
that
ask
for
more
peers,
so
this
is
when
we
receive
more
peers,
we
just
try
to
add
them
to
the
pure
manner.
It
already
has
some
love
to
add
new
peers.
We
here
have
also
some
protection
at
the
peer
store
level
to
avoid
the
to
avoid
cases
when
some
peers
try
to
impersonate
others
like
try
to
claim
that
an
ips
control
by
appear
with
different
id
or
something
like
that,
those
those
cases
are
are
addressed
here
in
the
peer
store.
B
There
is
also
some
complex
logic
because
of
that
we
have
like
some
trust
level
on
the
on
the
on
each
on
each
case,
which
can
be
indirect
direct.
Our
signal,
indirect,
is
when
we
learn
it
from
other
peer
direct
is
when
we
learn
from
the
peer
that
control
that
address
it's
coming
directly
from
that
pipe
and
signet
is
when
we
already
have
some
message
signed
by
that
by
that
peer
id
with
the
private
key,
so
we
can't
be
sure
to
understand
the
lawyer.
B
Almost
I'm
seeing
the
time
we
have
seven
minutes
to
finish.
We,
I
will
just
try
to
finish
quick,
the
state,
this
state
machine
and
yeah,
but
well
probably
you
can
you
can
in
what?
Now
that
you
understand
how
like
the
main
light
for
interacting
with
other
peer
works,
you
can
probably
inspect
and
the
rest
of
the
spec
of
the
state
machine
it
it
handles
each
type
of
connections.
Most
of
the
time
can
communicate
into
the
peer
manager
to
resolve
some
of
the
some
of
this
information,
and
so
well.
B
Here
is
when
we
try
to
update
the
nonsense
that
I
was
talking
before,
and
the
rest
of
the
message
are
relevant
either
for
for
routing
between
inside
the
network
when
we
want
when
we
try
to
root
a
message
to
another
peer
directly.
This
is
for
fast
propagation
of
certain
type
of
message,
such
as
transactions
and
chunks,
and
in
particular,
some
general
type
of
message
are
just
handled
by
this
function
receive
which
propagate
that
message
either
for
the
view
client
or
for
the
claim
and
depending
on
on
on
its
type.
Okay.
So
well.