Photon Server Configuration
This chapter explains how files and folders are organized for the Photon Server and how things are setup. Everything needed is in the deploy folder.
- Organization Of Server And Applications
- Configuration: PhotonServer.config
There are four versions of Photon in the folders: "bin_Win32", "bin_x64", "bin_Win32_xp" and "bin_win64_xp". We refer to these as binaries-folders.
Photon requires a separate folder next to the binaries-folder per application (e.g. "Lite" in the deploy folder). The assemblies must be in a "bin" subfolder (e.g. Lite/bin).
The following folders in the Server SDK deploy folder are applications: Lite, LiteLobby, MMO, CounterPublisher, Policy
Applications are setup in Photon's config file, as explained below.
The bin_tools folder currently contains useful tools:
- Baretail: Our favorite log viewer in the free edition. It is used by PhotonControl to view the latest logs.
- Photon Dashboard: The service to collect and concentrate Dashboard Counters and display them on a webpage.
- Perfmon: Contains a list of PerfMon counters used when you setup counter logging to a file. This is explained under "Administration".
- Stardust: A commandline testclient that can be used to get some load on a machine. This is shown in Photon in 5 Minutes
The main configuration file for Photon is the PhotonServer.config. An identical copy is located in each binaries-folder in the SDK. It is used to setup applications, listeners for IPs and performance specific values. It does not contain config values for the game logic.
The default values make sure Photon scales nicely on more cores but does not overwhelm a regular machine. In general performance tweaks are not needed.
The following settings are most commonly used. More options are described in the Photon Server Config Settings Page.
The config file defines which applications Photon should load on startup. In the "Applications" node, several "Application" entries can be added.
<Applications Default="Lite"> <!-- Lite Application --> <Application Name="Lite" BaseDirectory="Lite\Lite" Assembly="Lite" Type="Lite.LiteApplication" EnableAutoRestart="true" WatchFiles="dll;config" ExcludeFiles="log4net.config"> </Application> </Applications>
Each application is assigned a name by which the clients reference it on connect.
The BaseDirectory defines the folder in which an application resides. It does not name the "\bin" folder but expects it by convention. The Assembly names the .dll of an application and "Type its "main" class (which derives from Photon.SocketServer.Application).
The setting EnableAutoRestart tells Photon to start a shadow copy of the loaded application. This allows developers to replace the files without locking issues, making development more convenient. Photon will automatically start a new instance of an application 10 seconds after files are changed. WatchFiles and ExcludeFiles refines the list of files that trigger a restart. Clients that connected to a previous shadow copy will stay in it. New connects will use the new logic.
To load multiple applications, simply add more application nodes (with unique name). One of them can be made the default application by using its name ("Lite" in the example). The default app is the fallback for clients that try to connect to an unknown application.
Applications that are not setup in the PhotonServer.config won't be loaded and don't need to be deployed. When an application is in the config but the files are missing Photon won't start and name the issue in the logs.
These configure UDP and TCP endpoints on your machine respectively. You can use either (e.g. only UDP) or both.
The default IP 0.0.0.0 makes Phonton listen on any locally available IP. By replacing the wildcard IP, Photon will open only specific IPs and ports. Multiple UDPListener and TCPListener nodes can be defined, opening several IP/port combinations.
Per UDPListener and TCPListener node, you can setup an OverrideApplication or DefaultApplication. Override means: any client that connects to this port will end up in the application named, no matter what the client connects to. Default is a fallback, in case the application named by a client is not found.
<UDPListeners> <UDPListener IPAddress="0.0.0.0" Port="5055" OverrideApplication="Master"> </UDPListener> <UDPListener IPAddress="0.0.0.0" Port="5056" OverrideApplication="Game1"> </UDPListener> </UDPListeners>
Changing The Default Unity Ports
The default ports for Unity / UDP are: 5055 for the Master application and 5056 + 5057 for the Game Server applications. To change these ports, you need to do the following:
Open the Photon Server config in /deploy/bin[Winversion]. Edit the "Port" attribute of the
<UDPListeners> <UDPListener IPAddress="0.0.0.0" Port="5055" OverrideApplication="Master"> </UDPListener> <UDPListener IPAddress="0.0.0.0" Port="5056" OverrideApplication="Game1"> </UDPListener> <UDPListener IPAddress="0.0.0.0" Port="5057" OverrideApplication="Game2"> </UDPListener> </UDPListeners>
In /deploy/Loadbalancing/GameServer1 and /GameServer2, edit the "GamingUdpPort":
<setting name="GamingUdpPort" serializeAs="String"> <value>5056</value> </setting>
Change your client to connect to the new master server port. Restart Photon Server.
Could be removed but are needed when you create Silverlight or Flash games respectively. Both client-side plugins require a server to respond with a "policy file" (unless the website is on the same domain as Photon).
Two values in the instance node describe how the server times out unresponsive UDP clients: MinimumTimeout and MaximumTimeout.
<Instance1 EnablePerformanceCounters = "true" DataSendingDelayMilliseconds="50" AckSendingDelayMilliseconds="50" MinimumTimeout="5000" MaximumTimeout="30000">
A peer connected with UDP has MinimumTimeout milliseconds to respond before it can be disconnected. The actual time until disconnect, is determined dynamically per peer based on the RTT history. Previously good RTTs will disconnect faster.
TCP connections have a separate InactivityTimeout setting in the nodes TCPListener and TCPPolicyListener (also in the PhotonServer.config). We set those to 5 seconds (5000ms). If no request arrives in this time, the connection will be timed out and closed. Clients will also regularly Ping the server, to avoid this. Clients don't timeout for TCP.
Keep in mind that a client independently monitors a connection and might time it out as well. Both sides should have similar timeouts, fitting your game.
The attributes DataSendingDelayMilliseconds and AckSendingDelayMilliseconds represent a tradeoff between performance and minimal response times. This delay directly adds some lag to reduce the traffic: the wait allows the server to aggregate commands and send them in one package. The send delay is triggered when the server sends anything, the ack delay by incoming reliable data.
As you can see above, the default values are 50ms each. We found this to be a good value but it causes a \~50ms roundtrip time, even if client and server run on the same machine.
Depending on your game, you should load test with different values. A delay of 0 is a special case that skips usage of timers, so avoid low delays < 10.