Design and Implementation of Filters about quilkin HOT 5 CLOSED

Coming up with a filter configuration that works for both client and server configuration. This is what I came up with:

1. Added a "filters" section, that sits above the client/server section. The idea being that filters should be passed information that makes them aware of if they are in client or server mode.
2. Filters get passed a name. internally we should have some kind of registry of Filters that are a available (long term, if you used quilkin as a library, you could then add your own to the registry)
3. Filters can also have an arbitrary config passed in as well (probably passed in as serde enum.Value, which controls how filters work.

For example:

client-proxy.yaml

local:
  port: 7000 # the port to receive traffic to locally
filters: # new filters section
  - name: "quilkin.core.v1.rate-limiter" # the name that this filter is registered under
    config:
      map: of arbitrary key value pairs
      could:
        - also
        - be
        - an
        - array
client:
  address: 127.0.0.1:7001 # the address to send traffic to
  connection_id: 1x7ijy6 # the connection string to attach to the traffic

server-proxy.yaml

local:
  port: 7001 # the port to receive traffic to locally
filters:
  - name: "quilkin.core.v1.rate-limiter" # the name that this filter is registered under
    config:
      map: of arbitrary key value pairs
      could: 42
server:
  endpoints: # array of potential endpoints to send on traffic to
    - name: Game Server No. 1
      address: 127.0.0.1:26000
      connection_ids:
        - 1x7ijy6 # connection ids to route on
        - 8gj3v2i
    - name: Game Server No. 2
      address: 127.0.0.1:26001
      connection_ids:
        - nkuy70x

How do we feel about a setup like this?

from quilkin.

I'd prefer it if the client could get as much config as possible from the server rather than having its own, does that make sense ? It avoids people modifying the client config file in a way we don't want them to, and also makes it easier for us to update.
As such, I'd like the client to know of exactly two things only: Its own ID, and the server to connect to.

from quilkin.

So you raise an interesting idea @luna-duclos !

So in my mind, the yaml file is a useful data structure design tool / stopgap / during game development tool util we have a gRPC control API (#10) down the line -- which would let you configure everything we can see in the yaml file (which is basically how Envoy works - you have a static config, i.e. yaml and a dynamic config, i.e. via the API)

So in production, the client would likely make a gRPC connection to the proxy to configure it - meaning there is far less surface area for a user to manipulate (especially easily on the client side).

Then it would be the responsibility of the custom client/game system to receive and propagate out any configuration updates as required.

In my mind - Quilkin doesn't provide the control plane, but provides the foundation for a control plane (much like the difference between Envoy and Istio). We could then down the line have separate opinionated control plane implementations on top of Quilkin.

That all being said, we should think about how we can ensure the client side proxy is relatively tamper proof - or at least, if people DO tamper with it, it doesn't really affect anything. (maybe part we have a filter for quilkin that sends a hash of the current config, and the server receives the hash, and if it's changed, it refuses the connection???) - but this feels to me like a separate design ticket.

Also, depending on how we do the gRPC control plane API (which I think comes once we've locked down the design of some of the basic config data structures), what you propose might actually be possible -- depending on how you set it up. (i.e. should the control plane reach out to something? Should it be only accept connections? maybe both? but that's a discussion for #10)

That sound good?

from quilkin.

Had an offline slack chat. We agreed that this is an appropriate data structure for filters at this stage.
Also agreed that concerns about client side safety will continue to be explored in #10

from quilkin.

From conversation today, we need to look at the filter ordering is reversed appropriately between sending and recieving, so that filters run in the correct order.

For example, we may need to flip ordering around here on endpoint receive:
https://github.com/googleforgames/quilkin/blob/master/src/extensions/filter_chain.rs#L97-L107

from quilkin.