6.1How to conserve the communication traffic

It is highly suggested for developer to find out ways to conserve the communication traffic between hosts as much as possible.

Data Quantization helps in reducing the size of one message.

Dead Reckoning helps in reducing the number of exchanged messages.

If there are any unnecessary messages then it is better not to exchange them at all. For instance, let's say there is a quest that gamer can see. Rather than showing the entire string of quest, it is much more efficient to show the resource already saved in the game client.

6.2Optimizing multicast

The operation of Sending one same message to several hosts at one time is called multicast. We recommend optimizing multicast as followed as using ProudNet.

The basics of multicast optimization

When multicasting with RMI, it is much efficient to send a message to several hosts simultaneously by single call of RMI. How to send a message simultaneously is guided in 22. Sending a message.

Saving costs from MMO server multicast MMO

One of huge fees that developer has to pay as maintaining MMO game server is the speed of line where the server is running (i.e. IDC).

ProudNet has functions as followed which could save your cost in this field.

The effects of using below functions are introduced in the Nettention company website ( http://www.nettention.com).

Multicast of NPC simulation result

Generally simulation of NPC (Non Player Character) is run from server. You can Multicast the result of NPC simulation to clients, which can be transmitted via P2P connection of each client. More details are in 13. Routed multicasting several clients from server.

Multicast of PC (Player character) simulation result

Unlike NPC, the simulation of Player Character is run from each client. The client sends the position of PC, moving speed and etc. to the server which Multicast those information to clients near PC.

However, the processing of P2P creation, deletion, addition of member, and removal of member in ProudNet are remarkably fast. Taking a leverage on this, you can multicast position of PC without going through server and directly transmit it to other clients within the sight range of PC by P2P communication.

Here are the key methods.

• Form a P2P group with all clients within the sight range of PC at a fixed time.

• Each client sends simulated PC's position, moving speed and etc. to all clients within the same P2P group.

• Based on the information that server has received, it constantly create a P2P, delete a P2P, add a member, or remove a member.

• Client updates the position of PC based on the received information.

6.3Operating System (OS) of Game Server

동시접속자수가 100 이하인 경우에는 게임 서버의 운영체제로 무엇을 사용하던지 상관없습니다. 하지만 동시접속자수가 그 이상을 넘어가는 경우 게임 서버의 운영체제는 서버 전용 운영체제를 쓰는 것이 성능상 큰 이익을 봅니다.

ProudNet이 지원하는 서버 전용 운영체제는 Windows 2003 Server 혹은 이후 버전입니다. Linux도 지원하며, CentOS 6, Ubuntu 12 이상에서 테스트되었습니다.

6.4Method of using Server UDP Port

When client is connected to server then 1 TCP port will be appointed, which is nothing extraordinary since all TCP application programs are in this way.

However, ProudNet uses 1 UDP port for connecting with client. (If client can't use UDP port at default, then it uses TCP port instead.)

At that moment, Proud.CNetServer classifies the appointment policy of UDP port for each client connection.

• Appoint all clients with each different UDP port.

• Appoint all clients with already specified number of UDP ports.

The first is called per-client assign mode and the latter is called static assign mode.

At per-client assign mode, every client connecting to server will be appointed with each different UDP port. In this case, UDP port value will be used from one of UDP port numbers that server uses. If all of UDP port numbers are in use and more clients connect to server then random port numbers will be issued for them.

In static assign mode, there will be no case where another UDP port will be used than the list of UDP port numbers that server uses. And client connecting to that server will be appointed with one of UDP port numbers that server will use. This means, more than 2 clients will share the same UDP port in the manner of not affecting the flow of messages that could come from several clients on the same UDP port.

In general, per-client assign mode is better than static assign mode in performance-wise

• When there are lot of clients in static assign mode, the relatively small numbers of UDP sockets must handle the excessive amount of client messages, which most likely to cause packet loss when the amount of internal buffers run short.

• But if you prepare too many UDP sockets from the beginning then it could cause overloads in server and significantly increase the usage rate of memory and CPU.

• Static assign mode is weak against ICMP host unreachable packet. So it has to be 3.2 Firewall setup for ICMP related.

Unless it is inevitable, we recommend you to use per-client assign mode which doesn't have disadvantages listed above.

But there are some catches in using per-client assign mode. If the number of client trying to connect to server exceeds the number of UDP port that server will use, then they will be appointed with random ports, which coincidently match with numbers not permitted by firewall of that server. When this happens, the UDP communication may not perform appropriately.

Some server firewalls have a feature that allows the use of port as long as data is outbound packet. By using this, you can secure the performance of communication safely as using per-client assign mode although there are unpermitted UDP ports for use. For more details, please refer to 3.1 Firewall setup to defend DDOS attack.

To decide which server will use which assign mode, you need to set Proud.CStartServerParameter.m_udpAssignMode when Proud.CNetServer.Start is called. And you can set the list of UDP ports that server will use from Proud.CStartServerParameter.m_udpPorts.

Summarizing everything mentioned above, the recommended ways to set assign mode, the length of UDP port list and firewall as using ProudNet are as followed.

6.5Setting the number of threads in thread pool of server

At the startup of server(Proud.CNetServer.Start), you can assign the number of threads of Thread pool.

The role and function of server varies upon how many server processes are running and how many threads are created in the server computer.

Here are the typical guides.

• First, let's assume the number of threads is equal to the number of CPUs in server.

• If the server that uses ProudNet takes device burst time instead of CPU burst time ten it will increase the number of thread. (Refer to 6.7 Understanding burst time) The case where game server most typically takes device burst time is when it accesses user database.

• If the logic of game server is structured in simultaneous accessing from multi-threads, it is ok to let the server computer run just one of game server processes. But if it is protected by critical section or mutex to run from single thread, then it is wise to launch up several game server processes.

6.6Speed-hack detection and performance of the server

17. Speed-hack Detection causes a specific amount of traffic between client and server, and traffic increases in proportion to the number of clients connected to the server.

In case of just client connection to the server PC with 4 GB of Xeon E312XX (Sandy Bridge) memory.

If not using 17. Speed-hack Detection, 0~3% of CPU usage is measured.

If using 17. Speed-hack Detection, 25~35% of CPU usage is measured.

Therefore, it is recommended to deactivate Speed-hack detection unless it is absolutely necessary. (Use of Proud.CNetServer.EnableSpeedHackDetector)

6.7Understanding burst time

Burst time can be categorized as CPU burst time and device burst time.

• CPU burst time is the pure calculation time of CPU as executing a specific routine. In another words, the core usage rate of CPU during CPU burst time is 100%.

• Device burst time is the standby time of CPU waiting for completion of other operation as executing a specific routine. Which means the core usage rate of CPU during device burst time is 0%. The cases where CPU waits for other operations to complete are when file is being read/written, DB query is running, or simply putting itself on standby for service response of another host.

When developing a game server, there is a few things that you need to be careful is device burst time is long.

• It is better to unlock mutex or critical section protecting the local memory of game server during device burst time. If they are locked, device burst time may not perform properly and take longer that would appear as a severe lag.

6.8Optimizing transmission operation routine

One of factors that negatively affects the server performance is routines take long to operate transmission.

In the case like this, it is important to search for transmission operation routines with lack of performance through 16.2 Approaching the moment of reception (Stub) call and solve them.

Then you need to determine the slow routines are in either device burst time or CPU burst time.

• If device burst time is taking long, you need to optimize critical section lock and increase the performance of source in device burst (i.e. database or else).

• If CPU burst time is taking long, then the calculation routine must be optimized, switch to parallel processing, or distribute to a different server. The typical example for this is AI of NPC.

6.9Performance difference between Direct P2P and relay communication

As explained in 6. Overview of peer-to-peer communication between clients, peer-to-peer communication between hosts is based in 2 different methods, Direct P2P or relay communication.

Generally speaking, the latency of P2P communication two times larger than that of relay communication. Especially when the server is physically far away (for instance, if the server is located further than 3,000 kilometers), the gab will grow larger and larger.

Therefore, it is suggested to consider as followed.

• How to reduce the total number of P2P messaging(RMI call) in relay communication : With Proud.CNetClient.GetPeerInfo, you can find out whether or not you are in Direct P2P communication with another client who will receive RMI call. For instance, if you are in relay communication then you can reduce the number of RMI call for your character position from 8 times per second to 4 times per second.

But there is an advantage in using relay communication too. When there are many of P2P group members, it will cause excessive amount of uploads if client passes RMI to that P2P group. For solution to this, refer to Proud.RmiContext.m_maxDirectP2PMulticastCount or 11.2 Transmitting the latest message only.

6.10How to choose the right protocol for your project

As guided in 3. Protocol type of ProudNet, ProudNet supports reliable, Reliable messaging. From here and on, you can find useful tips for which messaging you should use.

First, you should send all messages by reliable messaging at the initial phase of your game developmen. (Use Proud.RmiContext.ReliableSend)

Then you should collect the contents of RMI message transmission as referring to 16. Approaching the moment of every RMI call .

In a normal game programming, the less than 20% of all defined RMI message types takes up 80% or more of the entire amount of RMI message transmission when you analyze the collected contents. Among these, there should be RMIs care less about data loss of 20% or below. A RMI transmitting the position of character 5 times per second would be a good example for this. ,

Through this process, you can edit your program as searching for RMIs with high transmission rate but can live with the loss then have them all use Reliable messaging.

6.11Detecting transmission overflows

Detecting transmission overflow from each hosts

ProudNet internally has Send Queue. When the amount of data exceeds more than what the network line and speed can handle, Send Queue puts the data on standby on memory until the transmission is complete.

If the communication traffic is excessive, you can mitigate it by using 11. Traffic auto-control function (Throttling). Also, you can prevent the overflow by measuring the amount of traffic since the number of Send Queue will increase equivalent to the amount of traffic.

Here are the methods of measuring Send Queue.

• Proud.CNetServer.GetClientInfo

• Proud.CNetClient.GetPeerInfo

And use Proud.CNetPeerInfo.m_sendQueuedAmountInBytes.

Detecting transmission overflows for each RMI type

Event callback Proud.IRmiProxy.NotifySendByProxy that is occurring when you call RMI has parameter Proud.MessageSummary You can measure traffic from RMI with it.