Frequently Asked Questions
Contents
- Which Photon Product Is The Right One For Me?
- How To Quickly Rejoin A Room After Disconnection?
- Threading
- Logging
Which Photon Product Is The Right One For Me?
The answer to this depends mostly on your project and team. Generally, we suggest to use either Fusion or Quantum, which are our most advanced client solutions.
For a quick overview, both product sheets contain the product picker "Quadrant":
Additionally, this page discusses using the photon cloud or photon server?.
Feel free to reach out to us for any questions.
How To Quickly Rejoin A Room After Disconnection?
To recover from an unexpected disconnection while joined to a room, the client can attempt to reconnect and rejoin the room. We call this a "quick rejoin". A quick rejoin will succeed only if:
- the room still exits on the same server or can be loaded: If a player leaves a room, the latter can stay alive on Photon server if other players are still joined. If the player is the last one to leave and the room becomes empty then the EmptyRoomTTL is how long it will remain alive waiting for players to join or rejoin. If after EmptyRoomTTL the room is still empty and no one joined then it will be removed from Photon server. If persistence conditions are met and webhooks are setup, the room state can be saved on the configured web service to be loaded later.
- the actor is marked as inactive inside: an actor with the same UserId exists inside the actors' list but not currently joined to the room. This requires PlayerTTL to be different from 0.
- the PlayerTTL for the inactive actor did not expire: when an actor leaves a room with the option to come back we save his Deactivation timestamp. As long as the room is alive, if PlayerTTL milliseconds are elapsed after Deactivation time the respective actor is removed from the actors' list. Otherwise, when the actor tries to rejoin, if the difference in milliseconds between the time of the rejoin attempt and Deactivation time exceeds PlayerTTL then the actor is removed from the actors' list and the rejoin fails. So an inactive actor can rejoin a room only for PlayerTTL milliseconds after Deactivation time.
A "quick rejoin" is composed of two steps:
- Reconnect: simply call the appropriate connect method once disconnected.
- Rejoin: call
loadBalancingClient.OpRejoin(roomName)
.
Threading
How To Avoid Race Conditions And Other Multithreading Issues?
In Photon we did as much as possible to simplify things:
- You may use PhotonPeer methods from any thread.
- All notifications from PhotonPeer are executed in one fiber (read about fibers below).
- All tasks in a room are executed in one fiber.
- Peers send messages to room's fibers in order to protect data from multithreading issues.
A fiber is a list of tasks which are executed one by one sequentially in FIFO manner. This does not mean that they are executed in one thread. Actually, they are executed in many threads, but one by one. So the first task may be executed in thread A, when it finishes, the second task may be executed in thread B and so one. But at every given moment just one thread accesses room data. In cases when many fibers access same data, we use locks. For instance, in a room's cache.
You may use fibers as follows:
// rooms contructor
someFiber = new PoolFiber(); // create new fiber
someFiber.Start();
someFiber.ScheduleForInterval(someRepetitiveRoutine, 0, 100); // start immediately and repeat every 100 ms, ie 10 times per second. this params may vary as you need
// at some other point, where you need to add more logic to the fiber
someFiber.Enqueue(newTask);
someFiber.Enqueue(()=>{ anotherTask(parameters);});
// from the tasks you can send messages to the room e.g. to notify the room of a result of a task
room.EnqueueMessage(new YourCustomMessage(somethingToSend));
Remember, if you use multiple custom fibers that share same code or same data, then you need synchronize access because actions in different fibers are executed concurrently.