Optionally specify the session key through a Filter

[markmandel]

Is your feature request related to a problem? Please describe.

This is driven by the fact that legacy game servers utilise the connection address + port as information of a user connection, and will likely get confused by packets coming from multiple Quilkin proxies, since they will be seen as different users. Which makes it difficult to setup a horizontally scalable set of proxies in front of legacy game servers.

What I think we need is a way to be able to proxy incoming connections from a variety of sources, and specify how we want that to be turned into a Session Key, such that if there is identifiable information in the packet, it can be utilised as a Session Key, regardless of where it comes from.

Describe the solution you'd like

I visualise this like so:

                            Dynamic Load Balancer

                              ┌─────────┐
                              │         │
                              │         │
                      ┌───────► Quilkin │
┌─────────┐           │       │ Proxy   ├───────────┐      Converts incoming packets
│         │           │       │         │           │      into singular connections
│ Client  ├───────────┤       └─────────┘           │      per routing token.
│         │           │                             │      ┌───────────┐            ┌────────────┐
└─────────┘           │       ┌─────────┐           │      │           ├────────────►            │
                      │       │         │           │      │  Quilkin  │            │  DGS       │
                      │       │         │       ┌───┴──────►  Sidecar  │            │            │
                      ├──────►│ Quilkin ├───────┤          │           ├────────────►            │
┌─────────┐           │       │ Proxy   │       │          └───────────┘            └────────────┘
│         │           │       │         │       │
│ Client  ├───────────┤       └─────────┘       │                        Two discreet connections
│         │           │                         │                        Since there are two clients
└─────────┘           │       ┌─────────┐       │
                      │       │         │       │
                      │       │         │       │
                      └──────►│ Quilkin ├───────┘
                              │ Proxy   │
                              │         │
                              └─────────┘

So the new part would be the sidecar to pull back all the routed tokens from the scalable proxies into the expected set of connections.

To do this, I would recommend adding a session_key: Option<String> to ReadResponse https://github.com/googleforgames/quilkin/blob/4800db48b5da64df227e4368ee485b4d6a89ad85/src/filters/read.rs#L81-L88

If set, that would be the session key utilised when creating and looking up the session. If not set, we use the default we use now.

We could then write a SessionKey filter (or some better name 😄 ) that could use the token stored in dynamic metadata to provide the session key.

My theory being, that an implementation of the above sidecar would be the following config:

version: v1alpha1
filters:
  - name: quilkin.filters.capture.v1alpha1.Capture
    config:
      metadataKey: myapp.com/myownkey
      prefix:
        size: 3
        remove: true
  - name: quilkin.filters.session.v1alpha1.SessionKey
    config:
      metadataKey: myapp.com/myownkey
clusters:
  default:
    localities:
        - endpoints:
            - address: 127.0.0.1:7001

Which would mimic the Capture logic on the load balancer proxies, but would be remove: false, since we need the token to pass through to the sidecar.

Describe alternatives you've considered

We don't do this, but I'm fairly sure we'll need it unless the game server has specific logic to ignore connection information, and that seems rare.

Additional context

I'm assuming that Xonotic will fail with a dynamic set of load balancer proxies setup in front of it, due to this issue. I've yet to actually test it (I should in the near future).

[XAMPPRocky]

This seems like a great idea to me. The only thing I would offer is, should this be a filter? I don't feel super strongly about it, but session configuration seems separate to per packet filters. For example, is there ever a reason not to have SessionKey be the last thing?

It might be more intuitive to have some session specific configuration. Like we could have a session.source, and the allowed values would be either IP which is how sessions currently works, or they could specify a metadata key.

[markmandel]

My thought on allowing it to be a Filter means that while we can provide some default implementations, but if an end user wanted to create their own strategy, it would be possible through providing their own Filters (either by using it as a library, or eventually something like #13 or #420).

If we tie it to the proxy config, it's harder to extend. That being said - we could create a new extension point to manage different types of connections, but it might be worth crossing that bridge if we need to 🤷🏻