This document is about: SERVER 5

What's new in Photon 5

Major Changes


The NameServer has been available on the Photon Cloud for a while and we decided to bring it to the self-hosted Photon Server in v5.

It is highly recommended to deploy the NameServer as default application for a LoadBalancing instance. Clients should connect to it first, authenticate, fetch the regions (available Master Servers) before switching to a MasterServer. This means the NameServer is useful to configure your different deployed regions or clusters and there is a new level of load balancing.

This has been used and appreciated by our Enterprise customers.

Read more here.

Built-In Authentication Providers

Client authentication is now done on the NameServer and no longer on the Master Server. This means the configuration for this moved (see Upgrade Guide).

Photon Server v5 includes four out-of-the-box providers, previously available on the Photon Cloud only: Facebook, Steam, Oculus and Vive. This is also another feature used and appreciated by our Enterprise customers.


Configuration Overhaul

The configuration system has been completely changed. It now relies on .NET Core's configuration providers for loading, parsing and binding. The server applications now requires "Microsoft.Extensions.Configuration.Abstractions" NuGet package in order to use the interface Microsoft.Extensions.Configuration.IConfiguration that will be injected to the application via a new constructor.

The PhotonServer.config file now also has XML schema validation on server startup.

New Limits

We've always had native settings (configured via PhotonServer.config) to set data transfer limits (message size, buffer size, data transfer rate).

So, in order to add a layer of protection to Photon Servers we introduced new settings that you can finetune to define usage limits.

  • MessageRate: The maximum number allowed of incoming messages per peer per second. Default is 5000.
  • MessageDataRate: The maximum size allowed of buffered incoming data per peer per second. Default is 2147483647 (int.MaxValue).
  • MaxMessageSize: The maximum size allowed for incoming messages. Default is 512000.

Read more about how to configure these in "Managed SocketServer Settings".

Serialization Protocol v1.8

The server now supports serialization protocol version 1.8 which should be the default for latest client SDKs. The new protocol brings new optimized and compact data transfer techniques for most commonly used types.

Secure Certificates Setup

We have switched from Secure Channel (Schannel) to OpenSSL in certificates format and configuration for secure listeners. You can find the new way to setup certificates here.

Photon Server v5 now also supports TLS 1.2 and TLS 1.3.

Scheduled Disconnect

In v5 we've added a way to schedule or delay disconnects, set the client's ConnectionState to ScheduledForDisconnect and give the server the ability to send DisconnectMessage to the client before disconnecting. Default delay is 5000 milliseconds. Also the server has more reasons to disconnect the server and the disconnect cause could be an error.

When a peer is scheduled for disconnects, the server will discard any data incoming from that peer.

Ending Support For 32bit

PhotonSocketServer is now available in 64bit only. "deploy\bin_Win32" is gone.


Configuration Overhaul

Configuration files have been changed so each application has its own file with a simplified new structure. Plugins configuration also moved to its own separate configuration file. Besides, HttpQueueSettings now have their own separate section and can be configured inside sections that make use of a HttpQueue.

New Limits

We always had a few miscellaneous configurable limits for LoadBalancing server applications. But this did not seem to be enough to shield Photon Server against attacks or abuse from malicious clients or hackers.

Operation Limits


We've added operation request and parameters limits per operation code.


There are also some limits for the most commonly used opeations: Join, Create and SetProperties:


  • JoinGameRate: the maximum number of Join requests per second per peer.
  • CreateGameRate: the maximum number of Create requests per second per peer.
  • SetPropertiesRate: the maximum number of SetProperties requests per second per peer.


  • MaxConcurrentJoinRequests: the maximum number of pending (queued unprocessed requests) Join operations per peer.
  • MaxTotalJoinRequests: the maximum total number of Join operations per peer.
  • MaxJoinedGames: the maximum number of rooms simultaneously joined by the same peer.
HTTP Limits

Other than the 'regular' HTTP Queue settings, you can limit the payload size of incoming HTTP responses via LimitHttpResponseMaxSize. This can be applied to custom authentication, WebRPCs or custom plugins (including Webhooks).

Events Cache Limits
  • SlicesCount: the maximum number of events cache slices per room.
  • EventsCount: the maximum number of cached events (for all actors and global cache) per room.
  • ActorEventsCount: the maximum number of cached events per actor per room.
Properties Limits


  • MaxUniqPropertyKeysPerPeer: the maximum number of distinct properties keys per actor per room.
  • MaxPropertiesPerRequest: the maximum number of distinct properties per SetProperties request.
  • MaxPropertiesSizePerGame: the maximum total/sum size of all properties per room.
  • MaxPropertiesSizePerRequest: the maximum size of any single property per SetProperties request.
Lobbies Limits
  • MaxGamesOnJoin: the maximum number of rooms list entries sent in GameList event when the client joins a lobby.
  • MaxGamesInUpdates: the maximum number of rooms list entries sent in GameListUpdate event.
  • MaxGamesInGetGamesListResponse: the maximum number of SQL rooms list entries as a result of a GetGameList request.
  • Total: the maximum number of lobbies per application.

.NET Targets

In preparation for v6, that will fully support .NET Core, server source code's .NET project style changed in v5 and we have added build files to prepare for this.

Build target configuration (also target build output folder, etc.) is handled via MSBuild files (csproj, csproj.includes) and custom defines and macros. See "build\include" folder. The build flow and deploy process is done mainly using "dotnet" command. That's why you need to have .NET Core runtime installed to be able to build and deploy although .NET Core is not a support build target yet.

Other than that, the target .NET Framework version was updated from 4.0 to 4.6.1. But you can build for .NET Framework versions higher than 4.6.1.

Local NuGet Repository

In v5 SDK, main libraries used in server applications development are now available as local NuGet packages:

  • ExitGamesLibs (ExitGamesLibs.dll)
  • ExitGames.PhotonHostRuntimes (PhotonHostRuntimesInterfaces.dll)
  • ExitGames.Logging (ExitGames.Logging.dll)
  • ExitGames.Logging.Log4Net (ExitGames.Logging.Log4Net.dll)

This done via "nuget.config" and Nuget package at the root of the SDK folder. You could manually add Package Source "WorkspaceNuget" from that "nuget.config" file if it's not done automatically for your solution.

Improved Feedback Control System (LoadBalancer)

The feedback control system used by the LoadBalancer was enhanced. It now contains double the feedback levels (used to be 5 and now are 10). We also introduced Priorities and Reserve.

New Server Error Codes

  • HttpLimitReached: 32745, it means the HTTP request failed because a limit has been reached.
  • ExternalHttpCallFailed: 32744, it means the HTTP request failed due to an issue related to the destination web service.
  • OperationLimitReached: 32743, it means the operation was blocked because a limit has been reached.
  • SlotError: 32742, it means there was an error updating expected users.
  • SecureConnectionRequired: 32740, it means peer was disconnected because the server requires secure connection which is enabled via "RequireSecureConnection" setting in LoadBalancing section.
  • EventCacheExceeded: 32739, it means events caching was cancelled because a limite has been reached.
  • ExpectedGSCheckFailure: 32738, it means the join operation failed because the client did not connect to the right expected GameServer provided by the MasterServer and encrypted in the auth token. This requires GameServer setting "TokenCheckExpectedHostAndGame" to be enabled.
  • ExpectedGameCheckFailure: 32737, it means the join operation failed because the client did provide the right expected GameId/RoomName provided by the MasterServer and encrypted in the auth token. This requires GameServer setting "TokenCheckExpectedHostAndGame" to be enabled.
  • AuthRequestWaitTimeout: 32736, a disconnect reason rather than an error code. It means the peer was disconnected because it stayed too long without authentication on the server. Happens on Master Server only. The timeout period can be set in Master setting "AuthTimeout". Default is 1200000 ms (20 minutes).
  • ConnectionSwitch: 32735, a disconnect reason rather than an error code. It means the disconnected peer was swapped for the active actor in the room because of a quick rejoin (using same session token).
  • ActorRemoved: 32734, a disconnect reason rather than an error code. It means the peer was disconnected because the corresponding actor was removed from a room.

Other Changes


  • The server now returns the UserId, as expected, in all cases as a result of the authentication operation. In case the UserId is not set by the client or auth provider, a GUID generated on the server is returned. In v4, the server did not return a UserId in this case.
  • Also, during authentication, in case the Nickname is not set by the authentication provider, the server will not return anything. In v4, the server returned a null Nickname in this case.
  • The server now will not allow the same actor to be added to the same interest group multiple times. This was possible in v4 and it resulted in receiving the same event sent to that interest group by that actor multiple times.
  • Ther server now supports session tokens and as a result, the quick rejoin feature works as expected.
  • Setting Expected Users after room creation via the well-known room property.


  • PlayerTTL and EmptyRoomTTL are added as well-known room properties that can be set (or changed) after room creation.
  • Room flags are added during room creation:
    • "Delete Null Properties": properties with null values will be deleted on the server.
    • "Broadcast Properties Change": the client who calls SetProperties will also receive PropertiesChanged event.
    • "SuppressPlayerInfo": we suppress getting any info about joined users during joining process still it is possible to get this info using GetProperties operation this flag overrides value of SuppressRoomEvents flag.
    • "CheckUserOnJoin", "SuppressRoomEvents", "PublishUserId" and "DeleteCacheOnLeave" (also called "CleanupCacheOnLeave") are now room flags. Used to be request parameters or well-known room properties.
  • New "GetGameList" operation for SQL lobby.
  • Additional security for SQL lobbies by protecting matchmaking filters (SQL queries) from SQL injection.
  • More performance counters. Find their list here.
  • JoinRandomRoom allows you to have multiple "chained" comma separated SQL filters (up to 3).
  • JoinRandomRoom allows you to create a room if no match is found.


  • Authentication in v5 should be done on the NameServer and no longer on the MasterServer. Although it's still available on the MasterServer, we will deprecate that in the future. Having Steam, Facebook, Oculus and Vive as authentication providers built-in on NameServer gives you another reason to move it there.

Other Changes


  • CounterPublisher is discontinued. Its related source and binaries (files and configuration) are removed from SDK. You can use Telegraf or Windows PerfMon instead.
  • MMO project.
  • StarDust test console client.

Photon Control Changes

  • "MMO Demo" instance submenu is removed.
  • "Run TestClient (LoadBalancing" is removed from "LoadBalancing (MyCloud)" submenu.
  • "Edit Nameserver.json" shortcut added.
Back to top