Photon C++ Client API
5.0.7.3
|
Operation is our term for remote procedure calls (RPC) on Photon. This in turn can be described as functions that are implemented on the server-side and called by clients. As any function, they have parameters and return values. The Photon development framework takes care of getting your RPC calls from clients to server (and results back).
Server-side, operations are part of an application running on top of Photon. The default application provided by Exit Games is called "Lite Application" or simply Lite. The LitePeer class extends the PhotonPeer by functions for each of the Lite Operations.
Examples for Lite Operations are "join" and "raise event". On the client-side, they can be found in the LitePeer class as functions: opJoin() and opRaiseEvent(). They can be used right away with the default implementation of Photon and the Lite Application.
Photon is about being extendable with features that are specific to your game. You could persist states in a database or double check information from the clients on the server by implementing functions. If your new functions can be called from the client-side, we call them Custom Operation. Creating those is primarily a server-side task, of course, but the clients have to use new functions / operations of the server.
So Operations are functions that can be called from the client-side. They can have any number of parameters and any name. As you will be calling operations a lot, we avoid using strings and instead assign byte-codes for every operation and each parameter.
This is done server side. Each Operation has its own, unique number to identify it, known as the operation code (opCode). An operation class defines the expected parameters and assigns a parameter code for each. With this definition, the client-side only has to fill in the values and let the server know the opCode of the Operation.
Photon uses instances of OperationRequest and OperationResponse to aggregate the opCode and all parameters. Use opCustom() to send your Hashtable and call any operation.
Client-side, operation codes and parameter codes are of type byte (to minimize overhead). They need to match the definition of the server-side to successfully call your operation.
Currently, the server-side uses the short-type to define opCodes and parameter keys while the client-side uses bytes only. This is a remainder of Neutron, essentially, where we implemented more values of opCodes. But using short for each opCode and parameter is a lot of overhead in a realtime environment, so we decided to revert this in the protocol and just send bytes. This simply saves lots of bandwidth.