Game server events

Game servers meet many events throughout their lifecycles. This section covers unusual and unexpected events, such as misbehavior and crashes. For other events, refer to the server lifecycle.

Misbehavior

When a game server misbehaves, it means something unexpected (other than a crash) happened with the build executable process. Usually, this means the build executable process started using more resources (CPU and memory) than the server slot allows or stopped responding to queries for an extended period of time.

Multiplay Hosting checks for misbehaving servers using a series of game server checks that run every minute. These checks ensure that the build executable process is:

  1. Within the expected CPU usage limits (with a 10% tolerance).
  2. Within the expected memory usage limits (with a 200 megabyte tolerance).
  3. Responding to queries.✝

Note: Multiplay Hosting only checks if game servers respond to queries if you implement a query protocol in the build and specify it in the build configuration.

If Multiplay Hosting detects that a build executable process is misbehaving, it sends the process a SIGSEGV signal. By default, Multiplay Hosting only considers build executables as misbehaving if they fail the same check three times within a 30-minute period.

Server check cycle - CPU failure

Crashes

A crash refers to an unintentional termination of a build executable process with any exit code other than 0 (opposed to an intentional exit). The recommended best practice is to have a build executable exit with a non-zero exit code when it meets an issue from which is can't recover.

When Multiplay Hosting detects that a build executable crashed, it attempts to recover the game session by restarting it with the same allocation ID. However, if the build executable continues to crash, Multiplay Hosting backs off and stops trying to recover the game session.

Allocation pre-recovery

The allocation pre-recovery process prevents Multiplay Hosting from automatically restarting game servers that were allocated when they crashed.

Note: Multiplay Hosting only detects crashes if you implement a query protocol in the build and specify it in the build configuration.

When Multiplay Hosting detects that a game server no longer responds to server state queries (using the implemented server query protocol), it checks if the game server was allocated during the crash by reading the allocation UUID.

If the game server doesn’t have an allocation UUID, Multiplay Hosting restarts the build executable process. If the game server continues to crash, Multiplay Hosting stops restarting the game server. Refer to crash backoff.

If the game server has an allocation UUID, Multiplay Hosting won’t restart the game server process. Instead, the game server remains stopped until it receives a new allocation. This prevents Multiplay Hosting from starting game servers with stale allocation information.

Crash back-off

Multiplay Hosting backs off and stops trying to recover a game session by restarting the build executable if the build executable process crashes more than a specific number✝ of times within a 30-minute period.

Note: By default, Multiplay Hosting only tries to restart the build executable process once (if the servers are running on a cloud machine).

Unity logo Documentation
Copyright © 2024 Unity Technologies
"Unity", Unity logos, and other Unity trademarks are trademarks or registered trademarks of Unity Technologies or its affiliates in the U.S. and elsewhere (more info here). Other names or brands are trademarks of their respective owners.