►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Design Decisions for Communication Systems - Eric Anderson, Google
When hearing about a new programming language, one might learn it is imperative, strongly-typed, dynamically-type-checked, object-oriented, and garbage-collected. If they have used multiple languages in the past, they now have a pretty good view of the basic constraints of the language. When it comes to communication systems, it's not as much common knowledge the design choices made and the impact they have. Come hear Eric Anderson discuss a variety of communication systems, from IPC to message queues to REST, modern and historical, and the various features they provide and some trade-offs involved. Learn where gRPC fits and how its design choices impact your service design.
https://sched.co/UaXa
A
Y'all
heard
apparently
y'all
everyone
supposed
to
get
upvotes,
I
didn't
say
it
so
we're
good
and
I
had
this
trouble
last
time
all
right,
so
I
am
part
of
a
gypsy
team.
However,
this
is
a
little
bit
wider
scope
than
GRP
see
gypsy.
It
does
it's
a
little
bit
of
how
does
Europe
see
fit
into
the
wider
story
of
communicating
and
I'll
try
to
be
pretty
fair
to
other
systems,
I
mean
so,
but
I'm
gonna
be
a
little
bit
biased,
so
we're
gonna
go
into
our
rabbit,
hole
so
programming
languages.
A
We
know
them
I'm
sort
of
using
this
as
a
jumping-off
point,
because
we're
very
familiar
with
multiple
of
them
typically,
and
we
tend
to
be
a
little
opinionated
about
them.
So,
for
example,
mythical
programming
language
is
imperative:
strongly-typed
dynamically
type
checked
and
while
I'm
saying
each
of
these
dragoo
yep
I
like
that
about
this
and
you're
like
I,
still,
don't
still
don't
know-
and
this
is
gonna-
maybe
gonna
be
a
little
bit
problem.
I,
don't
know
why
that
is
still
down
there.
It
is
hiding
stuff,
let's
see
if
we
just
do
it
again,.
A
A
So
that's
behind
where
you
can't
see
anyway,
so
there's
these
aspects
of
programming
languages
and
certain
things
you
like,
oh
I,
really
need
this
or
I.
Don't
care
about
very
much
like
this,
but
we're
quite
familiar
with
them.
We
can
talk
about
these
and
we
can
throw
around
these
words
and
we
sort
of
know
what
people
are
talking
about.
I
feel
like
people
are
also
opinionated
about
communication
systems,
but
it's
a
little
bit
more
akin
to
like
Emacs
versus
vim.
It's
a
very
limited
view
of
sort
of
the
choices
that
are
available.
A
We
know
some
options
and
we're
sort
of
just
debating
between
a
couple
implementations
or
things
like
that.
It's
not
serve
on
a
higher
level
and
so
like
what
are?
What
are
our
options?
We
are
like.
Okay,
we've
got
rest,
our
PC
is
the
thing
these
days
again.
We
could
make
something
our
souls
and
then
yeah.
That's
it.
There's
really
no
no
option
so
I'm,
not
sure
if
y'all
realize
that
there's
basically
no
options
on
the
market
and,
of
course,
I'm
jesting,
but
also
like,
let's
say
that
you're
gonna
want.
A
You
know
if
only
my
perfect
favorite
communication
system
existed,
I
really
wish
it
was,
and
what
are
they
choosing
between
we're,
like
oh
request
response,
yeah
I
know
about
that.
But
what's
the
other
things
I
could
be
talking
about
plant
server
versus
what
binary
versus
text
I?
Do
people
do
tend
to
be
on
that
when
they
know
the
other
side
is,
and
they
know
a
lot
of
the
advantages
disadvantages.
So
you
know
we've
got
that
going
for
us,
but
it
seems
like
there
really
should
be
some
more.
A
So
let's
go
ahead
and
start
simple
and
like
a
pipe,
pretty
simple,
it's
that
UNIX
thing
and
you
can
send
on
it
and
receive
on
it
and
but
there's
actually
quite
a
bit
to
it
like
I.
Didn't
try
very
hard
and
I
came
up
with
these
these
things.
So
if
we
sort
of
go
into
them,
it
simplex
means
it's
only
one
direction
versus
if
it
was
duplex
he'd
be
both
direction,
except
for
certain
OSS
like
Solaris.
A
A
So
if
you
send
one
and
two
it'll
come
on,
the
other
side
is
one
in
two:
it
happens
to
be
byte
oriented,
and
this
is
generally
a
versus
message
oriented,
although
that's
a
little
bit
varies
system
system
and
that's
because
it's
really
working
on
a
bytes.
That's
that
the
fundamental
level
it's
working.
It
happens
to
be
streaming.
A
This
tends
to
imply
the
reliable
and
ordered,
but
basically
there's
any
number
of
elements
in
this
case
and
bytes,
and
then
it
can
terminate
so
streams
typically
have
an
end
which
is
sort
of
a
hidden
aspect
to
them,
and
then
it
happens
to
be
asynchronous.
Whenever
you
write
a
byte,
you
don't
know
whenever
the
reader
has
read
the
byte
and
you
tend
not
to
wait
for
the
reader
to
read.
A
It
is
flow
controlled
though,
so
if
the
reader
isn't
reading
quickly
enough,
you're
gonna
have
to
end
up
waiting,
but
that's
a
little
bit
different
than
being
synchronous.
It
happens
to
be
buffered,
because
the
kernel
will
end
up
buffering
some
things.
This
is
also
related
to
async.
It
ends
up
providing
a
nice
bit
of
performance,
but
you
also
need
to
sort
of
account
for
it
that
certain
things
may
not
be
noticed
immediately.
A
Interesting
thing
is
it's
anonymous.
This
means
that
there's
no
identity
for
a
pipe.
You
know
you
create
one,
your
eye
god
this
is
my
favorite
I
wish.
We
could
tell
someone
else
about
it.
You
can't
it's
basically
just
an
F
T
and
so
there's
no
way
to
find
a
pipe.
If
you
could
figure
out
a
way
to
tell
someone
else
about
it,
there's
no
way
to
look
them
up.
A
It's
also
cereal,
if
you're,
sending
multiple
bytes
at
a
time
and
sort
of
those
bytes
vary
and
there's
a
couple
of
other
things,
but
it's
really
hard
to
do
a
read
or
write
by
itself
without
sort
of
other
synchronization,
a
sort
of
other
synchronization.
If
you've
got
multiple
readers
and
multiple
writers,
because
the
byte
alignment
can
end
up
getting
off
and
it's
a
little
bit
hard
if
you're
doing
just
single
byte
reads
and
writes,
you
can
actually
do
something
more
parallel,
where
you
could
have
multiple
readers
and
multiple
writers.
A
But
it's
not
to
be
all
that
common.
It's
more
things
like
make
using
like
desk
Jay
or
things
like
that,
it's
a
little
bit
more
specialized,
but
you
can
go
ahead
and
commonly
pair
two
pipes
together.
This
is
where
we
we
see
a
lot
of
systems.
Do
this
whenever
they're
wanting
to
communicate
in
both
directions-
and
at
this
point
it
becomes
duplex
so
you've
got
you
can
both
send
and
receive
at
the
same
time
well,
at
the
same
time,
full
duplex.
A
So
anytime
you
talk
about
duplex,
you
have
to
ask
whether
it's
half
duplex
or
full
duplex,
whether
so
some
systems
its
duplex,
but
you
have
to
send
and
then
you
have
to
receive
and
if
you
wanted
to
send
again
after
you
sent
sorry,
you
need
to
wait
for
the
receive
and
it
happens
to
be
full
duplex.
Both
directions
of
the
streams
are
independent.
A
It
happens
to
be
point-to-point
practice,
it's
very
hard
to
do
such
a
system
like
this,
where
it's
not
just
one
thing
on
either
side
and
yeah.
We've
got
pipe.
It's
proven.
It
works
for
really
well,
it's
sort
of
a
little
bit
low-level,
but
it's
it's
very
reliable
and
it
works,
and
we
know
how
to
understand
it
and
comprehend
it
and
work
with
it.
It
happens
to
also
only
be
local
local
machine.
Only
there's
something
related
a
called
a
FIFO
on
UNIX.
You
might
call
it
a
named
pipe
Windows
has
something
else
called
a
named
pipe.
A
It's
similar
slightly
different,
it's
a
little
closer
to
the
sockets
stuff,
our
UNIX
domain
socket
stuff,
but
basically
the
only
difference
is
now.
You
have
a
name
for
it.
So
before
the
thing
about
it
being
anonymous
now
it
is
named.
There
is
a
file
that
you
can
end
up
opening
and
then
you
can
either
open
it
for
rewriting
or
reading
it
happens,
just
to
be
otherwise
is
basically
the
same
as
a
pipe
there's.
It's
only
one
time
use
like
a
pipe
after
it's
closed,
it's
done
and
you
might
as
well
just
delete
the
file.
A
It
doesn't
do
much
up
to
that
point
and
then
we're
coming
up
on
two
shared
resources.
You
can
tell
I'm
talking
a
lot
about
on
a
single
machine
and
let's
not
ignore
the
fact
that
we
can
just
do
anything.
If
we
have
a
shared
resource
we
can
communicate.
However,
we
want
whatever
back-channel.
If
we
have
let's
say
some
shared
memory.
I
can
set
some
memory
bits
and
then
someone
else
can
read
those
memory
bits
and
set
some
hour,
and
we
have
that.
So
you
either
use
just
plain
shared
memory.
A
A
So
this
this
organ
thing
is
actually
pretty
common
in
desktop
applications
or
intra
app
applications.
Whenever
an
app
is
sort
of
trying
to
talk
to
itself
on
a
single
node
and
it's
generally
associated
with
high
performance,
if
you
you
can
use
it
and
get
low
performance,
but
whenever
people
are
going
for
high
performance,
this
is
something
they
might
turn
to
and
try
to
eat
things
out.
But
it
also
happens
to
be
a
bit
brittle
because
you
end
up
sharing
quite
a
bit
of
State
and
knowledge
and
the
things
have
to
coordinate.
A
If
anything,
if
any
one
thing
goes
wrong,
it
brings
down
the
entire
system,
and
things
like
that,
so
it's
pretty
poor,
poorly
suited
for
crossing
trusts
domains
when
it's
some
other
person
is
going
to
be
the
client
that
I'm,
saying
client
some
other
person
use
process
is
going
to
be
interacting
with
yours
and
you
don't
control
that
area.
What
much
and
it's
also
poorly
suited
to
outgrow
the
one
job
it
was
created
for
you
try
to
shove
it
more
things
in
it
like
if
you're
just
going
to
try
pass
more
data.
A
That's
probably
fine,
but
if
you're
trying
to
have
it
try
to
teach
it
new
tricks,
it
can
start
growing
poorly
there's
a
lot
of
there's
common
patterns,
but
they
tend
to
be
some
sort
of
random
application.
Specific
protocol
strongly
tailored
to
whatever
that
one
thing
you're
doing
is
and
and
that
sort
of
makes
it
a
bit
too
complex
to
get
into
two
very
dig
it
into.
A
But
I'll
just
make
note
here
that,
when
scaling
over
multiple
machines,
you
can
still
do
it
and
we
still
do
share
resources
across
multiple
machines,
but
and
most
of
the
interaction
patterns
still
hold
we're
going
to
need
some
sort
of
network
protocol
to
do
that.
But
this
can
be
something
like
as
simple
as
memcache
D
or
your
database
that
you
end
up
just
you
know
having
all
the
pieces
of
your
application
access
directly.
That's
that's
sort
of
similar
to
shared
resource
in
many
ways
and
then
just
sort
of
I
think
this
is
rounding.
A
This
out,
we've
got
sockets.
These
are
duplex
and
they
can
actually
be
both
four
bytes,
a
stream
of
bytes
or
four
messages,
depending
on
its
type,
its
point-to-point
client-server,
we're
noticing
some
terms
sort
of
coming
up
now
and
the
the
server
ends
up
binding
to
a
name
or
a
port,
and
the
client
ends
up
looking
up
that
name
in
order
to
find
it
and
then
we'll
see
we'll
see
this
sort
of
pattern
hold
and
slightly
different
names
and
slightly
different
forms,
but
it's
pretty
common.
A
It
happens
to
be
connection
oriented
where
you
make
the
establish
the
connection,
and
that
has
some
state
to
the
the
client
and
the
server
and
things
are
associated
with
that
connection.
So,
for
example,
UNIX
domain
socket
it
supports
both
bytes
and
messages.
They
really
behave
pretty
similar
to
each
other,
except
whether
you're
gonna
do
things
on
byte,
based
or
message
based
and
then
TCP,
which
we
all
basically
know.
It's
gonna
be
bytes.
A
It's
just
a
big
stream
of
bytes,
and
the
thing
that
is
cut
off
at
the
bottom
is
a
smaller
will
note
that
messages
may
have
a
maximum
size
that
that
happens.
A
lot
in
message
based
systems.
You
might
think,
oh
that
TCP
thing
we
talked
about
sockets,
there's
that
UDP
thing
yeah.
Let's
not
talk
about
the
UDP
thing,
it's
just
it's
a
thing
to
itself.
It's
really
cool
and
neat
useful,
but
it's
gonna
be
pretty
specialized
cases.
A
So
this
is
really
a
continuation
of
the
socket,
but
there,
the
UNIX
domain
socket
is
a
bit
interesting
in
that
it
can
send
more
than
just
bytes
or
messages
it
can
actually
send
file
descriptors.
These
system
objects
where
you
have
one
and
then
you
another
process,
and
then
they
have
it.
This
is
very
heavily
used
for,
like
limiting
permissions
where
you
you
have
some
privileged
process,
opens
a
file
or
something
and
then
hands
off
the
file
descriptor
to
another
process,
and
that
means
that
other
process
cannot
access
all
the
other
files.
A
But
this
opens
up
a
sort
of
question
now:
we've
got
an
object
and
the
objects
have
a
lifetime
to
them.
So
now
we
need
to
manage
this
lifetime
it
in
this
particular
case
it
since
not
to
be
that
bad.
The
kernel
just
keeps
a
reference
count
and
it
turns
to
be
pretty
simple
because
there's
no
row
graph
involved,
like
a
file
descriptor,
doesn't
contain
another
file
descriptor,
and
so
it's
pretty
much
just
a
flat
bunch
of
reference
counted
objects.
A
There's
no
graph,
there's
no
cycles,
so
everything
is
pretty
fine
in
the
world.
So
we
we
went
through
all
these
sort
of
lower-level
stuff,
but
we
don't
tend
to
use
those
on
a
daily
basis.
I
was
sort
of
it's
it's
a
little
bit
too
much
work
and
the
first
thing
to
sort
of
make
things
easier
that
sort
of
came
along
and
I
guess
the
80s
was
our
BC
remote
procedure
call
so
son
RPC
is
up
there
because
that
was
basically
the
first
widely
used.
One
I
used,
JSON
RPC
did
its
job
pretty
well.
Soap.
A
Is
you
could
argue
a
little
bit
it's
different,
but
a
lot
of
people
use
it
for
RPC,
so
I
think
it's
at
least
fair
to
put
in
here
and
then
G
RPC
is
also
RPC.
This
is
a
different
paradigm.
Now
we've
got
requests
and
response
messages
and
you've
got
this
request
response
pair
for
each
RBC.
It's
still
going
to
be
a
point-to-point
client-server,
but
it's
also
now
connectionless
you
we're
doing
things
on
a
per
RPC
basis
as
opposed
to
oh,
we
establish
connection
and
we're
going
to
do
a
bunch
of
back-and-forth
communication.
A
But
probably
the
biggest
thing
that
was
sort
of
a
big
deal
was
the
ideal
or
the
interface
definition
language.
This
is
you
go
off
and
you
describe
your
service
or
protocol
or
whatever
it
is,
and
then
it's
generally
prepared
with
generated
code
which
allows
you
to
generate
that
in
your
language
and
you
have
a
nice,
clear,
API,
you've
got
messages
and
types
that
you
can
work
with,
and
you
can
bundle
these
together
and
you
don't
have
to
worry
about
that
anymore.
So,
even
back
in
the
like
UNIX
domain
socket,
we
had
a.
A
We
had
a
message
base
to
stream.
That's
what
I
said,
but
that
message
was
just
a
bunch
of
bytes.
It
wasn't
actually
like.
It
was
just
a.
It
would
had
a
particular
length,
but
it
was
still
bytes
in
this
case
now
we
are
getting
something
that
there's
the
structure
involved.
You've
got
two
integer
fields
and
the
string
and
these
things
start
meaning
something
to
you
and
then
it's
a
little
cut
off
at
the
bottom
there,
but
RPC
is
also
synchronous
because
of
this
request
and
then
you're
waiting
on
the
response.
A
Gfc
was
up
there.
It's
a
little
bit
different
as
well,
though,
because
it
also
supports
a
streaming
mode.
So
it's
got
the
client.
It's
got
their
request
response
mode,
but
you
could
also
just
do
streaming,
which
is
a
different
mode.
You've
got
it's
gonna,
be
full
duplex
and
some
things
like
that
which
we
talked
about
with
streaming.
A
Also
at
the
bottom,
which
is
you
get
to
see
the
right?
It's
gonna
be
synchronous
if
you're
doing
a
request
response,
but
if
you're
doing
streaming
it
can
actually
be
asynchronous.
This
is
a
little
bit
what
you
tend
to
make
it
like
it's
a
bids
on
how
you
use
it,
whether
how
much
synchronous
or
asynchronous
it's
gonna
be
but
sort
of
lower
level.
It
can
start
working
a
lot
more
like
a
pipe
at
that
point.
A
Also
streaming
allows
pipelining
where
this
is
a
little
bit
of
a
people,
know
serial
and
they
know
parallel
it's
some
little
bit
in
the
middle
parallel
you're
doing
multiple
things
at
one
time
serial
is
you
do
one
thing
you
do
the
next
you
do.
The
next
pipelining
allows
you
to
start
the
second
one
a
little
bit
before
you
were
done
with
the
first
and
typically,
this
is
done
on
the
communication
itself.
So
you've
got
two
nodes
and
whenever
the
the
node
that'll
say,
the
server
is
done,
processing
the
work
from
the
first
request.
A
The
second
request
is
already
there
waiting
for
it,
and
so
it
can
immediately
process.
The
second
request:
it's
not
going
to
respond
with
the
the
first
request.
The
client
then
says:
oh
great,
that's,
and
then
it
creates
the
second
request,
Simpsons
that
the
client
can
have
already
prepared
the
the
second
request,
and
that
allows
you
to
reduce
some
latency
and
some
other
things.
A
So
this
sort
of
goes
back
to
why
I
made
the
talk.
People
aren't
necessarily
familiar
with
a
lot
of
these
things,
and
so
I
talked
about
Oh
Jesse,
its
RPC,
some
people,
not
actually
that
small
of
a
number
people
were
like
okay.
Well,
I've
got
my
service
up
at
the
top
and
it
creates
another
service.
So
it's
got
the
create
response
and
then
it's
going
to
return
a
calculator
and
this
at
the
very
bottom.
There
is
another
service
which
is
the
calculator
service.
A
So
can
you
return
one
service
from
another
service
and
actually
to
do
that?
I
mean
the
short
answer
is
no,
but
to
do
that,
you
end
up
needing
to
pass
a
reference
to
that
second
service
and
the
moment
you
start
talking
about
references,
we're
now
getting
into
more
of
an
object
land,
and
that
means
we're
going
to
do
remote
method
invocation.
It's
basically
object
oriented
RBC
in
some
ways,
if
you
so
the
main
thing
is
that
there's
an
object,
it's
got
some
stayed
and
methods,
but
you
don't
actually
send
objects.
A
You
only
send
references
and
if
anyone
needs
to
call
any
of
the
methods
on-
or
you
know,
change
the
state
of
the
object
or
anything
like
that,
they've
got
to
send
those
method
calls
back
to
the
original
object
in
order
to
get
it
to
mutate
at
state.
A
message,
however,
is
just
data,
and
it's
going
to
be
passed
by
by
value.
You
always
copy
the
full
message,
and
it's
gonna
be
things
like
the
primitives
and
structs
and
like
the
intz
and
the
streams
and
things
like
that.
A
A
A
Particular
objects
will
implement
particular
interfaces
or
be
particular
service
services,
and
you
can
end
up
casting
and
doing
things
like
that
to
them.
That
means
that
there's
a
runtime
system
in
place
now
in
order
to
check,
does
this
particular
reference.
This
particular
object
supports
these
particular
methods
that
will
vary
a
little
bit
in
complexity,
but
many
of
them
do
allow
you
to
check
hey.
A
Does
it
support
this
interface
and
we
also
need
a
way
to
maintain
object
lifetimes,
just
like
you
saw
before
with
the
UNIX
domain
socket
we
we're
gonna,
have
a
lot
of
objects
floating
around.
We're
gonna
need
some
sort
of
way
to
manage
them.
That's
generally
reference
counting
or
GC,
although
that
can
vary
a
little
bit,
and
so
just
to
put
this
into
a
little
bit
more
concrete,
because
a
lot
of
people
haven't
I
think
seen
RMI.
A
This
was
just
a
simple
d-bus
example:
I
made
I'm
a
little
familiar
with
ABI
he
and
d-bus
and
stuff,
and
so
I
just
shot
this
in
here,
but
the
the
first
one
finds
not
too
interesting.
It's
just
getting
a
sort
of
a
global
bus,
but
the
first
law,
the
second
line,
the
get
object,
is
getting
an
object
by
a
particular
name.
A
It's
got
some
slash
path,
sort
of
syntax,
but
the
FIR,
it's
basically
just
getting
it
by
its
name.
The
the
next
line
is
casting
it.
If
this
was
a
Jenner,
this
isn't
Python.
If
this
was
a
statically
typed
language,
that
would
have
been
generated
code
that
we
would
have
ended
up,
casting
it
to
particular
concrete
type,
and
then
we
actually
do
the
actual
communication
at
the
very
end.
A
But
that
is
a
very,
very
common
in
our
mi
like
in
anytime
you,
you
start
seeing
this
that
directory
service.
That's
that's
a
good
clue
that
you're
in
the
are
mi
land,
but
coming
back
a
little
bit
is
need
a
way
to
manage
object
lifetime.
This
is
a
very
important
part
of
our.
My
it
now
means
that
you
need
to
have
a
full
system.
It's
not
just
client
and
server,
and
those
two
communicate
alone.
You've
got
a
new
full
system
where
you've
got
references,
passing
back
and
forth
and
think
about.
A
If
you've
got
a
memory
leak,
it's
the
system
has
a
memory
leak.
It
is
not
that
process
has
a
memory
leak
and
you're
going
to
need
some
that
all
the
machines
are
going
to
need
to
communicate
and
figure
out
how
they
do
this
reference
counting.
When
do
they
release
references?
How
are
you
going
to
do
garbage
collection?
Are
you
been
going
to
bother
with
circular
references
or
things
like
that?
So
this?
How
you
end
up
solving
this
problems
very
important
to
our
mi?
A
There's
variations,
there's
simpler
versions,
event,
there's
more
complex
versions
of
it,
but
that
that's
something
always
to
look
out
for
so
serve
going
back.
I
had
the
list
for
RPC.
This
list
is
for
now
are
mi,
it's
basically
the
same
list.
The
only
difference
is
now
request.
Response
can
now
be
for
objects
and
messages,
because
you
can
pass
the
objects
around.
A
One
interesting
thing
is
sometimes
you
can
interchange
those
objects
and
messages,
I'm,
trying
to
think
I
think
like
Java
RMI,
it
wasn't
even
clear
whenever
he
called
whether
you're
gonna
get
an
object
back
or
a
message
back.
It
was
sort
of
up
to
the
server
to
decide
what
happened
and
that
it
that
can
actually
be
a
very,
very
hard
point.
Whenever
you're
trying
to
understand
these
systems,
I
strongly
prefer
whenever
those
are
very
clear,
if
there's
a
clear
separation
between
objects
and
messages,
and
then
it's
also
not
quite
client-server.
A
There's
aspects
of
client-server
you'll
commonly
see
the
words,
client
and
server,
but
I
think
it's
a
little
bit
more
murky
there,
because
it's
really
like
these
aren't
servers,
they're,
actually
objects
and
the
client
can
become
a
server
if
it's
gonna
pass
a
listener
and
stuff.
So
it's
a
little
bit
more
murky
there.
It's
still
mostly
client-server
but
I,
think
it's
not
quite
fair
to
just
say
it's
plain,
a
client-server
and
then
a
little
bit
cut
off
at
the
bottom.
Here
is
sometimes
it's
also
network.
It
has
Network
transparency.
A
This
was
a
big
thing
in
some
systems
and
it's
also
something
to
watch
out
for
I.
Think
that
this
was
a
big
failing
point
out
of
a
lot
of
the
RMI
systems
is
that
they
were
trying
to
become
completely
invisible
and
whenever
you
start
abstracting
where
the
network
at
this
level,
it
becomes
very
hard
to
figure
out
how
the
system
is
reeving.
For
example,
I
said
like
Java
RMI,
it
was
very
hard
to
get
your
very.
It
was
hard
to
get
figure
out
whether
you're
dealing
with
an
object
or
message
that
matters
for
a
performance.
A
Also,
this
network
transparency.
It
matters.
If,
if
you're
gonna
call
it
getter,
you
don't
want
to
really
be
calling
a
getter
from
over
the
network
all
the
time
you
know
it's
there's
five
different
things:
you're
not
gonna,
get
one
get
the
next
get
the
next
get
the
next
generally,
whenever
you're
doing,
network
programming,
you're
gonna
do
a
larger
request
to
get
more
things
all
at
once,
because
you
do
have
the
synchronous
major
nature.
So
those
are
things
to
look
out
for
not
every
RMI
system
has
a
network
transparency,
but
it's
something
that
very
strongly
impacts.
A
B
A
A
A
Those
were
the
the
are
my
systems
that
we
really
think
of
and
whenever
I
say
RPC,
that's
actually
what
a
lot
of
people
seem
to
have
in
their
mind
and
think
about,
but
Java
RMI
is
in
there
too
Java
RMI
is
actually
not
dead.
It's
I
think
still
going
with
j2ee
folks,
but
it's
a
little
bit
more
niche,
but
D
common
CORBA
are
pretty
much
dead.
At
this
point,
one
interesting
thing:
I
talked
about
the
the
local
only
RMI,
with
Android
binder
and
D
bus.
These
tend
to
be
used
for
transferring
system
objects.
A
Again,
the
reference
itself
to
objects
can
be
considered
a
secret
because
you
have
some
system
that
can
enforce
that.
It
was
actually
since
from
one
process
to
the
other,
and
so
you
can
pass
privileged
objects
and
in
this
case,
they're
actually,
like
application
level,
objects
references.
You
can
pass
those
references
across
processes
and
this
can
be
also
used
for
security.
A
Yes,
in
these
cases,
you're
going
to
use
some
sort
of
intermediary
and
it's
so-so-
a
broker
is
generally
a
service
that
you
end
up
talking
to
and
then
someone
else
might
talk
to
it
and
it's
very
common
for
message:
queues
and
job
queues,
a
message
buffs.
If
you
have
Watchers
and
notifications,
this
is
not
no
longer
client-server,
although
you're
going
to
talk
generally
client-server
to
the
broker
itself,
but
if
you're
looking
at
the
system,
the
sort
of
the
wider
system,
it's
no
longer
client-server
and
so,
for
example,
both
d-bus
and
pub/sub
are
brokered
protocols.
A
A
Brokered
services,
some
people
just
use
them
for
absolutely
everything
they
have
it
and
they
that's
the
only
thing
they
use.
They
tend
to
be
well
suited,
though,
for
one-way
communication.
Where
you
want
something
to
be
done,
you
don't
care
how
long
it
takes
or
you
don't
care
where
it
goes.
You
just
want
it
to
be
off
your
hands,
and
so
a
lot
of
this,
the
brokered
protocols
provide
pretty
strong
guarantees
about.
A
It
will
be
processed
once
where
it
won't
be
lost
or
those
sorts
of
things,
and
that's
some,
so
that's
sort
of
what
the
the
broker
is
providing
is
this
gonna
provide
this
persists,
persistence
and
make
sure
it
gets
done.
They're,
also
pretty
good
for
for
sort
of
multicasts
where
you've
got
so,
let's
say
an
event:
you
need
to
send
it
out
lots
of
places.
There's
lots
of
Watchers
for
that
are
interested
in
that
change.
You
tend
to
use
sort
of
broker
for
those
exactly
how
the
performance
on
this
operates.
A
This
is
loosely
object-oriented
like
there's
a
resource
I
see
it
has
a
URI,
and
that
looks
like
a
reference.
There's
methods
that
I
invoke
on
that
resource.
I
can
pass
in
these
references.
I
can
return
them,
and
sometimes,
even
though
these
references
are
used
for
security,
where
there's
a
sort
of
magic,
ugly,
random
number.
At
the
end-
and
someone
knows-
oh,
you
must
have
permission
to
access.
A
In
order
to
serve
add
more
and
more
types
of
operations,
there
are
IDL's
for
a
rest,
although
it's
not
as
essential
or
I
hope
it's
becoming
pretty
common,
but
it's
not
it's
not
always
used,
and,
interestingly
there's
no
reference
counting
or
there's
no
GC.
This
means
that
there's
that
transient
objects
are
objects
that
last
a
very
short
period
of
time
are
very
rare.
You
tend
to
have
a
limit
in
the
number
of
objects
you
can
have
per
account
or
each
object
costs
something
in
order
to
force
people
in
in
order
to
clean
up
after
themselves.
A
A
If
you
look
at
this
garbage
collector,
it's
got
some
configuration
and
bits
to
it,
and
that's
because,
whenever
you're
dealing
with
resources,
the
order
of
cleaning
them
up
matters
that
they
get
cleaned
up
soon
matters
or
maybe
it
doesn't-
and
so
so
there's
some
configuration
here
that
you
wouldn't
normally
see
of
just
a
memory
based
garbage
collector
and
there
there
are
some
additional
things
on
here.
Let's
see
the
I
think
what
I'm
going
to
jump
forward
a
little
bit
and
talk
about
the
OO,
though,
is
mainly
inside
the
application
there.
It's
the
one!
A
That's
passing
these
references
around
they're
not
used
too
much
by
the
system
itself.
They
are
used
for
level
seven
routing,
although
there's
some
trickery
to
that
they're
also
used
for
caching,
although
that's
mainly
for
proxies
clients,
don't
typ,
typically
cache
too
much
unless
you're
talking
browsers
and
some
things
like
that.
So
it's
actually
pretty
interesting
that
our
PCs
and
rest
aren't
more
different
once
you
start
looking
at
them,
and
you
can
do
some
of
the
same
things
that
you
do
in
rest
in
our
pcs.
A
But
really,
what
turns
out
is
there's
a
lot
of
non-functional
things
as
well.
There's
how
does
the
ecosystem,
how
good?
How
good
is
the
implementation?
These
things
actually
have
a
very
big,
much
bigger
impact
than
the
actual
protocol
itself.
So,
while
you're
gonna
be
interested
in
looking
at
all
the
functional
things,
these
end
up
deciding
a
lot
whether
make
or
break
and,
for
example,
compatibility
was
a
big
problem
with
koruba
and
that's
okay,
all
right,
I
think
we're
sort
of
out
of
time
that
did
go
long
longer
than
I
hoped,
I
wonder
two
questions.
C
B
What's
the
whole
idea
of
deadlines
in
gr,
PC
and
with
context
to
cloud
services
using
gr
PC
as
a
transport
mechanism?
Is
that
I'm
just
trying
to
ask
you?
Is
it
a
way
to
kind
of
like
a
fencing
mechanism
or
protect
protection
mechanism
to
issue
or
deadlines
against
RPC
request
coming
inbound
to
the
service?
Yes,.
A
So,
there's
a
deadline
to
used
a
couple
different
places:
they're
used
on
client
in
itself
in
order
to
sort
of
fail
early.
If
it
looks
like
it's
not
going
well
on
the
server
it
can
be
used
to
to
propagate
like
if
you're,
just
looking
at
client
and
server
just
that
by
itself.
It's
like
yeah,
not
too
interesting,
but
if
you
start
looking
at
you've
got
a
system
and
pretty
much
every
server.
A
It
turns
out
to
be
a
client
as
well
and
so
being
able
to
propagate
the
deadline
from
the
original
task,
you're
trying
to
do
which
had
some
time
all
the
way
through
the
system.
For
all
these,
my
new
little
sub
tasks
passing
that
deadline.
Arounds
can
be
quite
helpful
so
that,
whenever
let's
say,
let's
say
it
took
too
long,
all
those
tasks
can
be
cleaned
up
and
you
can
stop
your
work.
Also.
Let's
say
the
the
deadline
is
too
small.
You
learn
that
you've
got
two
microseconds
to
do
your
operation,
you
scoff
and
laugh.
A
So
captain
proto
didn't
come
in
here,
it's
gonna
be
more
object-oriented.
It's
also
got
things
like
the
the
futures
future
high
point:
high
planning
I've
not
used
it
heavily,
so
I,
don't
necessarily
know
how
well
it
works
in
practice.
I
tend
to
favor
simple
systems
that
I
can
quickly.
I,
don't
want
to
be
necessarily
fighting
the
system.
I'm
dealing
with
I
want
to
be
able
to
comprehend
how
the
the
communication
is
working,
and
so
then,
the
the
the
higher
level
I
can
understand
the
pieces.
A
A
Is
a
quick
version
of
G
RPC
on
some
of
the
mobile
platforms?
They
are
mainly
using
the
CRO
net
library,
which
is
Chrome's,
networking
stack
sort
of
turned
into
a
library,
and
so
then
you
also
need
a.
You
typically
have
a
quick
proxy
on
the
server
side.
In
order
to
turn
it
then
back
into
something
more
HTTP
2
or
something
like
that.
It's
there
Mobile
is
where
we've
seen
the
most
clamoring
for
it,
and
things
like
that.
Yeah.