►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11–13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14–15 (http://bit.ly/kccncchina18).
NATS Intro – Colin Sullivan & Waldemar Quevedo, Synadia (Any Skill Level)
Join members of the NATS team to learn about NATS Messaging! Distributed systems architecture has been disrupted via decomposition as cloud technology has matured - a move from monolithic applications to microservices. This has created a need for multiple communication patterns, location transparency, and the decoupling of data producers and consumers. NATS is a cloud-native messaging project that addresses these needs and others. In this discussion, we'll introduce you to NATS: how NATS came to be, it's DNA, the problems it solves and how NATS can be leveraged in cloud applications.
About Colin
Colin is the product manager of NATS (https://nats.io). He has extensive experience developing messaging products and designing distributed systems. Prior to Synadia, Colin worked at Apcera and TIBCO software.
About Waldemar
Waldemar is a Software Engineer at Synadia Communications, Inc, working on NATS (@nats_io)
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
So
first,
let's
talk
about
messaging.
What
is
messaging
wikipedia
defines
a
messaging
as
message
oriented
middleware,
which
is
what
Nats
is
it's
software
hardware
infrastructure
supporting
the
sending
and
receiving
messages
between
distributed
systems,
I
kind
of
like
Ken,
klinken,
Stein's
description.
Middleware
is
the
intersection
of
the
stuff
that
network
engineers
don't
want
to
do
with
the
stuff
application
developers
don't
want
to
do.
We
don't
mention
this
one
we're
interviewing.
A
So
why
does
CN
CF
need
messaging?
As
cloud
technology
has
matured
distributed
systems
architecture
has
been
disrupted
via
decomposition.
We've
moved
from
these.
These
large
monolithic
applications
to
microservices
spread
out
all
over
the
place
and
communications
has
lagged
a
bit
a
technologies
needed
to
address
some
very
some
use
cases.
We
need
multiple
messaging
patterns,
bundled
into
one
technology,
location,
transparency,
I
shouldn't
have
to
know
exactly
where
everything
is
to
connect
to
it.
A
The
decoupling
of
data
producers
and
consumers
and
built-in
load
balancing
Nats
was
created
specifically
to
meet
these
needs
for
the
next
generation
of
cloud
native
applications.
Now
what
is
Nats
Nats
is
a
seven-year-old
production,
proven
cloud
native
messaging
system
made
for
developers
and
operators
who
just
want
to
do
their
jobs.
People
who
don't
want
to
worry
about
messaging
just
want
something
simple
that
works
the
DNA
of
Nats.
What
what
makes
Nats
up
what's
behind.
It
is
performance,
simplicity,
security
and
availability.
A
So
how
did
Nats
come
about
NASA's
created
by
Derek
Collison
Derek's
been
building
messaging
systems
upwards
of
25
years.
He
started
at
10
Co,
whereas
chief
architect
developing
a
lot
of
the
messaging
systems
there.
He
was
a
technical
director
at
Google,
he
architected
Cloud,
Foundry,
CTO
and
chief
architect
at
VMware
and
formerly
at
Apps
era,
which
was
container
container
based
technology
and
now
he's
founder
and
CEO
at
cinavia,
where
we
maintain
that
and
we
do
have
a
very
engaged
user
community.
A
Quite
a
few
contributions,
a
very
healthy
slack
community
too,
so
an
overview
Nance
is
pure
publish/subscribe
and
based
on
this,
we
build
common
message
patterns.
On
top,
we
support
a
clustering
of
servers
with
built-in
Auto
discovery.
We've
got
clients
for
over
30
programming
languages,
log
base
streaming
to
guaranteed
message
delivery,
and
then
we
also
have
some
CN
CF
integrations
Prometheus
nats
exporter
for
exporting
nats
metrics
into
Prometheus,
and
a
kubernetes
operator.
A
Nat
supports
a
range
of
technical
use
cases
general
messaging
in
the
cloud
micro
services,
transport
control,
planes,
service
discovery,
we're
also
found
an
IOT
mobile
and
Big
Data
out
messaging.
I
need
to
get
one
message
out
to
many.
Thousands
of
subscribers
replacing
our
augmenting
legacy
messaging.
Well,
as
I
said,
Nikki
know
we're
finding
that
many
of
our
users,
as
they
move
from
on-prem
to
the
cloud,
find
that
their
legacy
old,
do-it-yourself
messaging
technologies
just
don't
fit
the
bill
and
they
find
that
Nats
really
helps
them
with
it.
A
A
That's
don't
want
to
lose
too
much
sleep
over
that,
but
that's
how
we're
liable
Nats
is
for
our
users
and
the
other
use
case.
I
love
is
Nats
on
a
cell
phone
and
when
the
cell
phone
vibrates
too
much
their
application
sends
a
message
over
Nats
through
to
the
cloud
that
aggregates
and
listen
for
these,
when
too
many
vibrations
happen
in
one
spot,
it's
an
earlier
earthquake
detection
system.
So
it's
not
saving
lives.
I
love
that
it's
called
the
circular
world,
so
some
contribution
statistics,
200
contributors.
A
We
have
30
public
repositories
about
25
million
NAT
server,
dr.
hub
pulls
about
7
million
at
streaming,
server
pools
a
healthy
slack
community
and
pretty
good
cadence
of
Nats
releases
about
20
over
the
last,
what
six
years
or
four
years
so
about
five.
A
year
now
before
we
go
on,
let's
talk
about
messaging
patterns
in
general
oops,
so
Nats
has
three
built-in
patterns
publish/subscribe.
A
So
that's
where
you
publish
data
to
a
subject
and
the
subjects
just
a
string
in
that,
so
some
identifiers
publish
they
do
a
subject
where
one
to
many
subscribers
will
receive
the
data.
This
is
a
fan-out,
so
I
might
have
a
thousand
subscribers
listening
to
the
same
subject
and
I
send
a
message
from
a
publisher
to
this
and
it
gets
fanned
out
to
your
thousands
of
subscribers.
We
also
have
a
request
reply.
That's
where
you
send
a
request
message
and
we
still
use
underlying
publish
subscribe,
but
we
use
guaranteed
unique
subjects.
A
I
see
you
send
a
request
message
on
a
unique
subject
with
a
unique
reply
and
that
creates
a
logical,
one-on-one
requests
reply.
We
also
have
load
balance
cue
subscribers,
so
these
are
subscribers
that
are
bundled
together
in
a
group
and
they're
all
listening
on
the
same
subject,
but
the
server
will
only
send
a
message
to
one
of
these
subscribers
and
if
you
can
start
out
with
a
group
of
one
where
that
subscriber
will
receive
every
single
message
pub
its
published
to
that
subject,
and
then
let's
say
you
want
to
auto
scale.
A
A
So
let's
talk
about
Nats,
DNA
performance
and
scalability
simplicity,
security
and
availability,
or
what
makeup
Nats
a
good
way
to
think
about
things
is
that's
it's
just
what
you
need
and
none
of
what
you
don't.
We
try
to
be
very,
very
simple
and
easy
to
use.
So,
let's
talk
about
performance
performance
is
a
part
of
every
single
decision.
We
make
any
PR,
we
merge,
we
look
for
performance,
we
take
a
look.
We
take
a
very,
very
careful
analysis
of
the
fast
path
you
know
is
this
gonna
require
extra
locking?
Are
there
extra
memory
copies?
A
A
That's
how
we
think
about
Nats
and
scalability,
and
we
found
keeping
that
simple,
has
worked
extremely
well,
but
just
as
important
as
how
we
do
this
and
how
we
look
at
performance
is
what
we
haven't
implemented.
We
try
to
minimize
state
in
the
corn
at
server,
so
we
in
corn
ATS
basic
Nats.
We
don't
provide
any
message
guarantees
we
provide
at
most
once
it's
up
to
the
application
to
make
sure
the
message
gets.
There
sounds
a
little
fragile
I'll
discuss
that
more
in
a
bit.
A
We
don't
support
transactions,
nor
do
we
support
message:
schemas
Nats
as
payload
agnostic,
nor
things
like
mqt,
T's,
last
will
and
testament
or,
if
you're
familiar
with
JMS
message
groups.
These
are
all
things
people
have
asked
for
us
and
you
know
I
hate
to
say
no,
but
it's
not
part
of
net,
but
what
this
yields
is.
18
million
messages,
a
second
with
multiple
streams,
we've
gotten
up
to
around
80
million
messages.
A
second
so
Nats
can
perform
extremely
well
because
of
these
core
values.
We
maintain.
A
Let's
talk
about
simplicity.
We
aim
for
ease
of
use
from
installation
through
operation.
We
have
a
single
binary.
It's
a
very
small
docker
image,
spins
up
very
quickly
no
external
dependencies.
Our
protocol
itself
is
simple.
It's
tech
space
with
just
a
handful
of
verbs
that
are
used.
We've
got
very
easy
to
you:
parse
JSON,
return
for
monitoring,
endpoints
and
in
a
very
straightforward
configuration.
A
With
such
little
configuration,
clients
only
require
a
Ural
and
credentials,
and
servers
only
really
need
well.
There's
one
configuration
file
that
you
don't
even
have
to
use
and
a
few
command
line
parameters,
so
clustering
is
automatic
and
how
this,
how
this
works
with
simplicity
is
that
you
configure
just
a
couple
seed
servers
and,
as
you
want
to
scale
up
your
cluster
point
them
to
these
seed
servers
and
everything
talks
about
everything
else.
Your
cluster
topology
is
shared
and
you
don't
have
to
configure
your
cluster
statically.
You
can
grow
or
shrink,
as
you
need
to
supported.
A
Clients
are
also
notified
of
these
cluster
topology
changes.
So
that
means
you
don't
have
to
configure
your
clients
as
to
where
every
node
and
your
NAT
server
cluster
is
you
just
need
one
or
two?
They
learn
about
the
rest
and
there's
a
very
straightforward
and
simple
API.
Here's
an
example
go
program.
A
You
connect,
we're
gonna,
be
nice
and
defer
close,
and
then
you
publish
you,
publish
a
message.
You
publish
it
to
a
very
simple
topic
or
subject
and
then,
since
Nats,
its
payload
agnostic,
I
just
pass
a
byte
array
of
hello
and
then
I
flushed,
just
to
make
sure
that
the
message
gets
out
before
the
application
ends
and
I
want
to
check
for
errors.
A
Here's
a
Java
subscriber
that
will
receive
and
print
that
message.
I
connect
passing
a
girl
and
a
port
optionally
I
could
include
user
credentials
in
there
or
include
user
credentials
in
that
connect,
call
itself
and
then
I
subscribe,
give
it
a
lambda
function
or
just
prints
out
that
it
received
a
message
and
that
subscribe
waits
in
another
thread
and
you
just
sit
and
wait
for
messages.
That's
how
simple
a
simple
math
subscriber
is:
let's
talk
a
bit
about
security,
nat
secures
distributed
systems
through
TLS
user
token,
based
authentication
and
authorization.
A
You
can
update
these
at
any
time
through
a
configuration
reload,
so
you
don't
have
to
take
the
net
server
down
to
change
these.
We
have
TLS
support,
so
we
support
its.
It's
simple
configuration
the
NAT
server.
We
support
bi-directional
TLS
with
client-side
certificates.
Certificate
authorities
are
supported.
We
default
to
the
most
secure
ciphers,
but
you
can
override
these
and
override
curve
preferences
in
case
you're,
connecting
with
older
legacy
systems,
credentials
with
the
username
or
password
or
token
are
associated
with
the
connection.
A
We
have
authorization
with
permission
based
roles.
All
it
boils
down
to
is
who
can
publish
to
what
topics
or
subjects
and
who
can
subscribe
to
what
subjects
and
again
we
have
configuration
reload
where
you
can
update,
add
or
remove
TLS
certificates,
add
or
remove
credentials
and
grant
or
revoke
permissions.
The
sanae
dia
team
we're
working
on
a
new
architecture
and
look
for
this
in
several
months,
where
no
private,
keys
or
passwords
will
be
stored
on
the
system
and
availability.
A
Here's
where
Nats
really
differentiates
itself
from
other
messaging
systems,
so
Nats
prioritizes
the
health
and
availability
of
the
system
as
a
whole
rather
than
trying
to
service
one
particular
client.
So
we
think
of
it
as
like.
A
dial
tone.
Nats
is
always
on
anytime.
You
go
to
connect
it's
always
on,
but
it
achieves
this
through
what
I've
called
selfish
optimization.
So
you
have
a
badly
behaving
client,
a
slow
consumer
who's,
not
keeping
up
the
server
needs
resources
to
to
handle
that
consumer
right.
A
Well,
what
Nats
does
is
it
cuts
the
consumer
off
in
the
interest
of
keeping
the
system
as
a
whole
resilient
other
badly
behaving
clients?
If
you
send
garbage
Nets
cuts
you
off
right
away.
We
also
have
full
mess
string
of
the
GNAT
servers,
and
what
this
means
is
that
no
matter
which
server
Goes
Down,
which
pod
you
kill,
there's
going
to
be
other
ones
that
know
about
the
system
as
a
whole,
and
it's
self-healing.
A
A
So
I
spoke
earlier
about
Auto
discovery,
so
the
resizing
of
a
server
cluster
can
be
facilitated
through
Auto
discovery.
You,
like
I,
said
you
start
with
a
few
seed
servers
and
then
add
servers.
Topology
changes
are
propagated
throughout
the
cluster,
allowing
servers
to
join
the
full
mesh
supported.
Clients
are
also
aware
of
topology
changes,
internal
knowledge
of
the
cluster
topologies
propagated
to
all
the
clients
and
you
they
can
automatically
failover
to
new
servers
in
the
cluster.
A
So
that
means,
as
you
add,
new
servers
to
the
cluster
clients
can
actually
connect
to
new
servers
they
never
originally
knew
about.
This
is
huge
in
cloud
computing
because,
as
you
all
know,
pods
come
up
and
go
down.
Images
come
up
and
go
down,
so
this
results
in
no
configuration
changes
for
clients
when
the
cluster
or
topology
changes
some
of
our
users
really
like
the
resilience
of
Nats.
You
know
hundreds
of
days
of
uptime
simplicity
is
a
prerequisite
for
reliability,
and
we
found
this
to
be
true
by
keeping
things
really
simple.
A
We
found
that
we
can
build
large
scalable
systems.
So
let's
talk
a
bit
about
delivery
modes.
How
badly
do
I
need
a
message,
and
so
first
what
are
delivery
modes.
Delivery
mode
is
just
a
guarantee
of
the
message
being
delivered
so
at
most
once
is
really
it's
no
guarantee
of
delivery
messages
can
be
lost.
It's
up
to
your
application
to
realize
the
message
can
be
lost.
It
sounds
really
fragile,
but
it's
not
that's
how
the
internet
works
today.
Just
think
about
your
HTTP
requests.
A
You
don't
know
if
they're
going
to
get
there,
you
timeout
you
we
try.
Now.
There
are
cases
where
you
need
at
least
once
messaging,
so
a
message
will
always
be
delivered,
but
in
some
cases
it
can
be
delivered
more
than
once.
These
cases
are
pretty
rare
or
you
know
typically,
you'll
have
both
parts,
the
client
and
the
server
going
on
at
the
same
time
come
back
up.
A
You
might
get
the
same
message
redeliver,
but
nowadays
most
people
are
designing
their
applications
to
be
idempotent,
so
hopefully
they'll
handle
this
case
and
then
there's
exactly
once,
which
I
argues
unnecessary,
especially
with
the
advent
of
the
12
factor
app.
But
it's
also
very
very
complex,
and
this
complexity
really
slows
things
down,
so
cornets
provides
at
most
once
delivery
guarantees,
and
this
is
your
your
internet.
Quality
of
delivery.
Nats
streaming
provides
at
least
once
delivery
guarantees,
so
you'll
get
the
same.
A
You'll
get
a
message
guaranteed
to
be
delivered,
but
you
might
get
it
more
than
once
Nats
streaming.
So
what
is
nat
streaming?
That
streaming
is
a
data
system
powered
by
Nats
so
rather
than
build
this
into
our
core
Nats
infrastructure,
we've
layered
it
on
top.
So
some
of
the
features
include
at
least
once
delivery.
You
can
replay
by
time
or
sequence
number.
So
you
can
say
give
me
the
last
hours
worth
of
messages
on
this
on
this
subject
or
give
me
every
message.
Since
sequence:
number
500,
there's
last
value.
A
Caching,
you
can
use
it
when
you
come
up
as
your
application
give
me.
The
last
value
give
me
the
last
message
that
was
received
for
initialization.
You
have
the
concept
of
durable
subscribers
where
you'll
continue
to
get
the
stream
of
messages,
and
if
communication
is
interrupted
anyway,
your
client
goes
down
loses
connectivity
with
the
server
when
it
comes
back
up.
It'll
pick
up
exactly
where
it
left
off.
You've
got
rate
matching
per
subscriber
I
mentioned
slow
consumers
with
core
Nats
with
NAT
streaming.
A
It
feeds
data,
it
sends
messages
to
consumers
at
the
rate
they
can
handle.
So
you
might
have
one
can
sumer
receiving
messages
at
5,000
messages
a
second
and
another
one
that
can
process
five
messages.
A
second
Nats
will
rate
limit
these
for
you,
we've
got
memory
file
or
database
storage
and
high
availability
through
fault,
tolerant
or
clustered
configurations.
This
clustering
is
a
little
bit
different
than
core
Nats.
A
How
do
we
monitor
Nats?
Well,
each
server
is
monitoring
it
and
pendant
Lee
and
I
go
back
to
the
very,
very
simple
case.
We
make
things
simple.
You
simply
enable
a
monitoring
port
and
then
pull
an
endpoint
for
metrics.
We
have
a
variety
of
metrics,
you
can
pull
and
then
the
simplicity
allows
you
to
build
more
complex,
tooling.
A
On
top
monitoring,
information
is
JSON,
formatted
very
easy
to
parse,
so
some
of
the
tooling
you
can
build
on
top
and
wally
here
actually
wrote:
nat
stop,
which
is
a
great
development
tool
to
look
at
the
server
and
see
what's
going
on
if
you've
used
top,
they
should
look,
you
know
somewhat
familiar,
but
for
the
enterprise
we've
written,
a
gnat's
prometheus
exporter
that
pulls
metrics
from
the
nat
server.
Let's
Prometheus
aggregate
it,
and
then
you
know
we
we
use
Griffin
as
a
dashboard,
use
your
favorite
dashboard,
and
you
can
view
Nats
metrics
like
this.
A
What's
coming
up
in
the
future
of
Nats
will
have
extended
client
support
for
n
keys,
which
would
be
a
utility
for
public
key
signatures.
Utilizing
edie
255,
one
nine
will
have
cloud
provider
integrations
events
that
might
happen
in
Google
or
Amazon
will
surface
in
two
Nats
and
let
you
consume
those
events.
A
We're
looking
at
features
to
connect
and
bridge
clusters
and
at
server
to
create
a
gnat's
deployment
at
a
global
scale,
and
this
is
big
I
know.
I,
know
it's
big,
but
we
want
to
be
able
to
provide
connectivity
between
millions
and
you
gotta,
aim
high
billions
of
clients,
think
clusters
upon
clusters
upon
clusters
of
NAT
servers
that
are
able
to
communicate
and
then
we're
going
to
continue
work
on
integrations
with
other
CN
CF
projects,
including
more
support
for
Prometheus
and
kubernetes.
A
If
you
want
to
contribute,
we
welcome
contributions
of
all
kinds.
Some
ways
include
highlighting
your
natchez
or
insights
and
the
nach
nats
blog.
You
can
fix
a
bug,
you
can
add,
fix
or
clarify
documentation.
It's
sometimes
embarrassing
the
number
of
typos
PRS
we
get,
you
can
propose
or
add
a
feature
and/or
just
present
your
own
Nats
project
at
meetups.
We
get
quite
a
few
of
those.
A
So
now
let
me
go
to
it.
I'll!
Do
a
quick
demo
and
talked
about
how
simple
Nats
is
I'll.
Just
show
you
what
the
protocol
looks
like
I
call
this
the
human
Nats
client,
so
I'm
going
to
start
on
that
server.
Here,
I
started
it
with
D
V,
which
stands
for
debug
verbose.
It's
going
to
print
out
absolutely
everything,
and
instead
of
a
client
I've
written
I'm,
gonna
use
telnet.
A
I've
connected
so
I've
connected
the
NAT
server.
The
NAT
servers
were
turned
some
information
back
with,
like
the
server
ID,
some
authorization
information,
whether
or
not
I
need
to
use
TLS
the
max
payload
things.
I
can
use
in
my
client
to
make
my
client
more
resilient
and
then
I'm
also
going
to
tell
that
here.
A
So
what
I
did
is
I
subscribed
to
a
subject
called
Coupland
Nats
and
I
gave
it
an
ID
of
1
the
IDS.
The
ID
is
required
because
you
might
want
to
have
multiple
subscribers
on
the
same
subject
within
an
application.
And
now
what
I'm
going
to
do
down
here
is
gonna
publish
to
cube
con
Nats
and
I'm
gonna,
say
I'm
gonna,
publish
5,
bytes.
A
B
A
D
A
C
A
E
I
have
follow
a
few.
The
conference
regarding
service
mesh
before
coming
here,
I'm
kind
of
surprised
to
see
middleware
still.
How
do
you
position
this
compared
to
a
service
mesh,
because
for
me,
the
service
mesh
was
to
take
this
kind
of
middle
way
to
cut
it
into
what
they
call
proxy
and
to
put
as
a
sidecar
next
to
each
and
every
piece
of
software,
which
makes
the
whole
system
self
provisioning
instead
of
Auto
provisioning.
A
That's
a
good
question
yeah,
so
we
do
have
some
features
and
Nats
that
we
haven't
talked
about
that
we
can
go
into
more
depth
as
far
as
message
patterns
and
stuff
that
kind
of
might
fall
outside
of
the
service
mesh.
I
agree.
There
is
some
overlap
there,
but
Nats
is
almost
more
specialized.
If
you
have
different
patterns,
you
want
to
use
that
don't
fall
into
service
service
match.
You
can
use
it.
Okay,.
E
A
First,
first,
let
me
say:
they're
very
similar
in
that
they
are
log
based
streaming
products,
so
so
they're
similar
they're,
a
big
differentiator,
is
the
net
streaming.
Clients
don't
have
to
keep
track
of
an
offset,
so
that
is
actually
kept
inside
the
server,
and
that
means
you
can
make
the
clients
very,
very
simple
operations,
don't
to
worry
about
where
a
client
left
off.
They
don't
have
to
worry
about.
Losing
that
offset.
Nats
takes
care
of
that
for
you
and
are.
E
A
F
Hi
I've
got
a
quick
question
if
you
have
a
setup
where
you
have
multiple
methis
with
high
availability
enabled
or
some
set
up
and
what
happens
so
is
there?
Is
there
some
resiliency
in
memory
or
do
you
use
the
multiple
service
to
distribute
the
load
in
a
way
that
one?
What
if
one
goes
down
messages
or
losts
mess.
A
With
core
Nats
messages
are
lost,
and
that's
because
we
only
give
the
at
most
once
delivery
guarantee
and
what
it
makes
our
algorithm
to
keep
state
within
the
servers
very,
very
simple,
and
we
don't
actually
have
to
keep
exact
state
in
the
servers,
because
we
don't
give
that
guarantee
in
that
streaming.
We
do
have
that
at
least
once
guarantee,
so
nat
streaming
uses
a
different
algorithm.
On
top
of
that
that
uses
raft.
Okay,
thanks.
G
A
Rabbit
rabbit
is
rabbits
more
of
like
a
Swiss
Army
knife
right,
it
does
a
whole
lot
of
things
and
Nats
is,
is
very
specialized.
Nance
is
specialized
and
works.
Well,
you
know
in
the
cloud
works
very
well
for
deployments
that
need
extremely
high
performance,
so
what
I
would
invite
you
to
do
is
compare
the
both
and
then
let
us
know
what
you
think.
Please
write
a
blog.
H
A
H
A
Yeah,
unless
you
lose
connectivity
or
something
like
that,
then
ordering
guarantee
is
guaranteed
and
NAT
streaming,
but
in
core
Nats.
It's
up
to
your
application,
then
right
if
he
might
publish
a
message
and
not
realize
it
wasn't
delivered
and
published
another
one.
So
it's
at
that
point.
It's
up
to
your
application
to
guarantee
ordering
unless
you're
using
that
streaming,
which
will
guarantee
order.
One.
H
A
I
Thanks
I
have
a
pub/sub
case
and
I
wanted
to
ask
about
Altaf,
occasionally
our
ization,
so
you
said
to
connect,
you
need
to
identification
some
token
and
password
or
username
a
password
doesn't
matter,
and
you
said
to
reload
credentials.
You
need
to
reload
some
configs.
That
means
the
server
knows.
Of
course,
the
credentials
is
there
API
to
manage
those
credentials
on
a
server
site.
No.
A
I
A
Is
we
have
what's
called
wild
carding,
yes
and
yeah,
and
that
that
would
probably
take
quite
a
while
to
explain?
But
basically,
if
you
remember,
I
did
cube
con
dot,
Nats
right,
you
can
suck
each
one
of
those.
We
consider
a
token
you
can
substitute
one
of
those
tokens
with
either
a
star
which
means
anything
matches
that
token
or
greater
than
which
means
anything.
A
A
Headers,
no,
no
header
support.
That's
part
of
the
simplicity,
part
of
Nats
I
can
share.
You
know
what
what
you
can
do
is
look
at
Nats
streaming
and
what
we
did
for
that
was
we
actually
needed
headers
for
NAT
streaming,
so
we
use
protobufs
on
top
of
that
to
almost
build
a
custom
protocol
on
top
of
nets.
D
A
Yes,
well,
somebody
has
contributed
a
mirroring
solution
for
NAT
streaming,
so
you
know
I,
imagine
something
along
the
lines
of
two
geographically
separated
sites
and
you
want
to
create
a
mirror.
I
actually
think
that
was
RI
paneer
right,
who
did
the
NAT
streaming
mirror,
and
we
actually
have
a
link
to
that
on
our
website.
J
A
Can
do
that,
so
what
happens
is
exactly
that,
after
a
period
of
time
or
certain
size
of
messages
that
have
accumulated
the
nat
streaming,
server
will
trigger
either
a
particular
either
they'll
either
partition
the
file
and
take
about
a
quarter
of
it
off
and
archive
it
for
you
or
it
can
trigger
a
script
where
you
can
do
whatever
you
want
with
that
chunk
of
file
and
move
it
to
some
long-term
storage.
So
then
the
streaming
server
will
keep
operating.
You
don't
have
any
manual
intervention.
You
necessarily
need
to
do
and
does.
J
B
A
So
we've
got
a
couple
different
stories
there.
One
is:
we've
got
a
fault-tolerant
pair,
you
can
set
up,
one
is
live,
one
is
warm
and
live.
One
goes
down
the
warm
takes
over.
It's
your
responsibility
to
make
sure
that
that
data
store
your
persistent
value
and
claim
there
is
backed
up.
We
have
another,
we've
got
full
clustering
where
and
that
uses
raft
where
you
have
independent
file.
So
let's
say
you
had
three
of
them.
You
might
have
three
different
persistent
volume
claims
and
they
would
all
maintain
consistency
through
the
raft
protocol
over
net
streaming.