Fly replay problems (game server)

Hi everyone!

I’m finally learning how to setup a proper game server architecture on, and I have some questions since I’ve never actually done this before :smile:

So far, my I have the following apps & their deployment pipelines ready

  • client: responsible of a spa application on the frontend. No problems there.
  • api: responsible of a regular application communication with database/api handling and can create machines with the machines api
  • game-server-gateway: I recently created this to communicate with the game-server app’s machines via fly-replay
  • game-server: the host of N amount of game-server machines created dynamically from the api app

Now, the real question is; how to actually communicate with the game-server machines? Currently I’m trying to just make a request to game-server-gateway app’s root path, with machine header information. Here is the code for it:

// Game server gateway machine
app.get('*', (c) => {
  const region = c.req.header('region')
  const instance = c.req.header('instance')
  if (!region || !instance) {
    throw new Error('Machine not found')
  console.log('replaying', `region=${region};app=floating-islands-game-server;instance=${instance}`)
  c.header('fly-replay', `region=${region};app=floating-islands-game-server;instance=${instance}`)
  return c.body('OK')

It seems to “work”, since I do get a timeout and the console log information to the gameway app log. But is this the right way to do things, if I just want to replay the request to the game server machine? There should be a root path returning arbitrary data in the game server machines end:

// Game server machine
app.get('/', async (c) => {
  const adventure = await getAdventure()
  return c.json(adventure)

But since I do get a timeout, I may have done something terribly wrong. I’ve allocated ip:s for the game server apps as well but I wonder if this is required? Should the replay header work in the internal networkings of fly without any hassle?

Thank you guys for any help you can provide! :pray:

Hi… It looks like the timeout is really due to the game servers themselves—not the replay:

$ curl -i ''
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection

Perhaps you could post the fly.toml, for that app?

Aside: Also, you might be interested in the parallel thread on region/replay nuances.

1 Like

Added machines, nodejs

Sure thing!

Here is the toml file. It used to be a bit less complex, but I copy pasted some configs in desperation from a previous (singular) application/machine I had like two years ago. It used to have udp but this might not be the case now. Would just like to get http/ws working before that :smiley:

# fly.toml app configuration file generated for floating-islands-api on 2024-03-29T21:25:59+02:00
# See for information about how to use this file.

app = 'floating-islands-game-server'
primary_region = 'ams'

  PORT = '8000'

  dockerfile = 'Dockerfile'

  allowed_public_ports = []
  auto_rollback = true

  internal_port = 10000
  protocol = "udp"

    port = 10000

  http_checks = []
  internal_port = 8000
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

    hard_limit = 2000
    soft_limit = 1000
    type = "connections"

    handlers = ["http"]
    port = 80

    handlers = ["tls", "http"]
    port = 443

    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

  memory = '256mb'
  cpu_kind = 'shared'
  cpus = 1

Also, here is my github actions script/step for this (btw just noticed I was building from wrong dockerfile, but fixing it seems to not work either):

- run: flyctl deploy --remote-only --build-only --push --dockerfile ./apps/game-server/Dockerfile --config ./apps/game-server/fly.toml --image-label newest
        working-directory: ./
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN_GAME_SERVER }}

I also noticed that all my secrets are all still staged… This might prevent the machine from booting normally since it might crash because of the database connection not being able to initialize. I’ve not actually deployed the app at all since it should only contain machines that are spawned by the api -app. What is the best course of action on this, to get the secrets deployed properly?

fly secrets deploy -a floating-islands-game-server should work for that.

(You can verify with fly ssh console -a floating-islands-game-server -C env, afterward.)

In general, it’s also wise to look in the logs when there are timeouts, etc.: fly logs -a floating-islands-game-server.

1 Like

Hmmm, it says: 'fly secrets deploy' will only work if the app has been deployed and there are machines available :thinking: There is currently one machine “running”, as in it might be crashed since the secrets are not available… :smiley: What to do…

EDIT: Does this mean my app is not deployed at all and might be causing all the problems? How to deploy it if I do not want any machines running other than the dynamic ones? :thinking:

I think things may have gotten into a non-intuitive state that is (as far as I know) primarily intended for Fly Postgres machines: the app exists and has a machine, but there are no “releases” in the strictest sense.

Maybe try the following, first, to confirm:

$ fly app releases -a floating-islands-game-server
$ fly m status -d  -a floating-islands-game-server
$ fly logs         -a floating-islands-game-server

For the second one, you’re looking for fly_release_id and fly_release_version as metadata keys.

(And the third will typically help resolve doubts about why it’s crashing, :thought_balloon:.)

If the hypothesis does hold up, then you might be able to use --update-only to introduce a release without the creation of any machines.

(But I’m just guessing now.)

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.