When you build an online multiplayer game, you have to be aware that sometimes connections between clients and servers fail.
Disconnects might be caused by software or hardware. If any link of a connection fails, messages get delayed, lost or corrupted and the connection need to be shut down.
If this happens frequently you can usually do something about it.
- Disconnect Reasons
- Timeout Disconnect
- Traffic Issues And Buffer Full
- First Aid
- Fine Tuning
- Platform Specific Info
- Recover From Unexpected Disconnects
Client SDKs provide disconnection callbacks and a disconnect cause. Use those to investigate the unexpected disconnects you are having. Here we list the major disconnect causes and whether they are caused on the client or the server side.
Disconnects By Client
- Client-side timeout: no/too late ACKs from the server. See "Timeout Disconnect" for more details.
- Client socket exception (connection loss).
- Client connection fails on receive (buffer full, connection loss). See "Traffic Issues and Buffer Full".
- Client connection fails on send (buffer full, connection loss). See "Traffic Issues and Buffer Full".
Disconnects By Server
- Server-side timeout: no/too late ACKs from client. See "Timeout Disconnect" for more details.
- Server send buffer full (too many messages). See "Traffic Issues and Buffer Full".
- License or Subscription CCU limit hit.
Unlike plain UDP, Photon's reliable UDP protocol establishes a connection between server and clients: Commands within a UDP package have sequence numbers and a flag if they are reliable. If so, the receiving end has to acknowledge the command. Reliable commands are repeated in short intervals until an acknowledgement arrives. If it does not arrive, the connection is timed out.
Both sides monitor this connection independently from their perspective. Both sides have their rules to decide if the other is still available.
If a timeout is detected, a disconnect happens on that side of the connection. As soon as one side thinks the other side does not respond anymore, no message is sent to it. This is why timeout disconnects are one sided and not synchronous.
The timeout disconnect is the most frequent issue, aside from problems to connect "at all".
There is no single point of failure when you run into frequent timeouts but there are a few common scenarios that cause issues and some ways to fix them.
Here is a quick checklist:
- Check the amount of data you are sending. If there are spikes or if your messages/sec rate is very high, this can affect the connection quality. Read "Send Less"
- Check if you can reproduce the issue on other hardware and on another network. See "Try Another Connection".
You can adjust the number and timing of resends. See "Tweak Resends".
If you are making a mobile app, read about Mobile Background Apps.
If you want to debug your game using breakpoints and all, read this.
Traffic Issues And Buffer Full
Photon servers and clients usually buffer some commands before they are actually put into a package and sent via the internet. This allows us to aggregate multiple commands into (fewer) packages.
If some side produces a lot of commands (e.g. by sending lots of big events), then the buffers might run out.
Filling buffers will also cause additional Lag: You will notice that events take longer to arrive on the other side. Operation responses are not as quick as usual.
Read "Send Less".
Check The Logs
This is the first check you need to do.
All clients have some callback to provide log messages about internal state changes and issues. You should log these messages and access them in case of problems.
You can usually increase the logging to some degree, if nothing useful shows up. Check the API reference how to do this.
If you customized the server, check the logs there.
Enable The SupportLogger
SupportLogger is a tool that logs the most commonly needed info to debug problems with Photon, like the (abbreviated)
AppId, version, region, server IPs and some callbacks.
In PUN Classic, the SupportLogger is a component. Create an empty GameObject in a scene that's enabled before you connect. Add the SupportLogger component and you're done. The console or log file will contain the new log entries.
Try Another Project
All client SDKs for Photon include some demos. Use one of those on your target platform. If the demo fails too, an issue with the connection is more likely.
Try Another Server Or Region
Using the Photon Cloud, you can also use another region easily.
Hosting yourself? Prefer physical over virtual machines. Test minimum lag (round-trip time) with a client near the server (but not on the same machine or network). Think about adding servers close to your customers.
Try Another Connection
In some cases, specific hardware can make the connection fail. Try another WiFi, router, etc. Check if another device runs better.
Try Alternative Ports
Since early 2018, we support a new port-range in all Photon Cloud deployments: Instead of using 5055 to 5058, the ports start at 27000.
Changing the ports does not sound like it should make a difference but it can have a very positive effect. So far, the feedback was really positive.
In PUN, you can set
PhotonNetwork.UseAlternativeUdpPorts = true before you connect.
Enable CRC Checks
Sometimes, packages get corrupted on the way between client and server. This is more likely when a router or network is especially busy. Some hardware or software is outright buggy corruption might happen anytime.
Photon has an optional CRC Check per package. As this takes some performance, we didn't activate this by default.
You enable CRC Checks in the client but the server will also send a CRC when you do.
PhotonNetwork.CrcCheckEnabled = true before you connect
Photon clients track how many packages get dropped due to enabled CRC checks.
You could monitor
Check Traffic Stats
On some client platforms, you can enable
Traffic Statistics directly in Photon.
Those track various vital performance indicators and can be logged easily.
In C#, the Traffic Stats are available in the LoadBalancingPeer class as
This provides an overview of the most interesting values.
As example, use
TrafficStatsGameLevel.LongestDeltaBetweenDispatching to check the longest time between to consecutive
If this time is more than a few milliseconds, you might have some local lag.
LongestDeltaBetweenSending to make sure your client is frequently sending.
TrafficStatsOutgoing properties provide more statistics for in- and outgoing bytes, commands and packages.
PUN has two properties which allow you to tweak the resend timing:
PhotonNetwork.QuickResends speed up repeats of reliable commands that did not get acknowledged by the receiving end.
The result is a bit more traffic for a shorter delays if some message got dropped.
PhotonNetwork.MaxResendsBeforeDisconnect defines how often the client will repeat an individual, reliable message.
If the client repeats faster, it should also repeat more often.
In some cases, you see a good effect when setting
PhotonNetwork.QuickResends to 3 and
PhotonNetwork.MaxResendsBeforeDisconnect to 7.
More repeats don't guarantee a better connection though and definitely allow longer delays.
Check Resent Reliable Commands
You should begin to monitor
This counter goes up for each resend of a reliable command (because the acknowledgement from the server didn't arrive in time).
If this value goes through the roof, the connection is unstable and UDP packets don't get through properly (in either direction).
You can usually send less to avoid traffic issues. Doing so has a lot of different approaches:
Don't Send More Than What's Needed
Exchange only what's totally necessary. Send only relevant values and derive as much as you can from them. Optimize what you send based on the context. Try to think about what you send and how often. Non critical data should be either recomputed on the receiving side based on the data synchronized or with what's happening in game instead of forced via synchronization.
In an RTS, you could send "orders" for a bunch of units when they happen. This is much leaner than sending position, rotation and velocity for each unit ten times a second. Good read: 1500 archers.
In a shooter, send a shot as position and direction. Bullets generally fly in a straight line, so you don't have to send individual positions every 100 ms. You can clean up a bullet when it hits anything or after it travelled "so many" units. No need to instantiate and destroy each bullet.
Don't send animations. Usually you can derive all animations from input and actions a player does. There is a good chance that a sent animation gets delayed and playing it too late usually looks awkward anyways.
Use delta compression. Send only values when they changes since last time they were sent. Use interpolation of data to smooth values on the receiving side. It's preferable over brute force synchronization and will save traffic.
Don't Send Too Much
Optimize exchanged types and data structures.
- Make use of bytes instead of ints for small ints, make use of ints instead of floats where possible.
- Avoid exchanging strings at all costs and prefer enums/bytes instead.
Avoid exchanging custom types unless you are totally sure about what get sent.
Typically avoid exchanging a
Vector3for rotation of your character as most likely it only rotates around the vertical axis. So make extra code to extract the vertical rotation and only send this you save 2/3 of the size just for that parameter.
- Don't try to combine data into arrays.
Split everything into individual using
stream.SendNext()for every single variable.
- Be careful of over-using Custom Properties. If you set a lot of them in a long running game, joining players will have a lot to catch up with. When your clients drop a lot while joining a room, check this.
Use another service to download static or bigger data (e.g. maps). Photon is not built as content delivery system. It's often cheaper and easier to maintain to use HTTP-based content systems. Anything that's bigger than the Maximum Transfer Unit (MTU) will be fragmented and sent as multiple reliable packages (they have to arrive to assemble the full message again).
Don't Send Too Often
Lower the send rate, you should go under 10 if possible. This depends on your gameplay of course. This has a major impact on traffic. You can also use adaptive or dynamic send rate based on the user's activity or the exchanged data, this is also helping a lot.
Send unreliable when possible. You can use unreliable messages in most cases if you have to send another update as soon as possible. Unreliable messages never cause a repeat. Example: In an FPS, player position can usually be sent unreliable.
Try Lower MTU
With a setting on the client-side, you can force server and client to use an even smaller maximum package size than usual. Lowering the MTU means you need more packages to send some messages but if nothing else helped, it makes sense to try this.
The results of this are unverified and we would like to hear from you if this improved things.
PhotonNetwork.networkingPeer.MaximumTransferUnit = 520;.
This network protocol analyzer and logger is extremely useful to find out what is actually happening on the network layer of your game. With this tool, we can have a look at the facts (networking wise).
Wireshark can be a bit intimidating but there are only a few settings you have to do when we ask you to log our game's traffic.
Install and start. The first toolbar icon will open the list of (network) interfaces.
You can check the box next to the interface which has traffic. In doubt, log more than one interface. Next, click "Options".
We don't want all your network traffic, so you have to setup a filter per checked interface. In the next dialog ("Capture Options"), find the checked interface and double click it. This opens another dialog "Interface Settings". Here you can setup a Filter.
A filter to log anything Photon related looks like so:
(udp || tcp) && (port 5055 || port 5056 || port 5057 || port 5058 || port 843 || port 943 || port 4530 || port 4531 || port 4532 || port 4533 || port 9090 || port 9091 || port 9092 || port 9093 || port 19090 || port 19091 || port 19093 || port 27000 || port 27001 || port 27002)
When you press "Start", the logging will begin when you connect. After you reproduced an issue, stop the logging (third toolbar button) and save it.
In best case, you also include a description of what you did, if the error happens regularly, how often and when it happened in this case (there are timestamps in the log). Attach a client console log, too.
.pcap and other files to us and we take a look.
Platform Specific Info
PUN implements the
Service calls for you in intervals.
However, Unity won't call
Update while it's loading scenes and assets or while you drag a standalone-player's window.
To keep the connection while loading scenes, you should set
PhotonNetwork.IsMessageQueueRunning = false.
Pausing the message queue has two effects:
- A background thread will be used to call
Updateis not called. This keeps the connection alive, sending acknowledgements only but no events or operations (RPCs or sync updates). Incoming data is not executed by this thread.
- All incoming updates are queued. Neither RPCs are called, nor are observed objects updated. While you change the level, this avoids calling RPCs in the previous one.
If you use our Photon Unity SDK, you probably do the
Service calls in some MonoBehaviour
To make sure Photon client's
SendOutgoingCommands is called while you load scenes, implement a background thread.
This thread should pause 100 or 200 ms between each call, so it does not take away all performance.
Recover From Unexpected Disconnects
Disconnects will happen, they can be reduced but they can't be avoided. So it's better to implement a recovery routine for when those unexpected disconnects occur especially mid-game.
When To Reconnect
First you need to make sure that the disconnect cause can be recovered from. Some disconnects may be due to issues that cannot be resolved or bypassed by a simple reconnect. Instead those cases should be treated separately and handled case by case.
Quick Rejoin (ReconnectAndRejoin)
Photon client SDKs offer a way to rejoin rooms as soon as possible after being disconnected while joined to a room. This is called "Quick Rejoin". Photon client locally caches the authentication token, the room name and the game server address. So when disconnected mid-game, the client can do a shortcut: connect directly to the game server, authenticate using the saved token and rejoin the room.
In PUN, this is done using
Check the return value of this method to make sure the quick rejoin process is initiated.
In order for the reconnect and rejoin to succeed, the room needs to have PlayerTTL != 0. But this is not a guarantee that the rejoin will work. If the reconnection and authentication is successful, rejoin can fail with one of the following errors:
- GameDoesNotExist (32758): the room was removed from the server while disconnected. This probably means that you were the last actor leaving the room when disconnected and that 0 <= EmptyRoomTTL < PlayerTTL or PlayerTTL < 0 <= EmptyRoomTTL.
- JoinFailedWithRejoinerNotFound (32748): the actor was removed from the room while disconnected. This probably means that PlayerTTL is too short and expired, we suggest at least a value of 12000 milliseconds to allow a quick rejoin.
- PluginReportedError (32752): this probably means that you use webhooks and that PathCreate returns ResultCode other than 0.
- JoinFailedFoundActiveJoiner (32746): this is very unlikely to happen but it may. It means that another client using the same UserId managed to rejoin the room while you were disconnected.
If the client got disconnected outside of a room or if quick rejoin failed (
ReconnectAndRejoin returned false) you could still do a Reconnect only.
The client will reconnect to the master server and reuse the cached authentication token there.
In PUN, this is done using
Check the return value of this method to make sure the quick rejoin process is initiated.
It could be useful in some cases to add:
- check if connectivity is working as expected (internet connection available, servers/network reachable, services status)
- reconnect attempts counter: max. retries
- backoff timer between retries