Implementation of a "Append Token Router" #98
Conversation
There was a problem hiding this comment.
I think we should be able to separate the append and router into two separate filters in place of nesting filters within each other? Say, an append filter that only appends bytes to payload and router filter that extracts bytes from payload to select endpoints - this way especially the append filter is reuseable e.g the token bytes can come from a different source than the append filter, or we could have another filter that also extracts bytes from the payload for other purposes and neither it nor the router need to be necessarily tied to the append filter.
Also its looking like the router doesn't fit very well as a filter as it depends on having a view of all endpoints while filter implementations today only sees the endpoints that were chosen by the loadbalancer (the router essentially does the job of the loadbalancer?)
If that's the case I think we might be able to to say that:
- the router filter is only useful if load balancing is turned off or we're broadcasting (though I'm less inclined to this one since it feels awkward and makes it possible for a user to make mistakes).
- instead of exposing
endpointsdirectly to filters, we could leverage the context object we plan to implement here to expose some function that filters call when they need to know endpoints information - then a router can request all endpoints while the default returns the load balanced endpoints as usual.
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.
markmandel
force-pushed
the
feature/append-token-router
branch
from
2e010f0
to
67c0ffc
Compare
|
Updated (with clippy fixes!!!) - PTAL. Also depends on how we feel about the discussion above. |
| "connection_id_length" => self.connection_id_length, "packet_length" => contents.len()); | ||
| return None; | ||
| } | ||
| let mut contents = contents; |
There was a problem hiding this comment.
the assignment doesn't look needed? we can have the mut in the function parameter?
| return None; | ||
| } | ||
|
|
||
| Some((filtered_endpoints, contents.to_vec())) |
There was a problem hiding this comment.
to_vec does a copy of the vector which might not be necessary? since the vec is already truncated by the split_off function?
AAAH! I just read this properly. I was reading it as separating the Client implementation from the Server implementation, but that's totally not what you are saying, my bad 🤦 What we're actually saying is - let's have a general purpose GOT IT. YES. Agreed. Lemme go back and look at your #102 PR, and then we can swing back around to this. 👍 I'll fix up some of your comments in the mean time as well, just so I can use this PR as a template to lift that functionality out. And will also file some tickets for the above sections too, unless you beat me to it for whatever reason. |
so make the functionality reusable in other contexts. |
|
Closing this PR, to clean things up. |
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.