Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List active sessions using the API #787

Open
alt4 opened this issue Sep 11, 2023 · 2 comments
Open

List active sessions using the API #787

alt4 opened this issue Sep 11, 2023 · 2 comments
Labels
kind/feature New feature or request

Comments

@alt4
Copy link

alt4 commented Sep 11, 2023

Hello! I'm filling this issue as per my conversation with Mark Mandel on Discord.

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

I am hosting a game that gets exposed to the Internet by Quilkin using the standard sidecar pattern on a generic k8s, with no Agones involved (yet?).
I happen to need to know the real client IP specific players use to connect to the game at a given moment.
This is far from easy at the moment since the game server only sees Quilkin's own IP. If I'm not mistaken, this IP is always 127.0.0.1 (due to the sidecar) for each players, but client port differs for each session.

Describe the solution you'd like

A /sessions API endpoint of sorts that would return currently active sessions with i.e.:

  • The real Client IP & Client Port, which in my case would be the player's to Quilkin
  • The client port (and possibly client IP?) Quilkin allocates to that session and uses to connect to the endpoint (game in my case)
    would let me map the latter to the former directly from the game.
  • The endpoint's IP and port Quilkin is proxying the client to (I wouldn't have much use for this myself having only one endpoint configured, but I suppose this could be useful otherwise)

I am not quite sure which format to use to return data would be optimal, but a simple JSON would likely work perfectly for me.

That endpoint may also be useful to troubleshoot specific sessions, and maybe provide additional session-specific data (i.e. lifetime, time since last packet transited or other metrics Quilkin might collect in the background).

Describe alternatives you've considered

N/A, though I am very much open to other solutions!

Additional context

Just in case, my current Quilkin config is as follow:

apiVersion: v1
kind: ConfigMap
metadata:
  name: quilkin-sidecar-config
  labels:
    app: game
data:
  quilkin.yaml: |
    version: v1alpha1
    admin:
      address: "[::]:9091"
    id: game-proxy
    port: 8888
    clusters:
      default:
        localities:
          - endpoints:
              - address: 127.0.0.1:7777

And the container declaration in my kube manifest, alongside the game's container:

[...]
      - name: quilkin
        image: us-docker.pkg.dev/quilkin/release/quilkin:0.5.0
        args: ["proxy"]
        ports:
        - name: proxy
          containerPort: 8888
          hostPort: 7777
          protocol: UDP
        livenessProbe:
          httpGet:
            path: /live
            port: 9091
          initialDelaySeconds: 3
          periodSeconds: 2
        resources:
          requests:
            memory: "128M"
            cpu: "0.25"
          limits:
            memory: "512M"
            cpu: "1"
        volumeMounts:
          - mountPath: /etc/quilkin/quilkin.yaml
            subPath: quilkin.yaml
            name: quilkin-config
            readOnly: true
[...]

Some more context is available in the Discord conversation linked at the top, but I am of course ready to provide more details if necessary :)

@alt4 alt4 added the kind/feature New feature or request label Sep 11, 2023
@XAMPPRocky
Copy link
Collaborator

Thank you for your issue!

This where I scope creep this feature a little bit and ask, instead of having dedicated endpoints for each kind of data users are interested in querying, what if we instead had a GraphQL endpoint, and we merged this with /config? That would also be more useful for your use-case where you could subscribe to sessions, and then you'd receive session data as it becomes available in Quilkin, rather than needing to repeatedly poll and search for new information yourself.

What do you think @markmandel ?

@markmandel
Copy link
Contributor

I knew I was going to have to learn GraphQL one day 😄 runs off to read docs

Yeah, this makes a lot of sense, and it's expandable over time. We can put config info in here, session info, and potentially more -- and it can change depending on mode, since the endpoint has built in discover ability. Yeah, count me as sold.

I do wonder if /config is the right endpoint name (/graphql ?), but that's minor detail.

@XAMPPRocky got a favourite Rust + GraphQL library?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants