Basic Concepts

Applications

An Application is the server side logic for a game.
All features of a game (e.g. remote procedure calls, data storing, etc.) are implemented in a Photon application.
The C# source is compiled and the resulting assemblies are loaded by Photons native core.
To setup applications and to define start parameters the Photon Core uses configuration files.

Usually, all logics of a game are provided in a single application.
Photon is still able to run several applications at the same time.
Each application can have a different task.
For example, a separate application can be made to send out policy files for web-based clients.

A client chooses the application it wants to use by simply providing the application's name on connect.

Game Logic

The game logic defines how a client can interact with the server.
It implements operations, events, and anything that the server does by itself.

A good basis for room based games is provided as "LoadBalancing Application", found in the SDK folder ("{Server_SDK_path}/src-server/Loadbalancing").

If your game is going to be a single, huge world, the MMO Demo Application is a good basis for it.
This application handles interest management for your clients and provides classes for items, properties, actors and more.

Alternatively any game logic can be developed directly on top of the C# framework.
The entry point for this is the application class, defined in the "Photon.Socketserver.dll".

Operations

An operation is Photon's equivalent to a remote procedure call.
Photon clients use operation calls for anything they want to get done.

Operations and all of their parameters are defined in the server-side application as needed.
Clients can call any operation by setting up a hashtable with keys and values fitting the operation's conventions.
The client and server frameworks take care of serialization, transfer and deserialization.

Each operation can also provide a result.
This is one way to provide a client with requested data.
Of course the result can be skipped, which saves traffic.

Operation calls and results are a thing between one client and the server.
The other clients won't know about these.

Events

Photon Events are messages for clients.
Each event is typed by a byte code and carries game updates.
The "LoadBalancing Application" defines several events but it's possible to define custom events purely on the client side.

Unlike operation results, a received event is most likely caused another client's operation call.
This means: Events might arrive anytime. "LoadBalancing Application" sends events when someone joins or leaves a room.

The Operation RaiseEvent makes events truly universal:
Any client can create new events by putting together a hashtable with the data and applying a code on sending it.
Game data can be sent without any need to change the server.

Of course, for more elaborate server side reaction to events, custom operations can be defined which check event data, compile it or create other events.

Connections and Timeouts

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.