►
From YouTube: Open Match Community Meeting October 2020
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
C
A
Exactly
I
mean,
as
I
say
later,
we
can
all
put
on
like
the
snap
camera
halloween
filters
and
make
it
a
spooky
meeting.
A
A
A
Yeah
so
just
know
that
that
that's
happening-
and
you
know
if
you,
if
you're
wanting
to
get
more
involved
in
actually
contributing
code
or
being
involved
in
some
of
the
design
discussions.
That
would
be
a
cool
place
to
do
it.
We
can
still
cover
them
here,
but
that
gets
a
little
more
in
depth.
So,
just
so
folks
are
aware
of
the
difference.
C
B
B
So
roughly
I
have
for
our
agenda
any
community
updates
or
questions.
Let's
just
get
those
done
first
and
then
we
have
an
upcoming
1.1
release
and
then
stuff
that's
happening
on
the
master
branch
right
now,
which
is
backfill.
Some
query
improvements,
query
api
and
the
database
stuff
caleb
just
mentioned.
So
I
think
first
of
all
does
anyone
want
to
say
hi
or
say
what
they're
working
on
or
have
any
questions
of
that
kind
of
stuff.
E
I
can
I
can
go
ahead.
Real
quick.
C
C
I
know
I'm
sorry,
but
there's
a
game
in
the
wild
that
that
we're
hosting
on
it
right
now
we
actually
migrated.
We
successfully
migrated
our
core,
for
I
can't
say
that
yeah
we
migrated
our
core
for
a
bunch
of
matchmaking
games
that
are
currently
in
evaluation,
and
it's
been
really
smooth
and
open
match
was
really
seamless
transition
for
us
from
from
what
we
were
using
before
to
to
being
pure,
pure
open
match.
C
C
That
was
a
long
time
coming
and
a
lot
of
work,
and
there
was
just
a
a
really
great
landing
zone
for
for
that
effort.
So
yeah
would.
C
No
no
soon.
A
C
We
have,
we
have
some
rings
that
we're
doing
now
for
for
releasing
internally
for
unity
matchmaking,
but
the
main
takeaway
is
that
we,
we
moved
a
bunch
of
folks
to
open,
match
and
then
found
some
bucks
and
so
we're
creating
some
issues
for
for
some
of
those
bugs
and-
and
we
have
some
some
fixes-
that
we're
testing
right
now
that
we'll
submit
for
for
prs
around.
C
For
example,
if
you
call
a
function
that
doesn't
exist,
the
synchronizer
window
holds
for
the
max
duration
of
the
proposal,
registration
window
or
the
proposal
return
window.
Instead
of
giving
up
on
the
function,
not
existing,
it
kind
of
waits
to
try
retry
and
see
if
the
function
never
shows
up
in
that,
like
one
to
three
second
time
window
which
which
pauses
something
so
we
have
a
bug
and
we're
going
to
submit
it.
C
It's
only
if
you've
misconfigured
stuff,
but
that
did
happen
and
so
we're
we're
gonna
we're
gonna
help
out
there.
That's.
B
That's
kind
of
grpc
being
grpc
yeah
right,
hey,
you
know
what
grpc
is
awesome.
It's
really
well
thought
out,
but
it
in
thinking
things
out.
It
makes
some
design
choices
that
are
different
from
others
like
connection
library
typical
stuff.
So
it
doesn't
always
behave
exactly
how
you
expect
it
to
be
well.
A
B
No,
the
the
there's
already
a
pr
which
I
just
need
to
double
check
as
I
think
it's
ready
to
go
for
open
match
she
just
we
have
to
call
grpc
the
right
way
to
get
the
behavior
we
wanted.
So
that's
the
deal.
A
F
Whoa,
I'm
sorry
well
as
a
I
guess,
a
reminder,
or
you
know
something
that
I
want
to
you
know
amplify.
We
do
have
the
open
match
ecosystem
repo.
So
if
you
are
working
on
anything
interesting,
we
would
really
hope
that
you
would
contribute
there,
whether
it
be
any
cool
projects.
You
know
whether
it's
using
open
match
and
a
gun
is
daniel.
F
I
want
you
to
talk
about
your
project
and
yeah,
so
look
forward
to
seeing
that
we're
gonna.
Add
it
to
our
we're
gonna.
Add
it
to
the
open
mesh
dock
so
that
you
can
easily
navigate
to
it,
and
hopefully
we
can.
You
know
list
out
all
the
cool
things
that
people
are
working
on,
so
that,
if
you're
inspired
by
those
projects,
you
can
you
know,
create
something
interesting
yourself.
B
Well,
unless
there's
anything
else
can
move
on
to
or
we
can
come
back
to
anything
outside
afterwards.
I
guess
so
open
match
1.1
release.
John
you've
made
the
cut
for
the
branch.
At
this
point,
I
believe
so
anything
going
in
now
is
not
going
to
make
it,
although
you're
maybe
having
some
problems
with
the
release.
So,
okay,
so
it's
coming.
It's
just.
F
Sure
so
I'm
currently
going
through
the
release.
I
am
suffering
from
environment
issues
at
the
moment,
so
I
am
firing
up
a
vm
to
do
the
release
outside
of
that,
I'm
making
sure
that
all
of
our
testing
works,
because
in
different
environments
the
tests
are
failing.
So
I
just
need
to
make
sure
that
everything
is
running
smoothly
because
it's
passing
in
one
environment
and
failing
in
another,
so
I
will
be
sure
to
update
the
community
as
far
as
anything
that's
going
on
with
the
release.
F
I
will
probably
reach
out
to
the
community
to
see
if
anybody
wants
to
run
this
in
their
environment
to
see
if
they're
getting
the
same
issues,
because
if
so,
then
I
probably
just
need
to
ask-
I
guess
our
parent
company
google,
for
a
like
actual
linux
machine.
So
I
can
do
these.
Do
these
builds
myself
there.
D
D
B
Issues
go
away,
that
is
true
yeah,
so
I
I
I
think
in
general,
our
release
could
use
improvement
like
mo.
Basically,
all
of
it
probably
could
be
automated
to
the
point
where
we
just
tagged
something
and
it
does
a
release
with
that
tag,
and
then
we,
you
know,
do
the
fill
out
the
github.
You
know
notes
or
whatever.
That's
obviously
not
automated,
but.
E
B
So
there's
several
awesome
changes
coming
in
the
big
one.
Probably
people
mostly
care
about
is
backfill.
We
have
a
design
dock
that
is
linked
from
the
github
issue
on
backfill.
If
you
are
interested
in
going
into
the
details,
they
are
there
we're
pretty
happy
with
the
design
now
and
we're
gonna
start
making
changes
to
the
main
repo
there's
already
a
couple
pr's
out
for
adding
protos
and
changes
to
state
store
and
stuff
already.
I
don't
know
how
much
we
want
to
get
into
any
of
the
design
on
that.
B
B
Most
people
here
have
already
seen
it,
so
I
don't
want
to
just
repeat
myself
and
all
the
designs
are
there
and
everything
I
thought.
Maybe
I
should
do
for
press
30
at
all.
Does
anyone
have
any
opinion
of
I?
I
think
it
might
be
useful
for.
C
C
What
is
the
design
that
we're
getting
happier
about
do
from
the
perspective
of
someone
who
wants
to
come
into
the
open
match
environment
and
understand
like
not
what
is
backfill,
but
what
is
it
about?
How
open
match
approaches
backfill
that
that
works?
Well
from
from
your
discovery
and
discussions.
C
Yeah,
I
think,
there's
part
of
this.
That's
like
we
could
describe
backfill
and
for
those
joining
we
can
take.
We
can
take
a
swing
out,
maybe
a
30
second
version
and
then
elaborate
a
little
bit,
but
I'm
imagining
you
know
when
people
come
and
understand
this
content
later
they
might
want
to
hear
about
what
what
we
considered
about
backfill,
that
that
open
match
is
going
to
help
with.
B
Right
so
I
think
the
short
definition
of
backfill
is
you
have
a
server
running
or
starting
up,
and
you
want
more
players
to
come
in.
This
could
either
be.
You
have
a
session
based
game
and
you
want
some.
You
know
someone
leaves
and
you
want
a
replacement
or
it
could
be
a
social
lobby
where
you
just
keep
them
running
for
hours
or
whatever
and
players
come
in
and
out
and
they
you
know,
go
to
the
shops
or
whatever,
and
they
see
other
places
running
right
now
going
to
different
shops.
B
That
kind
of
thing,
so
that
has
been
more
difficult
to
implement
an
open
mat.
So
far,
currently
we
recommend
using
tickets,
but
we
are
working
on
a
new
concept
which
is
a
backfill.
It's
a
lot
like
a
ticket,
it
has
search
fields,
it
has
extensions,
so
you
can
put
whatever
data
you
want
on
it.
It
has
an
id,
but
it
behaves
differently.
B
You
know
a
new
game
and
I
I
want
100
players
because
I'm
a
battle
royale,
but
I
only
had
50
at
the
moment,
so
I
want
to
put
them
in
a
lobby
and
let
them
run
around
in
a
lobby,
but
I
want
to
find
another
50
players
and
we
we
do
it
right
away
so
that
if
the
server
takes
a
while
to
start
up,
more
players
can
come
in
and
be
waiting
on
the
server
starting
up.
B
The
other
thing
that
can
happen
is
the
game.
Server
can
reach
out
to
open,
match
and
say:
hey.
You
know
here
are
my
details.
I
want
more
players,
both
are
supported
and
they
both
have
update
guarantees
about
like
open,
open
matches,
doing
the
work
of
trying
to
decollide
when
the
match
function
suggests
something.
But
the
game
server
also
says:
hey
things
have
changed.
B
Working
through
the
the
edge
cases-
and
I
think
we've
done
a
pretty
good
job
of
giving
you
a
design
that
handles
those
ed
cases
in
a
way
that's
pretty,
like
you,
don't
have
to
think
about
there's
a
ton
of
veg
cases.
It's
just
you
do
the
sensible
thing
and
open
match
just
like
handles
edge
cases
through
that
sensible
thing.
B
You
know
we
had
a
lot
of
questions
about
how
to
actual
like
what
is
the
sensible
thing
in
that
a
way
that
makes
it
easy
for
us
to
do
the
right
thing,
but
I
believe
we've
arrived
there,
so
you
just
on
a
match,
just
return
a
backfill
or
if
you
wanna,
update
the
backfill,
you
just
change
the
fields
in
the
backfield
and
then
we
put
it
on
a
match,
and
that
says
it
it'll
all
flow
through
the
system
it
will
update.
B
There
are
some
also
changes
into
your
director
as
well,
because
you
now
need
to
not
always
allocate
a
match
and
the
assignment
flow
goes
through
back
goes
through
a
different
mechanism
triggered
by
your
game
server.
If
you
are
using
backfill
versus
assignment
float
today,
the
director
gives
assignments
back
right
away.
B
There
are
various
reasons
for
that.
I
don't
think
we
need
to
go
into
them,
but
it's
a
little
bit
of
a
change.
B
Nothing
complicated
the
most
work
you're
probably
gonna
have
to
do
is
in
your
game
server,
actually
having
a
bit
the
ability
to
reach
out
to
open,
match
and
any
logic
there,
hopefully
we'll
end
up
with
some
libraries
or
something
for
various
game
engines,
but
there's
a
little
bit
there
does
anyone
else
want
who's
working
on
open
the
working
on
backfill
want
to
add
anything
or.
H
Is
like
an
anti-ticket
in
or
like
hole
and
electron?
If
we
compare
in
electrical
way,
if
you
think
about
this,
so
I
mean
when
backfill
meet
some
a
number
of
tickets.
H
These
tickets
disappear
so,
but
they
also
should
be
queried
with
the
same
search
fields,
and
now
we
should
provide
the
way
how
to
define
the
search
fields
and
in
order
to
be
queried
for
the
same
much
profile
as
normal
tickets.
So
I
imagine
that
we
could
use,
for
example,
in
in
a
range
filter.
H
We
can
use
an
average
between
min
and
max,
for
example,
to
and
put
it
in
in
this
search
fields.
So
we
are
thinking
of
how
to
properly
reuse
this
essentials
right
now
and
some
other
most
issues
we
currently
face
is
religious
changes
when
we
need
to
have
at
list
of
tickets
assigned
or
not
assigned
mapped
into
one
backfield,
which
are
waiting
for
assignments.
C
C
Function,
purview
the
same
way
that
you
can
understand
tickets
as
this
blob
of
data
that
it's
very
custom
backfills
are
the
same
way,
but
it
has
an
intuitive
representation
from
the
perspective
of
a
match,
isn't
complete,
and
so
you
can
represent
it
as
needing
to
be
filled
more
and
the
game
server
just
needs
to
know
about
it
and
then
you're
pretty
much
that
that's
the
extent
of
what
you
need
to
understand
from
a
match
like
a
an
open
match,
user
who's
going
to
be
developing
inside
of
the
framework.
C
One
one
concept
is
in
match
functions,
the
other
is
on
the
game.
Server
and
you're
in.
I
think
that's
a
pretty
pretty
compelling
considering
it
hits
all
the
edge
cases
it's
pretty
compelling
take
on
it.
B
Yeah,
I
I
think
this
has
been
the
most
requested
feature
of
open
match
like
all
time,
so
it's
really
excited
that
we're
co
code's
going
to
start
going
into
the
main
branch
like
probably
today,
so
if
the
reviews
go
well,
so
that's
awesome.
C
Let's
just
make
the
numbers
not
mean
anything
right,
super
exciting.
C
Cool,
I
guess,
does
anyone
have
any
questions
about
backfill?
I
think
we
have
the.
I
think
we
have
all
the
backfill
experts
in
the
room.
H
Probably
we
have
a
question
about
the
requirements.
How
many
tickets
can
wait
in
this
backfield
to
be
assigned,
so
we
need
to
get
the
this.
I
mean
io
caleb
have
some
limits
on
number
of
tickets,
which
could
be
in
this
backfield.
I
mean
regular
tickets.
C
H
Yeah
fine,
I
mean
probably
we
should
also
discuss
some
limitations
on
how
many
players,
in
this
case
tickets
could
be
waiting
to
be
backfilled.
I
mean.
I
Yeah,
I
think
that's
a
good
point
right
like
could
you
have
thousands
of
tickets
on
a
backfill
ticket
and
would
that
just
bog
the
system
down
and
lead
to,
like
you
know,
draining
the
pool
until
like
servers
respond,
but
also,
I
think
that
there
is
a
case
to
be
made
for
doing
backfill
as
the
only
way
to
make
matches,
which
means
you
see
one
ticket,
you
immediately
make
a
backfill
ticket
and
you
keep
adding
tickets
right
and
if
you
know,
100
players
show
up
and
you
have
100
player,
you
know
like
battle
royale
match.
I
Should
you
be?
You
should
probably
be
able
to
sign
those
right,
but
is
there
like
an
upper
limit
on
essentially
how
many
players
could
kind
of
be
in?
I
guess
it
kind
of
corresponds
to
a
match
right.
So
I
don't
know
if
open
match
has
has
taken
a
stance
on
that
right
now.
I
I
Since
it's
kind
of
up
to
the
users
of
open
match
to,
you
know
find
that
when
they
put
10
000
tickets,
things
are
are
bad.
Maybe
we
could
have
guidance
there
or
like
have
official
tests
there,
but
yeah.
B
I
I
generally
with
open
match
I
take
the
stance
of
like
we
try
to
make
it
run
good,
but,
like
you
need
to
run
your
your
test,
because
your
end
and
skill
test,
because
it's
possible
you're
gonna
hit
an
edge
case
an
open
match,
but
it's
also
really
possible
that
you're
gonna
hit
an
issue
with
your
mmf.
Having
n
squared
you
know,
runtime
complexity,
or
you
know
talking
to
server
startups,
taking
too
long
or
something
like
that.
So
there's
there's
a
lot
of
places
where
subtle
things
could
happen.
B
C
One
point
that
might
be
worth
just
specifically
out
of
scoping
right:
one
of
the
things
we
try
to
do
in
open
matches.
We
try
to
put
anyone
down
the
wrong
road.
I
have
seen
it
before
in
conversation
where
open
match
starts
to
look
like
a
traffic
manager
like
a
global
traffic
manager
or
an
ingress,
a
sort
of
like
terrifying
way
to
use
mapreduce
to
send
you
to
like
a
server
that
is
serving
requests,
requests
that
are
like,
like
lightly
longer
than
a
normal
web
request,
and
so
for.
C
C
Or
you
know
just
normal
services
event
driven
architecture,
maybe
even
think
about
denormalizing
the
batching
into
something
more
like
a
data
flow
pattern,
but
yeah
I
would.
I
would
veer
away
from
using
open
match
in
this
style.
Open
match
is
primarily
a
pressure,
ingress,
egress
mechanism
for
doing
real-time
map
reviews.
That
would
not
be
a
good
fit
for
that
type
of
problem.
So
I
I
don't
see
a
reason
why
to
andy's
point
where
we
would
need
to
limit
it
save
for
someone
trying
to
do
something
really
crazy.
C
There
could
be
a
thousand
person
game
like
I
get
it,
especially
if
there's
like
a
worldwide
event,
but
open
match
primarily
tries
to
be
a
real
time,
matchmaking
system,
not
necessarily
what
you
would
want
out
of
something
for
like
like
a
dating
app
or
event
planning
style,
matchmaking
find
find
the
local
you
know
find
the
conference
near
you
in
the
next
six
months,
type
of
thing
find
a
health
provider,
that's
a
different
kind
of
search.
B
C
As
a
part
of
the
backfill
work,
I'd
be
curious
to
understand
what
we
can
do
in
open
match,
though,
to
enable
we've
talked
about
reporting
on
stress
testing
in
open
match
in
general.
I
think
the
problem
has
always
been
around
scenarios,
so
we
definitely
have
some
more
that
we've
been
discovering.
I
think
this
idea
that
there's
a
a
scenario
where
we
have
very
large
matches
and
now
backfill
is
part
of
that
story.
We
should.
We
should
consider
that
as
part
of
some
piece
of
work,
someone
could
contribute
yep.
B
Definitely
there,
I
think,
there's
two
pieces
to
that
with
the
scale
testing.
There
is
just
like
a
scenarios
folder
where
you
can
add
new
scenarios.
If
you
want
it
fairly,
easy
we're
hoping
to
extend
it
for
backfill
to
include
more
functionality
for
backfill
scenarios,
but
also
the
the
scale
testing.
Another
improvement
we
can
make
is
making
it
easier
to
run
in
an
automated
way
or
something,
but
nobody
has
prioritized
doing
that
at
the
moment.
B
H
On
do
we
need
to
create
a
separate
ticket
with
this
google
docs
content
pushed
to
the
github
or,
as
I
mean,
proposal
stuff.
B
B
So
last,
but
here
or
next
here
is
there's
gonna,
be
an
exclu.
The
the
ranges
on
rain.
The
range
query
are
both
inclusive,
so
min
and
max
are
both
inclusive
there's
a
pr
from
unity
that
is
adding
the
ability
to
make
one
or
both
of
them
exclusive.
B
So
you
can
do
things.
You
can
put
two
match
functions
that
are
segmenting
a
range
that
will
be.
I
think
it's
ready.
I
have
to
double
check
coming
into
the.
B
The
merge
it'll
be
it'll,
it's
gonna,
miss
1.1,
but
1.2
probably
will
have
that
as
well
in
beta.
So
if
you
needed
that
functionality,
hey
unity,
contributed.
Thank
thank
them
cool.
Well,
unless
there's
anything
on
that,
let's
talk
about
unity.
What
are
you
doing
with
databases.
C
Guillaume,
do
you
do
you
want
to
talk
a
little
bit
about
just
maybe
the
framing
here?
Is
you
know
around
the
limits
that
we've
encountered
our
desire
to
understand
partitioning
and
also
like
what
the
what
database
technology
is
trying
to
do
in
open
match
like
what?
What
makes
a
good
fit
for
the
style
of
architecture.
E
Yeah,
so,
basically,
on
our
scale,
we
figured
that
we
were
reaching
the
limit
of
ccus
for
for
some
of
our
customers
and
we
were
not
able
to
horizontally
scale
either
om
query
already,
and
we
have
been
looking
at
what
sort
of
solution
we
could
have
to
to
fix
this
horizontal
scaling
and
also
like
allow
developer
to
have
like
better
performance
on
their
matchmaking.
E
E
E
E
So
probably
like
one
of
the
options
we
would
have
is
to
separate
oim
korean
the
data
layer,
and
so
that,
like
when
query,
because
we
can
become
like
completely
agnostic
of
the
db
technologies
we
are
using,
and
then
we
have
a
data
layer
that
we
implement
for
like
kind
of
drivers
for
the
for
the
for
the
database,
that
we
that
we
can
support
and
then
provide
like
those
options
for
the
for,
for
whoever
wants
to
implement
open
match.
E
So
that
means
that
we
will
still
be
able
to
use
like
the
current
implementation
so
using
like
radius
the
way
it
is
and
then
like,
provide
the
option
of
using
partitioning
with
with
a
third
party
database
that
could
be
like
whatever
we
find.
That
makes
a
cut
and,
like
I
said
like
right
now,
we're
looking
at
aerospike
and
android
is
enterprise
for
our
need,
specifically
or
need
of
like
off
scale.
C
One
of
the
interesting
struggles
or
one
of
the
challenges
that
anyone
coming
at
open
match
has
is:
it
comes
with
a
database,
and
so
we
can
definitely
get
some
like.
We
can
continue
to
assume
the
user
of
open
match,
and
folks
here
I
mean
this
is
where
some
feedback
would
be
useful
for
us
trying
to
understand
how
to
how
to
drive,
not
changes
but
like
improvements
and
enhancements
to
separating
aspects
of
the
hosting
challenges
from
like
the
app
what
open
match
is
trying
to
achieve
with
matchmaking
the
the
h.a
redis
takes
you
so
far.
C
If
we
want
to
get
partitioning,
we
need
to
talk
about
clustered
h.a
redis,
which
will
significantly
increase
some
of
the
challenges
of
hosting
open
match
and
open
match
might
not
necessarily
be
the
best
place
to
understand
how
to
like
grok
and
enable
hosting
of
that
type
of
infrastructure,
including
things
like
like
cluster
auto
cluster.
Auto
scaling
is
something
that
is
very
challenging
and
so
like.
If
that's
a
requirement
in
open
match,
we'd
want
to
understand
how
to
like
bring
that
type
of
expertise
into
the
the
project.
C
Whereas
there
are,
we
basically
want
to
enable
certain,
like
off-the-shelf
dbs,
to
also
be
accounted
for.
So
that's
that's
something
that
we
can
also
take
into
technical
steering.
But
you
know
if
anyone
else
from
the
community
has
like
databases
that
they'd
like
us
to
look
into
we're,
investigating
it
right
now
to
to
even
pursue
you
know,
ones
that
are
or
even
stranger
or
or
more
niche.
C
This
is
such
an
interesting
database
problem
from
a
extr
like
tight,
doesn't
have
to
be
tight
consistency
in
indexing,
but
it
does
need
to
be
extremely
fast
high
query,
high
parallelizable
query
with
with
instant
hydration
and
then
in
the
meantime,
we
also
have
to
have
this
consistency
between
synchronizing
windows.
So
one
of
the
things
that
we've
noticed
in
enterprise
redis
or
just
it's
really
redis
search,
which
is
an
indexing
mechanism
built
on
redis
that
we
think
might
provide
similar
functionality
to
what
ohm
query
provides.
C
Ohm
query
would
still
be
a
really
great
interop
layer,
but
yeah
redis,
search
and
then
aerospike
kind
of
has
that
concept
of
query
built
into
it.
So
we
think
we
might
get
really
interesting
scale
out
of
those
two
systems
from
not
just
a
partitioning
perspective,
but
also
like
enabling
a
higher,
singular
pool.
We
call
it
globalpull
something
that
we've
been
throwing
around
because
right
now
openmatch
is
a
global
pool
concept.
C
So
we
should
have
an
update
on
at
least
the
ones
that
we've
investigated
in
a
future
meeting
related
to
just
general,
like
proof
of
concept.
Throughput
might
not
be
done
exclusively
in
open
match.
To
begin
with
might
be
more
like
a
little
app
that
we
write
to
enable
stress,
testing
those
systems
in
a
style
that
looks
like
open
match
and
then
provide
those
numbers
back
to
this
forum.
C
C
Infinitely
it
actually
has
some
problems
yeah,
so.
B
We
did,
we
did
do
reading
from
slaves
for
query
and
as
an
experiment.
Youth
ended
that
and
we're
comparing
several
different
options
and
that.
B
That
didn't
actually
really
improve
the
numbers
at
all:
yeah
weirdly
enough,
so
yeah
we
we
didn't.
We
didn't
call
that
a
success.
It
was
good.
It
was
good
to
try,
though,
but
what
we
did
currently
is
that
curry
will
I
figured
I'd?
Describe
it
when
query
gets
a
request
it.
It
asks
redis
what
are
all
the
tickets
and
then
it
does
an
update
of
any
tickets.
That's
missing
and
throws
any
way
that
it
has,
but
aren't
there
anymore,
so
it
that
has
this
caching
layer
and
then
it
runs.
B
The
like
actual
query
range
filtering
whatever
in
memory
in
parallel,
and
we
got
way
better
scale
with
that.
So
I
think
I'd
be
interested.
I
did
a
little
bit
of
research
around.
Are
there
any
things
like
redis
that
does
the
querying
patterns
that
we
really
want
to?
Do?
B
I
didn't
have
any
luck
that
doesn't
mean
that
there
aren't
any.
I
don't
think
I
looked
into
aerospace
so
whatever
that
is,
maybe
maybe
that
does
it,
but
for
my
cursor
researching,
I
didn't
really
find
anything,
and
I
focused,
like
all
of
our
problems
were
with
corey
at
that
point
so
or
korean,
and
it
was
like,
obviously,
obviously
the
huge
bottleneck
that
we
were
fighting.
So
in
that
respect,
that's
what
we
focused
on.
I
I
wouldn't
be
surprised
if
or
like.
B
If
I
had
to
guess
about
like
what
would
be
a
good
way
to
process
is
what
can
what
would
be
a
better
system
for
watching
assignments
and,
like
you
know,
maybe
we're
starting
the
player
pulls
and
that
just
works.
But
then
query
looks
across
those
player
polls
or
we
also
shared
query
and
put
like
a
yeah.
You
know
something
in
front
of
corey,
which
is
what
we
call
we
would
call
corey,
I
guess,
and
then
we'd
split
it
send
it
out
to
corey
shards
or
something
like
that.
B
Maybe
that
would
be
the
good
way
to
go.
I
don't
I
haven't
looked
into
it
too
much,
but
yeah
focus
on
like
trying
to
figure
out
what's
causing
righteous
problems
and
focus
on
that
is
maybe
a
useful
attack.
But
I
I
think
the
other
question
is:
what
is
the
level
scale
you
want
and
what
we
focused
on
was
one
very
large
game
and
you're
trying
to
get
to
that.
B
C
Yeah,
those
are
great
points,
scott.
I
think
we're
hoping
to
bring
back
some
feedback
on
both
both
fronts,
not
just
large
game
but
mini
game
as
well,
and
still
still
looking
for
other
community
members
that
might
be
trying
to
achieve
that
same
mini
game
results
multi-tenancy,
I
know
of
at
least
one
other
that
was
looking
into
it,
but
you
know
feel
free
to
ping
ping,
the
dev
channel
and
just
express
like
yeah.
C
I
actually
want
to
do
like
10
games
as
well
on
a
single
instance
instead
of
hosting
10
versions
of
open
match,
but
so
still
still
vetting
that
assumption
on.
On
my
part,
the
I
guess
I
have
I
have
one
more
sort
of
like.
C
C
I
imagine
we
could
add
that
type
of
concept
to
our
variety
show
here,
but
there
there
is
a
limit
to
what
you
can
do
with
a
match
function,
that
is
in
squared
processing,
a
pool
of
tickets,
and
it's
based
on
the
number
of
tickets.
You
have.
C
So
what
a
behavior
that
you
might
come
across
when
you're
doing
open
match
processing
is
that,
if
you're
unable
to
egress
your
players
out
of
matchmaking
the
player,
pull
increases,
and
then
that
prevents
you
from
being
able
to
make
matches
in
a
timely
way
which
then
snowballs
your
your
player
pool.
And
then
you
can't
egress
the
pressure,
and
so
you
end
up
just
in
a
hard
locked
state
of
every
player
sitting
in
a
match
making
unable
to
leave.
C
We
we've
added
at
at
our
front
door
that
I
think
I
just
realized
this
ski
home.
We
should
probably
think
about
figuring
out
how
to
get
this
back
in
is
a
pool
limiter,
so
a
way
to
cue
players
coming
into
matchmaking
having
it
look
like
they've
entered
matchmaking
but
they're
effectively
waiting
for
the
pool
of
actual
tickets
trying
to
match
make
to
to
reduce
in
size.
It
might
not
just
be
like
that
you're
unable
to
make
matches
fast
enough.
It
might
also
be
that
you're
downstream.
C
G
I
was
gonna,
say
good
question
on
that,
so
like
doesn't
that
potentially
introduce
the
alternative
problem
that
the
people
with
whom
I
would
match
are
now
are
now
sharded
outside
the
gate
right.
So
you
know,
I
have
a
different
style
of
can't
get
the
people
out
fast
enough,
but
if
you're
full,
that's
that
you
can
make
a
match
is
probably
pretty.
C
High
right
there's
a
this
is
the
theoretical
limit
of
what
you
know.
Real-Time
matchmaking
looks
like
in
terms
of
parallel
compute
processing
that
an
n1
standard
for
can
do
given
the
query
time
and
if
your
matchmaking
needs
you
know,
100
000,
simultaneous
observations
on
that
many
tickets,
then
then
yeah,
like
maybe
100
000,
makes
sense
and
your
match
function
needs
to
be
fast
or
maybe
your
matchmaking
loop
needs
to
be
really
slow
and
therefore
you
need
to
use
the
open
match
configurations
to
make
it.
You
know
60,
you
know.
C
60
seconds
is
crazy,
but,
like
60
seconds
worth
of
match
function,
processing
time
to
consume
your
pool
from
a
from
a
real-time.
You
know
second
style
matchmaking
perspective.
You
know
you
can
only
make
so
many
observations
and
parallel
comparisons
between
tickets,
so
having
a
pool
limiter
as
a
configurable
option
in
matchmake
in
open
match
might
be,
might
be
an
interesting
tool
to
utilize
to
prevent
things
from
we've
experienced
snowball
on
our
side
and
it's
it's
pretty
hard
to
you
end
up
like
flushing
the
database
in
real
time,
trying
to
like.
F
C
Some
matches
out
but
yeah
what
happens
is
egress
stops
going
and
suddenly
you
end
up
with
your
entire.
You
know
over
the
course
of
an
average
game
length,
everyone
comes
back
through
matchmaking
and
so
they're
all
sitting
there,
not
two
hundred
thousand,
but
a
million
players
waiting
to
go
through
matchmaking.
G
Is
it
possible
to
add
a?
Is
it
useful
or
maybe
helpful,
to
add
a
director
back
off?
You
know
like
okay,
my
match
function
is
taken,
it's
just
really
going
exponential,
but
if
I
let
it
finish
once
like
half
these
people
will
go
away.
So
just
don't
is
that
that's
not
the
problem,
though,
is
it
right?
The.
B
Director,
I
think
the
idea
here,
generally
speaking,
is
that
adding
more
players
will
make
things
slower.
So
I
want
to
keep.
I
want
to
limit
the
pool
to
keep
things
fast
and
I'm
by
keep
limiting
the
pool,
I'm
going
to
move
faster
and
work
through
the
tickets
faster,
and
I
already
have
like
a
lot
of
players.
B
So
I'm
going
to
be
able
to
make
good
matches
right
so,
like
the
the
quality,
isn't
going
to
suffer
that
much
other
than
wait
time
right.
But
I
just
need
to
like
keep
it's
kind
of
a
failure
scenario
where
you
hit
some
n
squared
in
your
match
function
or
you
like
you
hit
something
that
like
starts
really
slowing
down.
G
Well,
there's
a
tale
where,
beyond
you
know,
10
000
players
like
the
quality
of
match
and
the
speed
of
match
like
doesn't
improve.
So
can
you
know
you
may
have
a
million
tickets,
but
if
you
just
say
give
me
the
first
10
000,
I
will
keep
my
match
function.
Super
tight
on
those
I
will
get
good
matches
and
those
people
right
is
that
a
way
we
could
do
it,
I'm
just
throwing
ideas
by
the
way.
These
are
totally.
G
G
C
B
Oh,
as
you
say,
I
think,
limiting
it
at
the
front.
End
ensures
that
we
don't
hit
like.
If
your
bottleneck
is
the
redis,
you
know
creating
tickets
or
whatever
you
know.
Let
me
know
at
the
front
end
will
prevent
more
areas
where
bottlenecks
could
develop
in
your
system,
so
it
seems
more
natural
to
prevent
it
there.
B
We
did
look
into
limiting
queries
a
little
bit
at
one
point,
but
we
never
had
a
strong
reason
to
do
that.
Like
a
limit,
like
you
know,
query
from
call
query
but
limit
a
thousand
tickets
or
something
so
we
didn't
end
up
doing
any
of
that,
although
people
are
welcome
to
you,
know,
suggested
or
submitted
as
an
option.
C
I
kind
of
imagine
three
three
touch
points
here
that
really
anyone
could
pursue.
The
first
is
to
cue
them
at
the
front
door,
either
through
a
you
know,
exponential
back
off
header
or
an
actual
like
queue.
That's
like
you're,
not
indexed
until
we
can't
index
you
so
therefore
you're
in
matchmaking,
but
nothing
can
see
you
so
there's
a
front
door
way.
I
think
to
aaron's
point:
there's
a
match
function.
C
Protection
way,
which
is
the
query
layer
won't
give
you
more
than
you
can
handle,
but
the
query
layer
now
has
to
do
more
from
an
indexing
perspective,
because
we
have
this
large
index
now
that
we
need
to
to
page
through.
So
maybe
that's
an
interesting
consideration
to
add
to
our
database
exploration,
to
see
if
there's
any
technologies
that
just
give
it
to
us
because
of
om
query
is
basically
like
a
hand
built
indexing
system
built
on
top
of
a
cache.
There
are
things
we
can
do
directly
into
that.
C
That
might
help
partitioning
gets
really
hard
with
with
the
ohm
query
setup
that
we
currently
have
so
we'll
want
to
talk
about
that.
As
a
part
of
the
partitioning
conversation,
I
think
to
your
point,
there's
also
a
what
what
I
can
sometimes
think
of
as
like
a
real
time
tuning
where
the
director
actually
kind
of
needs
to
be
smart
and
it
needs
to
have
the
ability
to
make
a
trade-off
between
hey,
like
there
is
a
world
where
there's
a.
I
need
to
break
the
dam
and
like
let
one
process
for
a
minute.
C
In
the
meantime,
I
still
have
tickets
coming
through,
but
maybe
I'm
actually
fully
saturated
and
everyone's
waiting
on
a
match.
So
let's
just
go
ahead
and
do
a
long
form
matchmaking
round
and
then
speed
it
up
and
getting
control
over.
That
synchronizer
window
is
an
interesting
strategy
for
basically
like
having
your
foot
on
the
gas
pedal
and,
having
a
your
hand
on
the
choke
and
like
kind
of
adjusting
the
engine
to
get
it
working
again.
C
Yeah
definitely
I
I
want
to
think
more
on
the
on
the
technical
side
for,
for
which
one
gives
us
different
bangs
for
your
buck.
We
did
went
with
the
pull
limiter
just
to
enable
like
to
get
a
consistent
behavior
that
we
could
know
that
hey
30,
000
tickets
in
the
pool
we
know
for
this
custom
match
function
is
under
three
seconds,
and
so
we
are
basically
able
to
like
never
have
a
snowballing
problem.
C
Reacting
to
a
snowballing
problem
is
an
interesting.
Is
another
thing
we
could.
We
could
talk
about.
G
Yeah,
these
don't
necessarily
need
to
be
mutually
exclusive
at
all.
Like
multi-layered
responses
is
a
good
idea.
Like
you,
you
start
by
paging
your
queries,
then
you
go
okay,
look
you
guys
just
stand
outside.
That's
like
level
two.
You
know
it's!
It's
it's
reasonable
to
have
many
tools
to
address
this
yeah.
C
Well,
we'll
look
into
making
an
issue
for
the
preliminar
one
just
because
we
already
have
it
sort
of
designed,
and
I
think
the
synchronizer
already
being
a
loop
allows
us
to
update
like
how
big
the
pool
is
and
allow
the
front
doors
to
reject
calls
or
cue
calls.
Sorry
go
ahead.
G
Yeah,
you
mentioned
that
ratio
of
like
tickets
to
like
performance
time
right
like
are
there
any
guidelines
or
numbers
right?
I
mean
it's
so
everything's
a
custom
match
function.
So
it's
really
hard
to
to
tell
somebody
like.
G
B
There's
the
numbers
we've
published
they're
on
the
point,
10
releases
the
last
time
we
did
the
full
run
of
the
profiling
because
there
wasn't
any
profile
like
performance
improvements
in
1.0.
Yes,
dog,
the
for
people
watching
the
recording
april's
holding
a
dog.
You
can't
see
that
it's
very
cute
the
what
was
I
saying.
Oh
sorry,
it's
april's
fault.
B
Yes,
in
terms
of
guidelines
yeah,
it's
like
we
have
so
we
have
those
numbers,
those
those
are
where
you
can
start.
Unfortunately,
I
I
really
do
think
it
is.
You
have
to
write
your
scenario
and
actually
try
it
thing
right.
G
G
Made
it
yeah,
I
was
just
gonna,
say
I'll
ping
you
offline
for
the
pro.
I
can't
find
him
immediately
on
openmatchdev
or
github,
but
you
can
pick
me
up
it's
on.
B
The
it's
on
the
release
like
if
you
look
at
releases,
it's
just
like
a
paragraph
on
the
point:
10
release
0.10
so.
C
We've
you
know,
we've
been
in
an
interesting
position
where
we've
seen
a
lot
of
custom
functions.
We've
been
in
co-development,
with
a
lot
of
people
who
are
authoring.
Custom
functions
it'd
be
interesting
to
try
and
get
some
of
that
feedback
through.
It's
very
varied.
We
see
in
log
in
we
see
expensive
off
box
call
operations,
we've
seen
exponential
time,
those
those
ones
in
particular.
I
think
it
really
hits
home
how
important
its
algorithms
are,
because
you
can
only
have
like
10
000
ccu.
C
If
your
matchmaker
can
only
do
you
know,
2
000
tickets,
a
minute
before
it
enters
into
like
a
degraded
mode
and
and
then
it
starts
to
kind
of
snowball
or
you
have
to
prevent
the
snowball.
We've
also
seen,
I
think,
to
scott's
point
when
it's
really
simple
logic
or
like
linear
time
that
it's
you
know,
500
half
a
million
tickets
per
minute
and
that
could
technically
support.
C
You
know
three
or
four
or
five
million
ccu
without
really
much
modification,
so
understanding
how
to
benchmark.
That
is
definitely
something
I
could
imagine
the
community
benefiting
from
in
the
the
ecosystem
repository
if
we
had
a
some
like
a
benchmarking
example
for
how
to
convert
like
a
unit
test
on
a
function
with
so
many
tickets
should
result
in
x,
scale
and
open
match.
B
Cool,
so
we
have
two
minutes
left
I
see.
I
know
someone
left
the
comment
saying
open
match.
Docs
pools
are
stale.
I
should
get
on
that.
I'm
also
working
on
the
all
the
new
pull
requests.
We've
got
recently
on
main
repo.
C
Yeah
scott,
I
just
want
to
recognize
something
you
submitted
recently,
the
the
how
to
contribute.
Yeah
youtube,
video
very,
very
helpful,
awesome
contribution,
and
I
know
that
that's
going
to
be
really
great
for
a
lot
of
people
trying
to
get
introduced
to
like
how
to
actually
think
about
open
match.
We
know
it's
a
framework.
We
know
that
there's
work
to
do
there,
that
you
might
need
to
spend
some
time
rolling
your
sleeves
and
getting
involved
and
that's
going
to
be
a
really
big
help.
So
thank
you.
B
C
Here
we
have
a
11
advisor
room
seriously:
the
advisors,
meeting,
cool,
okay,
I
think
we're
at
time
scott.
Thank
you.
Yep.