The source of the problem in the design of the FPS game server
: http://www.byteedu.com/thread-20-1-1.html 1.
Traceback
Go to the gameloft written test, there is a question that says:
Ask you to design an FPS (first person shooter), do you want to use TCP or UDP, and explain why.
2. Learning
Here are two articles I found on the Internet, very well written.
When I took the written test at that time, I didn't expect it to be so complete, but probably the idea was the same, so I took it out and learned it again.
1. Notes for online game programmers UDP vs TCP
Author: [email protected]
First link: http://blog.csdn.net/rellikt/archive/2010/08/21/5829020.aspx
In this tutorial, let's start with the most basic network data sending and receiving. In fact, this part is the most basic and simple part that network programmers should do, but if you want to do well in this part, it is relatively skillful and difficult. And if you don't do this part well, the impact it brings in multiplayer battle games is extremely bad.
You may have heard of the concept of ports, and you may also know the concepts of TCP and UDP. When doing network development, the first thing we have to do is to choose the appropriate protocol. Is it TCP, UDP, or a mix of the two? this is a problem.
In fact, your choice should be related to the type of game you need to do. So first of all, if you are doing online game development, from now on, I assume that you are already familiar with some well-known online games, such as COD, Quake, Unreal, CS.
Since we want to talk about the protocol selection of online games, we must first have a deep understanding of various protocols, so it is self-evident which protocol should be selected.
TPC/IP
TCP
TCP is interpreted as Transmission Control Protocol and IP is interpreted as Network Protocol. Together they do most of your day-to-day web work, such as writing emails, viewing web pages, etc.
If you have ever used TCP, then you must know that TCP is a reliable protocol. That is, you first establish a connection between the two machines, and then you start transferring data between the two machines. The transfer process is very similar to file reading and writing. You write at one end and read at the other end.
The TCP protocol is reliable and orderly, which means that TCP is responsible for ensuring that your data can be transmitted to the other end in a complete and orderly manner. TCP transmits data by stream, which means that TCP will be responsible for segmenting, packaging, and transmitting your data.
Finally, remember that TCP transfers are actually as simple as reading and writing files. by rellikt
IP
The abstract and simple concept of the IP protocol is in stark contrast to the complex real implementation of the underlying transport of the IP protocol.
There is no need for any connection concept here, packets are transferred from one computer to another, just like you would pass a note in a classroom. As long as you give a final destination, the packet will naturally go to that terminal, and of course, it will be delivered through many layers of routing in the middle.
You can't be absolutely sure that your bag will eventually reach its destination, you can only hope that it will. If you want to know if the packet has finally arrived, then you have to ask the receiver to reply after receiving it.
In fact, the whole process may be more complicated. Since no machine can predict the complete routing path that the packet can reach the fastest, sometimes the IP protocol will copy the packet and send out multiple copies, and these packets will take different routes. So they will generally arrive at different times as well.
You must understand that the design principle of Internet routing problems is to self-organize paths and self-repair paths. So it's quite exciting when you think about how the bottom layer of the problem is implemented, and of course you can find what you want in the relevant textbook or wiki.
UDP
We already have a method that can transmit data stably like writing a file. If we also want a way to send and receive packets freely, what can we do?
Here we can use UDP. UDP is interpreted as "user datagram protocol". Similar to TCP, it is also based on the IP protocol, but compared to TCP, it only does a thin layer of protocol on the IP protocol.
We can use the UDP protocol to send packets directly to the specified IP and port, such as 1.0.0.127:21 (the local FTP port). This packet will be routed from the sender to the receiver itself, and of course it may be lost halfway.
On the receiving end, we only need to listen to the relevant port. When a packet is sent from any computer (there is no concept of connection here), we get the data of the packet and the IP of the sender of the packet. and port data, the size of the packet sent.
UDP is an unstable and reliable transport protocol, in fact most of the packets will be delivered, but you generally have a packet loss rate of 1% to 5%. You may even find that there are times when you can't even receive a single package. What's wrong with those machines on the routing path, who knows?
Sometimes the order of receiving the packets and the order of sending the packets are different. Maybe you send the packets in the order of 1, 2, 3, 4, and 5. The received packets become the order of 1,3,4,5,2. Of course, most of the time this order is not chaotic. But no one dared to make a guarantee.
UDP can only guarantee you one thing, and that is packet integrity. If you send a 256bytes packet, the other party must also receive a 256bytes packet. He won't just get half a bag or something. Of course, this is actually the only thing UDP can guarantee you. Everything else is up to you to order. by rellikt
TCP vs UDP
We now have to make a choice. Is it better to use UDP to develop games? Or is it better to use TCP?
First, let's list their disadvantages:
TCP：
1. Connection-based protocols.
2. Reliability and seriality of packets are guaranteed.
3. Automatically package your data.
4. Make sure that the packet traffic does not exceed the load limit of your network link.
5. Simple and easy to use, you just need to read and write like a file and everything will be fine.
UDP：
1. There is no concept of connection, if you want, implement it yourself.
2. There is no guarantee of reliability and packet sequence, and packets may be lost, duplicated, or out of sequence.
3. You have to do the packetizing yourself.
4. You have to make sure that you don't get too many packets over the link load limit.
5. You have to deal with packet loss, duplication, and out-of-order situations. If you don't want them to cause trouble to your program, you must implement the code yourself to deal with it.
In this comparison, we should obviously use that TCP protocol. It has all the features we wanted, it's just perfect, isn't it? by rellikt
How TCP really works
Both TCP and UDP are based on the IP protocol, but their essences are indeed completely different . UDP is similar to its underlying IP protocol, but TCP abstracts many things. It makes you feel like reading and writing a file when you use it. In fact, it hides the implementation details of many complex functions from you.
How exactly does it implement these details?
First of all, TCP is a streaming protocol, you write data to the stream bit by bit, and then TCP makes sure they end up at their destination. We must be clear: the TCP protocol is based on the IP protocol, and the IP protocol is based on data packets. Here, TCP actually packages our data stream at the bottom layer. In fact, there are some codes in the TCP protocol that queue our data streams, and then write them into packets in turn. When the packet has written enough data, it will send the packet away.
This will cause some problems, because you can't control the underlying packaging and transmission, so when a small user input data is written into the data stream, TCP may fill up a certain amount of data (such as 100bytes), and then package and send . In this case, the real-time performance will be poor, because maybe you will need these packets to arrive as soon as possible. These small delays may greatly affect your gameplay.
There is actually a TCP_NODELAY option in TCP. After using this option, your data will skip the TCP queue packing process and send it directly.
But even if you use this technique, you'll still run into problems in multiplayer online games.
These problems stem from the mechanism by which TCP implements reliable transport. by rellikt
How does TCP achieve reliable transmission
Basically, TCP takes the data in a stream into packets, sends them over the unreliable IP protocol, and reassembles the packets into a stream at the receiving end.
But what does TCP do when a packet is lost? What does TCP do when packets are duplicated and out of order?
I don't want to go into too much detail here, interested readers can find the details they need on the wiki. Roughly speaking, when TCP finds a packet loss, it will ask the sender to retransmit, the duplicate packets will be discarded, and the out-of-order packets will be sorted. In fact, this is how it ensures the reliability of transmission.
The packet loss handling here is terrible for the game. In TCP, if you find that the packet is lost, you must wait for the sender to retransmit. Before the retransmitted packet arrives, even if there is a new packet, you can only let them wait in the queue and cannot read it. This waiting The time is about 1.5 times the ping value, and 3 times the time if the retransmitted packet is lost again. Assuming your ping value is 125ms, one packet loss will delay about 200ms, and if continuous packet loss is 400ms, this situation is unbearable in most real-time games.
Why you can't choose TCP as the network protocol for game development
From the above discussion, in fact, it is very clear. In games that focus on immediacy, the requirements for latency are very strict, we can lose packets, but if we receive a newer packet than the lost packet, we can completely ignore the lost packet. We only focus on current data.
Here we assume a model of the simplest multiplayer game. For example, in an FPS game, you send the input data (such as advancing, jumping, and firing) to the server each time in the client segment, and then the server sends the player's current position and situation back to the client for display.
In this simplest model, as soon as one packet is lost, everything has to stop and wait for the packet to be re-sent, everything has to stop, you can't move or shoot. By the time this package arrives, you will finally be able to proceed. But maybe you will find that there are still a bunch of packets waiting for retransmission in the queue, so you have to continue to wait, and maybe the retransmission packet you received has lost its timeliness for the game and is completely meaningless. Can you endure such a game?
Unfortunately there is absolutely nothing you can do about this behavior of the TCP protocol . This is the nature of the TCP protocol, that is, it ensures the reliability of the TCP protocol.
We don't need such uncustomizable reliability agreements. We need to customize the processing principles for packet loss by ourselves. This is why we avoid using the TCP protocol when developing games.
Is it possible to mix TCP and UDP protocols?
From the above conclusion, we can clearly know that for some timeliness-related data similar to player operations and player positions, we must not use the TCP protocol. But some data must be guaranteed to be reliable, so can we use the TCP protocol for synchronization?
This idea is very good. We can use UDP protocol for highly instant data such as player operations, and use TCP for highly sequential data such as player AI, data loading, and player dialogue. If you want, you can even create different TCP connections for different AIs, lest the loss of one AI will affect the immediacy of another AI.
It looks like a good idea. But that's just what it looks like. Since both TCP and UDP are based on the IP protocol, they actually interfere with each other at the bottom. I will not discuss the details of interference here. Readers who want to know can read this article . by rellikt
in conclusion
My suggestion is to only use UDP as the network protocol in the game, even if you want to use TCP, you should implement a TCP-like protocol on the basis of UDP. This is also a popular network architecture in modern games.
In the next article I will describe how to implement this architecture. The next article will be more practical, about how to use UDP to send and receive packets. Do please look forward to. by rellikt
2. Some ideas of FPS game server design (FROM high total)
Link: http://blog.csdn.net/sunguangran/article/details/6064256
FPS games, so far I have not really designed. From last year to Shanda and this year to Jinshan, I would like to thank the principal and Jinzhou for giving me many opportunities to communicate and learn from each other with teams inside and outside the company. In addition, I have experience in designing qqtang server, and I gradually understand FPS games. discussion, and the details of which are gradually deepened. Because there is no complete design of FPS games, many ideas may be greatly deviated, just summarize the experience of more than a year.
1. The player's game data forwarding is confirmed by UDP+ application layer? Or UDP+TCP?
qqtang game data forwarding adopts the latter. All game data (moving + picking up props + bubble explosion, etc.) are forwarded through UDP, but for key game data such as picking up props and bubble explosion, it will be forwarded again by tcp. The reason for this design is that if there is only UDP (no confirmation, no retransmission) forwarding, and the UDP packet is lost, it will lead to confusion in the game logic. Never explode etc. If these key data are forwarded by TCP, the reliability is guaranteed, and for the character movement packets, part of the loss will not affect the game logic, so only UDP is used for forwarding, which also reduces the traffic.
The game package of Counter Terrorism Operation 1 is only forwarded by UDP. When I communicated with them in March this year, I didn't quite understand how they ensured the reliability, and I figured it out later. Its forwarding logic should be that mobile packets (packets that allow a certain loss rate) are forwarded through UDP, and there is no confirmation mechanism; game key data packets (such as bullets, gun changes, etc.) are also forwarded through UDP, but these packets are in The application layer has acknowledgment and retransmission mechanisms to ensure reliable transmission of data.
Which way is better, you can refer to qq server and qqgame server:
In 2003, the qq server used the ftcp protocol designed by the company itself, which is a protocol based on UDP that realizes reliable transmission at the application layer. It mainly solved the access volume and efficiency of the select model at that time. At that time, qqgame also adopted the ftcp protocol to increase the load of the qqgame server. But later found out that it is not suitable for use on game server. The reason is that qqgame has more than 20K large packets, and the ftcp protocol requires us to split it into more than n small packets to send. The loss of each small packet will cause the reception of the entire large packet to fail. Using the ftcp protocol can increase the amount of access, but the quality of service of a single user is degraded. In the end, we still used the select model (it was changed to the epoll model after half a year, which greatly improved the access volume).
The anti-terrorism model (UDP+UDP application layer confirmation) and qqtang server (UDP+TCP), these two models, I recommend using the former.
1) No large packets appear during the fps game.
2) Unified use of udp, simple design and consistent logic.
3) The traffic is smaller, FPS games have high requirements for network delay, the packet loss rate of UDP is not high, and all key packets are forwarded and waste a lot of traffic.
Second, the P2P model? Or the C/S model?
Games like qqtang, Bubble Hall, Bubble Kart or CF were designed in a P2P way a few years ago. I remember that in 2004, the cost of bandwidth seemed to be 30W/G per month. The current cost seems to be only 1/6-1/3, and the cost will continue to decline in the future.
According to my previous statistics, the P2P connection rate of qqtang is about 70%, and about 70% of the traffic is transmitted through P2P, which reduces the cost of operators. However, the trend of the entire Internet environment is not recommended for P2P. Another important thing is that the P2P method makes the program design very complicated, which is a relatively big bottleneck for the team, especially the entrepreneurial team, and also makes it difficult to design the anti-plugging mechanism of the server. , the intercommunication of players and players' game data makes it difficult for the server to participate in it to control.
qqtang is a p2p model, cf and anti-terrorism are both c/s models. From personal experience, unless you are very experienced in p2p, it may be more appropriate to use the cs model.
3. Separation of lobby server and game server
The lobby and games of qqtang server are on a physical and logical server. The lobby server of crossfire is centralized in the IDC room, and the game logic server is distributed in the CDN. After the player opens the room and enters the game state, they will log in to the game server to play the game. This method of accessing nearby is very successful in the operation of crossfire, which solves the problem that FPS has high requirements for network delay.
Counter-Terrorism Operation 1 does not do as crossfire in the distribution of servers. Most players play well, and a small number of players react a little bit. Fortunately, Anti-Terrorist Action 2 will solve this problem. All aspects of Anti-Terrorism Action 2 have been greatly optimized, and I believe it will perform better.
Because FPS games have very high network requirements, they adopt the method of regional and nearby access. This is very different from mmog, and it is also the guarantee of FPS operation quality.
4. Whether the player status is forwarded immediately or status synchronization
Jinzhou’s previous design of Vitality Storm adopted the latter scheme, broadcasting the player’s status every 50ms, and the player’s 2 behaviors within 50ms, such as changing 2 guns, will only record the subsequent status. This will lead to
1) Video playback is not easy to do, because there is no complete behavior process,
2) The state forwarding of 50ms will not be very accurate, the delay is uncertain, and the synchronization thread and the main logic thread also have synchronization problems, which will increase the delay for no reason.
3) The traffic increases, and each state synchronization will synchronize some data that has not changed.
qqtang uses the former, and the program design is relatively complicated; but the message delay is lower, and the event logic of the game world is recorded.
5. Server walking simulation?
The basis of the server walking simulation is to use the cs model. Jinzhou has tested it with the unreal solution before. If the server does the walking simulation, it can solve the problem of anti-plug-in very well, but the overhead is too high, and the computational load such as physical collision is too large. ; Similar attempts have also been made in qqtang. When I took over qqtang, I still had the code for server walking simulation, and finally found that the cpu overhead was too large and cancelled.
The continuous development of server hardware may make server walking simulation feasible. If feasible, the anti-plug-in of fps games will naturally form a natural barrier.
6. Player damage judgment and anti-plug-in
Because the server calculates the collision cost too much, the player damage and other behaviors are mainly realized by the mutual verification between players, in addition to the server doing certain checks. In games with high network requirements, generally we are based on the principle of serving players with better network speed, so it is a relatively difficult task to prevent plug-ins in fps games. Just like the previous qqtang, the client has undertaken too much In order to ensure a good user sense at the same time, it is necessary to add more anti-plug-in considerations to the game logic. qqtang mainly adopts schemes such as scanning feature code and dynamic code execution.
Unreal has formed a relatively complete solution in fps, which has been verified in Counter-Terrorism 1. The development threshold is low and the efficiency is acceptable. Maybe future fps games can use ready-made solutions. Developers only need to complete the main frame and in-game detail logic.
I haven't fully developed a fps game, these are just a summary of some ideas.
Reprinted in: https://www.cnblogs.com/yourwit/p/11557855.html