►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Designing a gRPC Interface for Kernel Tracing with eBPF - Leonardo Di Donato, Sysdig
As a maintainer of the CNCF runtime security project, Falco, he was tasked with designing a mutually TLS authenticated API over gRPC in C/C++ to solve the runtime security problem. Join this talk to understand the challenges he faced with designing the interface, as well as the performance concerns with parsing millions of syscalls using eBPF over gRPC. The audience will walk away with an understanding of runtime security in cloud-native, as well as the technical concerns with building such an interface.
https://sched.co/Zexb
A
A
Falco
was
created
as
an
open
source
project
from
day
one
by
assisting
in
2016
to
pass
libsyn's
p
events
to
match
security
policies
against
them
at
runtime.
About
years
later,
it
was
donated
to
the
cncf.
This
past
january
falca's
been
the
first
ever
and
time
security
project
to
be
promoted
to
the
cncf
incubation
level
anyways.
My
name
is
leonardo
di
donato.
I'm
an
open
source
software
engineer
at
sysdig,
where
my
daily
job
is
to
code
falco,
evaluate
and
maintain
it
as
a
material
farco.
A
I
also
have
to
advocate
and
present
its
technology
and
all
the
artwork.
We
do
to
continuously
improve
it.
So
here
I
am
here,
there's
a
photo
of
me
moving
as
like
a
real
italian
in
san
diego
falconswag
to
the
first
one,
guessing
the
exact
meaning.
You
can
usually
find
me
on
twitter,
github
and
generally,
the
webverse,
with
the
nickname,
leodido
feel
free
to
drop
me
a
line.
A
Finally,
we
will
see
how
falco
collects
these
events
from
the
kernel
as
rules
against
them,
and
now
it
eventually
outputs
outlets
via
grpc,
to
make
them
more
usable
in
a
cognitive
context,
since
we
are
going
to
deep
dive
into
all
of
these
by
the
end
of
this
talk,
you'll
have
a
deep
technical
knowledge
of
some
very
crucial
parts
of
falco,
and
hopefully
you
will
be
also
able
to
start
contributing
to
it.
What
does
security
mean,
at
least
to
me?
A
A
What
these
two
concepts
have
in
common
policies,
both
use
some
kind
of
policies
to
describe
the
allowed
or
disallowed
mirror
for
a
process
in
terms
of
system,
calls
their
arguments
and
asked
resources
assessed.
The
differences
are
that
the
first
concept
prevention
is
about
enforcement.
Do
not
allow
some
actions
for
some
person
to
happen
at
all
because
of
some
policies.
On
the
other
side.
The
second
handle
of
security
is
to
use
the
policies
to
monitor
the
behavior
of
a
process
and
notify
when
it
steps
outside
those
policies
at
runtime.
A
A
Software
is
made
of
layers
and
soy
security.
This
is
even
more
true
in
cloud
native
environments.
Nowadays,
as
you
can
see
in
the
scheme
I
drew
into
the
slide.
Falco
is
here
to
fit
into
this
picture
together
with
the
other
tools.
You'll
have
to
combine
it
with
other
layers
in
many
way,
using
a
defense
in
that
strategy,
the
idea
is
to
defend
a
system
against
any
particular
attack
using
several
independent
methods.
A
I
mean
cv,
still
happens:
linux
kubernetes
name,
an
open
source
software
that
does
not
experience
the
cv
and
suffered
an
explorer.
I
think
it's
clear
now
that
enforcement
tools
alone
are
not
enough.
We
also
need
runtime
security
solutions
and
these
two
approaches
are
and
must
be
complementary
and
not
mutually
exclusive.
A
So
what's
runtime
security
in
the
context,
I've
just
described
runtime
security
is
often
the
last
line
of
defense.
Let's
try
with
a
metaphor,
she's
scaly.
Look
how
beautiful
she
was.
I
have
locks
on
my
door
and
dolls
on
alarm,
think
of
them
as
compliance
rules,
but
she
hollers
me
when
things
are
not
going
right.
Policy
violations
when
little
bro
is
misbehaving.
Think
of
him
like
a
compromised
insider
or
if
there's
something
suspicious
happening
outside
or
nearby
anomaly
or
zero
day.
A
A
The
faulty
unique
way
to
do
this
is
by
tracing
and
detecting
everything
happening
inside
the
box
from
the
bottom.
The
kernel
up,
instead
of
using
the
usual
top-down
approach,
like
other
security
monitoring
engines,
do
how
that's
possible
tracing
cisco's
at
their
source
and
asserting
rules
against
events
containing
the
syscalls
plus
other
context
info
like
arguments,
kubernetes
metadata
containing
metadata
and
so
on.
Somebody
could
argue
why
tracing
the
c
schools.
A
Well,
nowadays,
the
production
environments
are
filled
with
so
many
pods
services
containers
monitoring
tools.
Generally
software,
I
tried
to
do
a
nice
layered
diagram
to
slide
before
and
well.
It
turns
out
that
complexity
is
the
exact
reason
we
go
look
under
the
in
the
end.
Whatever
program
we
run,
it
will
end
up
making
a
lot
of
syscalls
this
because
system
calls
are
the
way
programs
ask
the
kernel
where
everything
happens,
to
perform
some
tasks,
whether
the
task
regards
networking
io
processes.
A
A
We
need
to
combine
these
events
with
metadata
from
other
layers
of
interest
like
kubernetes
audit,
logs
container
metadata
and
so
on.
For
example,
we
need
to
have
the
cisco
arguments
in
a
readable
way.
We
need
to
know
when
events
are
happening
asynchronously.
We
also
need
to
know
if
a
cisco
was
originated
in
a
container.
A
What
was
the
idea
of
the
container
and
from
what
image
the
container
was
created?
Also,
we
would
like
to
know
the
cluster
nodes
where
all
of
these
happened,
how
to
get
cisco
to
user
space
and
use
them
as
one
of
the
inputs
for
runtime
security.
Falcos
solves
this
with
three
alternative
approaches
that
we
can
call
falco
drivers,
a
kernel,
module
a
pitrass-based
producer.
We
call
pdig,
which
is
slower
than
other
methods
and
very
yucky,
but
it's
the
only
possible
solution.
A
In
some
environments,
like
managed
kubernetes
clusters
fargate
and
places
where
you
cannot
install
camera
module
either
in
bpf
probes
and
finally,
an
mbpf
probe
forget
the
first
few
drivers
I
mentioned
in
this
talk.
We
are
gonna
focus
only
on
the
latter
before
a
while,
using
something
it's
good
practice
trying
to
understand
what
it
is
right.
A
A
So
ebpf
is
very
flexible
and
capable
of
tracing
almost
any
aspect
of
all
major
linux
subsystem,
ranging
from
cpu
scheduler
memory
manager,
networking
system
calls
and
so
on.
With
abpf
one
can
attach
custom
sandbox
bytecode
to
virtually
every
function
exported
by
a
kernel,
simple
table
without
the
fear
of
breaking
the
kernel.
Ebpf
emphasizes
the
importance
of
safety
when
crossing
user
space
boundaries,
the
internal
verifier
will
refuse
to
load
any
bpf
program.
A
If
invalid
point,
the
references
are
detected
or
the
maximum
stack
size
limit
is
reached,
loops
are
not
generally
allowed
and
only
a
small
subset
of
specific
bpf
helper
functions
is
permitted
to
be
called
within
generated
by
the
code.
Thus,
a
bpf
programs
are
guaranteed
to
terminate
at
some
point
in
time
and
never
exhaust
system
resources.
Furthermore,
the
performance
already
induced
by
bpf
is
soft
negligible,
making
it
a
great
fit
for
monitoring
and
tracing
evenly
loaded
systems.
For
all
these
reasons,
ebpf
superpowers
are
perfect
for
our
need
to
trace
all
the
syscalls.
A
I
know
when
we
are
most
ready
to
look
at
our
bpf
driver
implementation,
no
worries,
let's
first
give
a
glance
at
how
abpf
architecture
works
in
general.
Let's
pretend
we
have
an
bpf
source
file
ready.
The
first
step
is
to
compile
it
to
a
bpf
byte
code
once
it
is
successfully
compiled
and
the
object
file
is
generated.
We
are
ready
to
inject
it
into
the
kernel,
attaching
it
to
a
given
hook
or
making
it
run.
On
a
specific
event,
for
this
purpose,
we
used
bpf
system
code.
A
This
seemingly
simple
cisco
does
a
lot
more
apart
from
loading
a
bpf
byte
code.
It
attaches
the
particle
to
the
event
and
it
also
creates
and
manipulates
in
kernel
maps.
Then
the
verifier
statically
analyzes
the
program
before
loading
it
to
ensure
that
it
cannot
harm
the
running
system,
as
we
briefly
explained
before,
and
it's
important
to
observe
how
there
are
plenty
of
events
to
which
we
can
look
up
various
bpf
program
types.
We
have
events
for
monitoring
and
tracing
purposes,
others
for
security,
others
for
assess,
control
and
clear
for
networking
too.
A
Finally,
a
bpf
also
provides
the
ability
and
to
assess
shared
data
structure
such
as
ebpf
maps.
Well,
the
ebpf
maps
are
likely
the
most
compelling
feature
of
abpf
without
any
dubbed
without
maps
and
falco
driver
will
not
have
been
possible
at
all
maps
come
to
the
rescue
for
sharing
state
between
user
and
kernel
space.
They
represent
a
very
efficient
in
kernel,
key
values,
tool
for
data
aggregation
and
can
be
assessed
asynchronously
from
user
speech.
There
are
many
types
of
bpf
maps,
as
you
can
see.
A
Looking
at
the
slide
maps
that
store
delta
per
cpu
usual
hash
maps,
arrays
maps
to
store
other
programs
to
tell
cool
later
that
we
use
a
lot
in
our
driver
and
so
on.
Ebpf
does
not
allow
you
by
design
to
move
memory
from
kernel
space
to
user
space
and
for
reasons
its
purpose
to
be
safe.
Will
there
been
a
completely
filed
soap
in
that
case,
but
luckily,
as
said,
ebpf
has
maps,
as
you
can
see
in
the
diagram
here,
the
bpf
maps
are
a
vital
part
of
the
falc
architecture
when
using
the
bpf
probe.
A
Here
we
have
a
library
called
libscap
that
loads.
The
alph
of
the
bpf
driver
into
the
kernel
bpf
virtual
machine,
which
executes
it
under
the
odds
libscop
also
sends
literally
bpf
programs
to
be
executed
at
runtime.
The
goal
of
these
little
bpf
programs
that
we
call
fillers
is
to
augment
the
traced
c
schools
so
that,
in
an
input
event
we'll
have
the
actual
value
c
score
parameter
head,
not
some
random,
x
values.
A
A
The
first
step
would
be
to
build
the
existing
one
from
source
right,
so
create
a
build
directory,
go
into
it,
configure
cmake
to
create
make
files
to
compile
the
bpf
probe
2,
as
shown
in
the
slide
once
this
configuration
step
is
done,
execute
make
bpf
to
build
it.
If
everything
went
well,
you
will
end
up
having
a
0.2
object
file
to
falcon
bpf
probe
into
the
build
slash
drivers,
bpf
directory,
pretty
simple.
As
long
you
already
have
clang
installed
the
either
for
your
specific
current
release
installed
and
the
bug
file
system
mounted.
A
Well,
the
next
natural
step
is
to
load
the
bpf
probe.
We
just
build
and
use
it
as
the
falco
inputs
driver
long
story
short,
you
can
execute
falco
putting
before
its
binary
the
falco
bpf
probe
environment
variable
it
can
be
either
empty,
in
which
case
falco
expects
the
bpf
object
file
to
be
into
the
dot
file
called
slash,
falco
dash
bpf.2
file
into
your
room
directory
or
directly
pointing
to
the
path
where
you
put
the
compiled
bpf
object
file,
let's
now
dive
into
some
details.
A
A
It
passes
this
inspector
instance
to
the
falco
engine,
which
in
turn
also
passes
the
rules
that
we
started,
falco
weed
and
to
the
falco
outputs,
which
is
the
piece
of
falco
responsible
for
initializing
the
output
methods
and
handle
the
events
when
they
will
flow
in
from
this
pack.
At
this
point,
falco
is
ready
to
instruct
the
inspector
to
start
live
capturing
syscalls
their
arguments.
The
context
within
the
happening
container
metadata
generate
what
we
call
input
themes.
A
A
This
only
slide
will
need
a
wall
torque
dedicated
to
it.
But
let
me
try
briefly
summarize
it
to
perform
the
loading
it
first
tries
to
locate
the
bpf
object
file
depending
on
the
environment.
Variable
we
passed
the
falco
before
then
it
collects
some
machining
for
like
number
of
online
cores
enables
a
bpf
just
in
time,
compilation
for
better
performances
and
starts
passing
the
alpha
of
the
opacity
in
abpf
object
5.,
while
passing
it
lipscope
first
checks.
A
If
the
bpf
pro
version
has
been
compiled
for
the
current
current
release
and
if
the
ebpf
version
matches
the
one
that
the
current
falcon
version
requires,
then
it
looks
for
ebpf
map
sections
into
the
elf
to
define
and
create
them.
Accordingly,
dbpf
probe
uses
various
maps
to
define
and
share
its
setting
its
state
and
its
behavior.
A
It
does
a
map
to
represent
cisco
through
system
independent
codes,
look
for
c
school
code
routing
table
a
map
to
represent
whether
a
specific
c
school
should
be
traded
or
ignored.
Look
for
c
school
table
another
map
to
describe
the
events
in
terms
of
the
cisco
they
are
created
from
its
argument
and
their
tabs
look
for
event
info
tables,
a
map
to
link
every
cisco
to
the
entry
and
exit
fillers
to
execute.
A
When
it
occurs,
filler
stable,
then
it
has
also
maps
to
store
measurements
about
all
processes
and
threads
per
cpu
lipscope
loads.
All
of
these
from
the
elf
and
populates
them,
then
it
looks
for
elf
sections,
starting
with
trace
point
or
raw
trace
point
prefix
and
loads
them
too.
To
do
so,
it
uses
bpfc
school
using
bpf,
prog
type,
trace
point
or
bpf
prototype
raw
trace
point
once
loaded.
It
attaches
them
either
by
opening
the
transparent
file
into
the
backfile
system
and
using
ioctl
command
with
perth
event.
A
It
grabs
the
corresponding
bpf
program
from
the
fillers
table
and
setups
it
to
be
executed
when
the
related
c
school
get
traced
by
populating
the
corresponding
ebpf
map
of
type
bpf
map
type
prog
array,
these
little
bpf
programs
are
responsible
for
reading
the
c
school
arguments
at
the
entry
or
the
exit
of
the
corresponding
c
school
and
make
them
useful
for
libsyns
alongside
libscap,
also
retrieved
the
process
and
user
lists,
and
now
it
is
ready
to
scan
the
profile
system
to
gather
thread.
Ids
read:
sockets
retrieve
various
other
process
information.
A
A
A
If
a
match
with
a
rule
is
found,
the
event
gets
immediately
passed
to
the
falco
outputs
which
will
handle
it
by
calling
the
andal
jrpc
function.
In
this
case,
this
function
reshape
the
information
contained
in
the
event
to
create
an
output,
alert
and
push.
This
final
object
to
a
queue
from
which
the
actual
rpc
implementation
will
pop.
A
A
Then
it
was
open
sourced
under
the
cncf
umbrella
and
evolved
a
lot
since
then
for
sure
it's
one
of
the
more
high
performance
standards
based
general
purpose
and
feature
reach
rpc
frameworks
out
there.
It's
built
on
top
of
http
2,
which
is
a
binary
protocol
that
implements
the
same
semantics
of
http
protocol,
making
more
efficient
use
of
network
resources.
A
It
also
provides
some
nice
capabilities,
like
stream
multiplexing
within
a
single
connection,
flow
control
and
leader
compression.
Usually
your
apc
implementation
use
some
generated
code
obtained
from
serialization
formats
that
define
the
services
you
want
to
implement
in
terms
of
rpc
calls
their
type
and
their
messages
very
often,
but
not
always,
this
format
is
protobuf.
A
Such
generated
code
looks
into
the
core
apis
directly,
which
is
the
api
implementing
the
main
features
of
the
jrpc
on
top
of
a
lower
level
api
like
system
calls
and
transport
protocols,
depending
on
the
programming
languages
we
use.
Jrpc
has
like
different
stacks
since
falco
is
mainly
written
in
c
plus,
plus
we
are
going
to
look
only
at
the
jpc
stack
as
depicted
on
the
right
part
of
this
slide
at
the
bottom.
We
do
have
tcps
transport
going
up.
A
We
have
ch2,
which
is
a
custom
http
2
basin,
transport
implementation
that
uses
0pc
data
structures
and
it's
easily
optimized
for
it,
but
you
can
also
bring
your
room
such
as
chronet,
the
chrome,
networking
library
above
we
have
the
jpc
core,
where
the
main
functionalities
are
implemented.
As
said
and
where
a
thin
c
api
is
this
thin
c
api
is
meant
to
support
rapid
languages.
Implementations
like
the
c
plus
plus
one
to
go
synchronous
or
to
go
asynchronous.
That's
the
question.
The
jrpc
programming
api
comes
in
both
synchronous
and
asynchronous
flavors.
A
A
So,
in
the
synchronous
model,
the
implementer
only
has
to
care
about
handling
the
actual
rpc
called
implementation,
making
it
an
easier
model
to
work
with.
But
if
you
want
finer
control
over
the
trading
aspect
of
the
rpcs,
then
the
aciculus
api
is
the
better
model,
even
though
it's
considerably
more
difficult
to
work
with
honestly.
A
In
this
model,
the
application
tells
the
grpc
core
that
it
wants
to
handle
an
rfpc
and
provide
it
a
tag
that
acts
as
a
key
for
the
completion
of
events.
Then
it
blocks
on
a
completion
queue
waiting
for
a
completion
key
to
become
available
once
the
key
is
available.
The
application
code
executes
the
associated
pc.
A
This
model
provides
the
best
performances
to
who
is
willing
to
go
the
extra
mile.
The
cost
to
pay
is
that
such
api
needs
considerably
glucose
to
be
written,
and
we
will
see
in
a
bit
and
a
good
amount
of
patience
to
deal
with
implicit
behaviors.
That
dogs
do
not
cool
out
very
well
honestly,
but
in
the
end
it
allows
us
to
bring
our
trading
model
and
to
overcome
scaling
limitations.
A
Since
no
one
knows
when
some
falco
rules
violation
happens,
I
needed
a
way
to
let
people
start
a
lpc
and
then
it
just
sit
there
waiting
for
some
violation
to
happen
so
to
notify
the
clients
watching.
I
want
people
able
to
say,
hey
falco.
I
am
interested
in
violations
about
this
topic
and
falco
will
tell
them
the
violations
regarding
the
topic.
If
any
and
then,
if
other
violations
occur,
it
will
go
ahead
immediately,
send
them
to
the
people
still
watching
this
way,
clients
would
need
to
wait
and
start
new
rpc
calls
randomly.
A
This
is
what
it's
usually
called
long-lived
streaming.
Api
long-lead
rpcr
calls
lasting
minutes
hours
or
even
days
in
some
cases,
as
you
can
see
in
slide,
I
use
this
jrpc
bi-directional
api
to
define
and
then
implement
it.
Anyways
long
leave
the
rpc
do
not
come
for
free.
There
are
a
lot
of
complexity
involved,
buffing
the
implementation
of
such
apis
and
into
their
own
nature.
For
example,
the
jrpc
flow
control
may
have
large
buffer
retry
strategies
at
the
framework
level.
A
Stop
aiming
much
sense
in
this
case,
which
means
we
need
to
implement
our
own
at
the
application
level.
Furthermore,
we
also
know
that
this
type
of
service
fails
when
there
are
tcp
disconnects
and
also
it
takes
time
to
detect
such
network
failures.
We
also
know
it
creates
issues
with
load
balancers.
The
alternative
is
that
a
falco
client
does
a
repc
call
and
asks
if
violations
already
happen
to
the
falco
jrpg
server.
A
A
This
way
we
can
eventually
start
more
rpc
calls
without
blocking
its
current
thread.
Honestly,
as
you
can
imagine,
this
process
was
not
easy
at
all
and
it's
far
to
be
yet
completed,
but,
after
writing
ebpf
code,
nothing
can
scare
us
right.
Improving
the
performances
and
the
behavioral
falco
jrpg
server
was
essential.
A
A
If
you
are
interested
in
learning
more,
I
can
say
that
in
general,
what
matters
when
implementing
such
jrpc
apis
in
c
plus
plus,
is
to
use
the
synchronous
api
tune,
the
trading
model,
while
also
reducing
the
contention
using
tools
like
valgrind
or
mutrus,
by
making
different
hypotheses
and
measuring
the
outcomes.
For
example,
I
found
that
having
a
number
of
threads
equal
to
the
number
of
online
cpus
works
pretty
well
for
falco.
A
A
As
said,
I
consider
the
current
falco's
europc
apis
far
to
be
dfinity
for
sure
there
are
still
a
lot
of
areas
where
performances
can
improve,
but
also
from
an
architectural
point
of
view,
there
are
still
existential
questions
to
be
asked
for,
for
example,
does
it
make
any
sense
to
design
the
output
cpi
as
a
unity
call
rather
than
a
long
live
bi-directional
stream?
One?
A
This
alternative
api
will
return
a
response
containing
the
current
list
of
folk
rule
violations
which
use
case
not
already
covered
up
with
itself.
Will
it
be
more
efficient
for
sure
it
will
be
simpler
to
write
and
maintain,
but
out
to
the
side,
we
need
to
wait
whether
the
added
complexity
for
streaming
long,
lead,
rpcs,
provides
a
large
enough
benefit
or
not
any
which
scenarios
sending
a
message
on
a
stream
is
indeed
faster
than
a
new
unity
air
pc
every
time,
but
the
improvement
is
fixed
and
has
a
higher
complexity.
A
So
this
is
not
a
done
deal
yet.
As
said
in
the
previous
slide,
the
only
real
way
to
find
answers
is
to
write
a
code
and
measure
it.
So
I
invite
anyone
willing
to
take
this
task
to
join
our
community
code
and
discuss
this
with
us.
Let's
now
jump
into
some
diagrams
to
describe
the
current
falco
jrpc
flow
in
more
detail.
A
We
are
at
the
point
that
falco
can
now
read
the
configuration
file
and
initialize
the
jpc
server
by
providing
it
config
values
like
the
server
paths
and
the
address
to
bind
it
also
automatically
guesses.
The
number
of
online
cores
and
uses
this
number
as
its
treadiness
value.
At
this
point,
falco
is
ready
to
spawn
a
new
thread
responsible
for
running
the
entire
jrpg
server,
which
main
operation
is
to
set
up
its
own
trading
model,
as
said.
Finally,
the
server
also
ensures
to
stay
awake
until
it's
running
or
to
stop
itself.
A
Otherwise,
when
the
grpc
server
is
sold
to
start.
The
first
thing
it
does
is
to
register
the
asynchronous
services
automatically
generated
from
the
protobuf
definitions
and
get
told
of
the
completion
cues.
Once
this
is
done,
we
can
ask
the
jrpc
call
to
build
and
start
the
jpg
server
soon
after
the
falco
jrpc
server
spawns
one
thread
dedicated
to
surveying
and
processing
the
requests
for
every
online
cpu,
and,
while
doing
so,
it
also
locates
10
different
contexts
of
three
different
types,
bi-directional
streaming
and
unary
for
each
trade.
A
Think
of
them
as
sessions.
These
contexts
contain
references
to
the
actual
service
implementation,
to
call
processbank
and
to
the
generated
asynchronous
service
method.
To
start
serving
the
session
request
bank,
they
have
three
main
functionalities
start
session
that
we
do
as
we
allocate
them
right
now,
process
it
when
recourses
are
coming
and
eventually
complete
the
associated
rpc
or
keep
it
going.
A
We
use
the
address
of
the
context
as
the
tag
uniquely
identifying
the
current
jrpc
event
available
from
the
completion
queue
when
it's
time
to
process
the
event.
The
request,
contacts
dispatch,
the
current
concrete
implementation
of
the
rpc
call
using
the
reference
contained
into
the
process
func.
In
the
shown
case.
It
calls
the
submethod
that
is
responsible
to
pop
the
last
falco
alert
if
any
from
the
falco
outputs
queue
we
mentioned
before
and
write
it
into
the
response
stream.
A
In
case
there
are
more
file
colors
to
pop
and
to
stream
it
continues
to
write
them
into
the
response
stream.
This
operation
generates
another
jrpc
event
and
causes
the
completion
queue
to
trigger
again
and
restart
the
work
process.
In
case
there
are
no
more
falco
alerts
left
to
send
this
process
notifies
the
jrpc
core
to
be
able
to
read
requests
again.
A
Kpis
both
need
some
serious
love,
so
regardless
you're
interested
in
contributing
and
improving
the
c
plus
plus
farco
jr,
pc
server
and
methods
or
to
the
clients,
please
join
our
community
and
help
us
also
in
case
you
need
direction
or
support
feel
free
to
drop
me.
A
line
over
twitter
always
glad
to
help.
So
thanks.
Everyone
for
staying
here
for
so
long,
my
direct
messages
are
open.
You
can
find
me
with
ludio,
nickname
on
twitter
or
github
feel
free
to
follow
me
get
in
touch
for
even
more
details.