Photon socket Glossary

Photon Overview

Photon is a development framework used to build real-time MMO games and support multiple platforms. As in photon
As described in socket, it includes a server SDK and a client SDK.

Photon provides a low-latency communication layer that selects TCP or UDP as needed to send "commands" in "reliable transmission" and "unreliable transmission" respectively ". These terms are explained in detail in this article. But at the beginning, I hope everyone understands that photon is a framework based on "operations" and "events. This aims to simplify the cost of game system development. Follow-up of this series ArticleWe will illustrate this through a series of examples.

On the server side, each independent ProgramThese are called lite applications ). They have built-in basic "operations" to enable developers to focus more on their business logic rather than the underlying implementation.

The following describes the terms and classes that are often used in development.

Class litepeer

The following describes the most common procedure of running photon from the client workflow. You can understand how a server program creates a "room" and allows users to "join. In "room", each user is an "Actor" with a unique identifier in the room.

• Create an Instance Object of the litepeer class and prepare to call the method of this object in the following steps.
• Call the connect () method to connect to the server and implement iphotonpeerlistener. peerstatuscallback to get the connection status notification. The success status is statuscode. Connect.
• Periodically call the service () method to obtain events and send "commands" (for example, 10 times per second)
• Call opjoin () to join the game. Call operationresult () to get the connection status notification. The successful status is liteopcode. Join.
• Call opraiseevent () to send data to the server
• Obtain server data updates by implementing iphotonpeerlistener. eventaction ().
• Call litepeer. opleave () to exit the game. If operationresult () returns liteopcode. Leave, it indicates that the server has successfully left.
• Call disconnect () to disconnect the connection and get a notification of the connection status through peerstatuscallback (). statuscode. Disconnect indicates that the connection is closed successfully.

Through the above process, we can find that these methods have been introduced into the following three categories:

• Asynchronous Operation:Such as connect (), opjoin (), opraiseevent (), opleave ()
• Asynchronous callback:For example, operationresult () is used to return the result of an asynchronous active operation.It is worth noting that this kind of return usually appears in the form of a question and answer.
• Event:Not sure if it is appropriate, such as peerstatuscallback ().

Level)

The communication between photonserver SDK and client SDK can be divided into three communication layers.

• Communication layer:Services, connect, disconnect, and statuscallback are directly related to the connection status. They correspond to the UDP/TCP Protocols one by one.
• Logic layer:The built-in "operations", "status", and "events" are counted as part of the logic layer. We can distinguish them by method names, such as opjoin, operationresult, and peerstatuscallback.
• Application Layer:The business logic in our own games is usually listed in this layer. For example, we can implement opcustom () to send custom "operations ".

In most cases, we do not have to control the communication layer. However, it makes sense to understand the communication mechanisms between the client and the server.

Interface iphotonpeerlistener

Iphotonpeerlistener is defined to accept server-side events. The following methods need to be implemented.

• Peerstatuscallback:Notifications of connection status changes at the communication layer, such as connect, disconnect, errors, and compare. These statuses are defined in the statuscode enumeration.
• Operationresult:Used to obtain the callback for logical layer operations, such as (join, leave)
• Eventaction:Used to obtain the Event Callback at the application layer
• Debugreturn:Used only during debugging

The following attributes are also worth noting.

• Timepinginterval:Set the ping interval between the client and the server
• Roundtriptime:Specifies the round-trip interval of a "reliable channel. It can be simply understood that when sending data packets in a "reliable channel", the response time in a unit of time is determined by roundtriptime and roundtriptimevariance.
• Roundtriptimevariance:The variance allowed by roundtriptime.
• Servertimeinmilliseconds:Server-side timer, in microseconds.

Operation)

Operation is the term used to describe remote method Call (RPC) on the photon server. That is to say, the operation is implemented on the server, but called on the client. Like all methods, they have parameters and return values. Photon is responsible for processing the call mechanism of operations, but we only need to define and call it.

On the server side, the operation runs on the photon kernel. By default, the server programs provided by exit games (photon Development Company) are called line applications ). The litepeer class inherits from photonpeer and implements all the inherited basic operations.

The most typical examples of these basic operations are join and raise event. On the client, the two operations correspond to the opjoin and opraiseevent methods of the litepeer class. Since they have been implemented by litepeer, you can call them at the application layer with confidence.

Custom operations)

Photon is extensible. For example, in a game program, you may need to persist the status of the game world on the server side, or check whether the information is synchronized on the client side. Therefore, you need to implement some business logic by yourself. All these operations that are not implemented by the built-in are called custom operations. The implementation of these operations is generally the work of the server programmer, and the call of these remote methods and the update of the client is the work of the client programmer.

During custom operations, the number of names and parameters is unrestricted. To save bandwidth, these operation names and parameters are converted into bytecode in binary format. In fact, photon identifies each operation with a unique code, which is called an opcode ).

When a custom operation is called, opcustom () is called on the client. photon sends the data structure of a hash table to call a remote method.

Event)

Unlike an action, an event is notified by exposing the callback method. Events may be sent by the server or other clients.

Generally, the event notification is affected by the operation. For example, if you enter a game room, other clients in the room should be notified. Of course, a custom operation requires a custom event. Most events contain descriptive data about this event, which uses a hash table as the data structure.

Segment (fragmentation)

Data larger than 1 kb will be split into 1 kb message packages, and will be automatically reorganized after being transferred to the point. This means that some commands containing a large amount of data will cause the subsequent command delay. Therefore, Service () is often called ()
Or sendoutgoingcommands () is absolutely necessary. You can check whether the attribute photonpeer. queuedoutgoingcommands is set to zero to see if all the commands in the queue are sent out. You can also check whether "UDP" exists in the debug output.
Package is full ", which sometimes happens.

Unreliable data)

Some data needs to be ensured in real time, but there is no high requirement on its accuracy and loss rate. Such data is called untrusted data. Some data must be accurate, and the sending order must be the order of receipt. Such data is called trusted data. In fact, trusted data is generally based on TCP, rather than UDP. Of course, TCP communication efficiency is significantly lower than UDP, And it is unicast, But UDP can be multicast.

In game programs, we can use these two transmission modes as needed. For example, in FPS games, mobile information can be used as untrusted data because it needs to be updated frequently and can accept certain errors because it can be quickly corrected by subsequent messages, the dialog information must be trusted data, because order errors or message loss are unacceptable.

Channel (channels)

The. NET client already supports multiple channels. This feature allows the client and server to transmit messages in parallel. This means that if we put some commands or events that are particularly prone to latency in an independent channel, it will not cause those data with real-time requirements to wait too long. Of course, you cannot send events across channels.

By default, each photonpeer object instance has two channels, and channel 0 is the default channel used to send operations. If you join the room or leave the room, it is sent through Channel 2. This is done to make the business clearer. In addition to the two, there is actually a backend channel, that is, channel 255, which is used to send network connection and disconnect messages, in this way, we can encapsulate the active and outgoing disconnected networks into one situation.

Channels are also prioritized, and low-number channels are prioritized over UDP. For example, a dialog message may be placed on Channel 1, while a mobile message is placed on channel 0. When the chat message is delayed, mobile messages with higher real-time requirements will not be blocked.

TCP

For example, the flash or Silverlight client does not support the UDP protocol, which means we can only use the TCP protocol as the underlying protocol. This is not the best practice for using photon, but it is the only practice.

In TCP, we cannot use the features of highly efficient transmission and Multicast Of untrusted data. Of course, our business CodeIt can also be much simpler.

Serializable PES ypes)

Since the server SDK 1.8.0 and. Net client 5.6.0, the serializable data types supported by photon have changed significantly. Arraylist (weak type array) is abandoned, while arrays (strong type array) and hashtable are supported. For details, refer to the following list:

• String/string
• Boolean/bool
• Byte/byte (unsigned)
• Int16/short (Signed)
• Int32/INT (Signed)
• Int64/long
• Single/float
• Double/double
• Array (supports the preceding type of strong-type arrays, but the length is limited to short. maxvalue, and the two arrays are not supported. )
• Hashtable (note that hashtable [] is not supported. For a hashtable object, although different types of values can be used as its keys at the same time, it is best not to consider this situation in terms of transmission performance. Once a hashtable key has multiple types, reading the object is split into multiple sub-commands, and each key requires a sub-command .)

Broadcasting Property)

Line applications can be used to maintain data consistency for clients on the server side. players in the same room need to synchronize data from each other. For clients, the entire process may be like reading and writing the object's attributes.

With the built-in multicast options of photon, you can easily implement the multicast attribute function. When the Server property changes, the response event will be triggered to notify all players to update the data, except for the attribute modifier (because this is not required ).

The following method is used to write the attribute back to the server:

• Litepeer. opsetpropertiesofactor
• Litepeer. opsetpropertiesofgame
• Litepeer. opjoin)

The following methods are used to read attributes from the server and cache them locally on the client:

• Opgetpropertiesofactor
• Opgetpropertiesofgame

Note that offline applications do not support attribute deletion or use string with wide characters as the key value of the multicast attribute. Attribute methods (. NET can wrap methods into attributes) are not supported at the moment.