Filter idea: Simple routing with every packet having the connection id appended #8
Comments
markmandel
added
kind/feature
|
Started work on this 👍 |
Connections id's should be Vec[u8] instead of strings, as the connection authentication tokens could easily be arbitrary data rather than strings. This PR implements this in the config, as well as changes the yaml storage to be a base64 encoding of the byte array. Implementation is done through a new type `ByteArray` which implements a custom de/serialiser for serde to create this functionality. Deliberately didn't use serde's de/serialize_with attributes as I couldn't find clean way to implement this in a way that would work for both the Vec<u8> in the Client config as well as a Vec<Vec<u8>> in the Server configuration. Work on #8
Connections id's should be Vec[u8] instead of strings, as the connection authentication tokens could easily be arbitrary data rather than strings. This PR implements this in the config, as well as changes the yaml storage to be a base64 encoding of the byte array. Implementation is done through a new type `ByteArray` which implements a custom de/serialiser for serde to create this functionality. Deliberately didn't use serde's de/serialize_with attributes as I couldn't find clean way to implement this in a way that would work for both the Vec<u8> in the Client config as well as a Vec<Vec<u8>> in the Server configuration. Work on #8
* Convert connection_id's to base64 byte arraus Connections id's should be Vec[u8] instead of strings, as the connection authentication tokens could easily be arbitrary data rather than strings. This PR implements this in the config, as well as changes the yaml storage to be a base64 encoding of the byte array. Implementation is done through a new type `ByteArray` which implements a custom de/serialiser for serde to create this functionality. Deliberately didn't use serde's de/serialize_with attributes as I couldn't find clean way to implement this in a way that would work for both the Vec<u8> in the Client config as well as a Vec<Vec<u8>> in the Server configuration. Work on #8 * Implement From * Introduce base64-serde and refactor to ConnectionId * ConnectionId::new() -> "".into()
Filter that appends the connection_id to each packet on the client side, and uses it to compare against endpoint stored connection_ids to route traffic to the appropriate game server on the server side. Work on #8 Integration tests and Metrics are next.
Filter that appends the connection_id to each packet on the client side, and uses it to compare against endpoint stored connection_ids to route traffic to the appropriate game server on the server side. Work on #8 Integration tests and Metrics are next.
|
Coming off context in #98 (comment) I feel like there are a few separate parts to tackle that I want to outline:
A couple of thoughts/questions on this:
Figuring this will also make xDS config easier as well. WDYT? |
|
I'm wondering if points 4 and 5 could be merged together? Since the From the looks of it, it seems the XDS api has both endpoint metadata support and Config for filters if we need that as well - we should be able to use them for e.g tokens |
|
So my thought with splitting 4 + 5 - was that if you had a different strategy to capture the token (maybe something unique to your game), you could still use the Router once the data was stored in the Context object, without having to write it yourself (even though the logic is pretty straight forward). It's sounding like we'll be able to drop connection_id though -- we could store tokens either on endpoint metdata or within the config of the filter itself. Question - I was looking at this Endpoint proto -- which doesn't seem to have metadata? Is that the same Endpoint we use in xDS? (I need to dig into that PR soon!) |
Ah yeah that makes sense, it would be harder to do if we had that part inside the router, splitting them sounds good!
Yes its pretty much the same, the one you linked (contains the actual address for the endpoing) is nested within the one I linked (which includes other metadata for that endpoint) - most of the api objects are quite large and nested like that 😬 |
Add a `values` of with a `HashMap` of `Any` to the filter context objects and results, and update the FilterChain to pass that Map between each invocation of a Filter in the chain. Work on #8
Add a `values` of with a `HashMap` of `Any` to the filter context objects and results, and update the FilterChain to pass that Map between each invocation of a Filter in the chain. Work on #8
Add a `values` of with a `HashMap` of `Any` to the filter context objects and results, and update the FilterChain to pass that Map between each invocation of a Filter in the chain. Work on #8
* Be able to pass data between Filters Add a `values` of with a `HashMap` of `Any` to the filter context objects and results, and update the FilterChain to pass that Map between each invocation of a Filter in the chain. Work on #8
The `ConcatBytes` filter's job is to add a byte packet to either the beginning or end of each UDP packet that passes through. This is commonly used to provide an auth token to each packet, so they can be routed appropriately. This also includes implementing `Filter` on `Box` to make reusable test assertion functions easier to write. Next step will be to remove `connection_id` from the Client config. Work on #8
The `ConcatBytes` filter's job is to add a byte packet to either the beginning or end of each UDP packet that passes through. This is commonly used to provide an auth token to each packet, so they can be routed appropriately. This also includes implementing `Filter` on `Box` to make reusable test assertion functions easier to write. Next step will be to remove `connection_id` from the Client config. Work on #8
The `ConcatBytes` filter's job is to add a byte packet to either the beginning or end of each UDP packet that passes through. This is commonly used to provide an auth token to each packet, so they can be routed appropriately. This also includes implementing `Filter` on `Box` to make reusable test assertion functions easier to write. Next step will be to remove `connection_id` from the Client config. Work on #8
* Concat Byte Filter The `ConcatBytes` filter's job is to add a byte packet to either the beginning or end of each UDP packet that passes through. This is commonly used to provide an auth token to each packet, so they can be routed appropriately. Next step will be to remove `connection_id` from the Client config. Work on #8
Since the inclusion of the connection id token is being processed as a filter, we no longer have a need for connection_id in the client configuration. Work on #8
Since the inclusion of the connection id token is being processed as a filter, we no longer have a need for connection_id in the client configuration. Work on #8
|
Working on the router at the moment, just need to wrap up some docs, and it'll be good to submit as a PR. I couldn't work out a good name for it - settled on "ConnectionIdRouter" just because we have this concept (currently) of a connection id on an Endpoint. Anyone got any better ideas? Some random thoughts as they come to me now, as we've been taking through concepts:
I was trying to have something about a "token" or something in the name, but maybe that's not neccessary? |
Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
* TokenRouter filter Implementation of the filter that will route packets to Endpoints that have a matching connection_id to the auth token found in the dynamic metadata. Closes #8
This design is not meant to necessarily be used for production workloads, but is a simple design for testing and POC work and also giving us a simple filter to get started with implementation wise that covers both a sender and receiver.
UDP Structure
The connection_id is on every packet, at the end, so as to not change data positioning.
Sender implementation
The Sender will append the
connection_idto the end of every packet it receives, and forward that to the receiver proxies.Configuration options:
Receiver implementation
Configuration options:
Logic
The Receiver will introspect the packet for the connection_id, and query the endpoints to see which ones contain that connection_id. The packet is then routed to only the endpoints that retain that connection_id
The text was updated successfully, but these errors were encountered: