Quake 2 Networking model
Hi!
I have a question about quake 2 networking model. Is there some documentation on the architecture of this part of Quake 2 Engine.
Yeah, I could do some reverse engineering, but I would prefer to read some (even blur) description.
The information I am interested in are:
- what data is exchanged
- how does server checks whether the client is not cheating
- how are the clients synchronized (for example taking the same medipack)
- how often are the packets sent
- and even more:)
Thanks for answers.
There is no need to reverse-engineer. Just read the source code. This is not a complete answer, its just something simple to give you ideas. The full answer is complicated :)
- what data is exchanged
C->S: Your intended angle of rotation and intention of movement
S->C: All player information, gamestate, your actual movement
- how does server checks whether the client is not cheating
The server makes sure that the client has a limited speed of movement, clips it if the client goes too far. On some later implementations, BSP culling can be used to only send other player info if the other player is in the same sector (anti-wallhacking strategy). But in reality the original Quake2 cannot protect against aim cheats (because aim is done with fixed angles, not delta movements) and wallhacks. Nor can Counter-Strike, thats why there are so many cheats.
- how are the clients synchronized (for example taking the same medipack)
Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.
- how often are the packets sent
That depends on the 'rate' settings. Depends on server and client configuration.
- and even more :)
Read the source.
- what data is exchanged
C->S: Your intended angle of rotation and intention of movement
S->C: All player information, gamestate, your actual movement
- how does server checks whether the client is not cheating
The server makes sure that the client has a limited speed of movement, clips it if the client goes too far. On some later implementations, BSP culling can be used to only send other player info if the other player is in the same sector (anti-wallhacking strategy). But in reality the original Quake2 cannot protect against aim cheats (because aim is done with fixed angles, not delta movements) and wallhacks. Nor can Counter-Strike, thats why there are so many cheats.
- how are the clients synchronized (for example taking the same medipack)
Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.
- how often are the packets sent
That depends on the 'rate' settings. Depends on server and client configuration.
- and even more :)
Read the source.
Here's an interesting article about the Quake 3 network model. It says (among other things) that Carmack was never really happy with the networking in Quake 2.
It might be worth checking out.
It might be worth checking out.
Konrad,
I'll try to explain some of the answers you are interested in based on what I've learned from my own reverse engineering. Keep in mind this isn't official and is my own interpretation so it is most likely not 100% correct:
Voxelsoft pretty much summed it up in his two lines. The client will send it's keyboard and mouse state as well as it's view angles (I believe) every frame. This data is sent out in the form of an unreliable message (with the exception of a weapon fire (and jumping/crouching) which is sent reliably) each and every client frame. This is the biggest reason that Quake II and Quake III implemented frame caps otherwise you would overrun your max rate and as a result you would lag.
As far as the server is concerned I believe it's every 10 or 20ms a "gamestate" update is sent to the client which will include items such as viewable entities (clients, spawned items, etc.) and "playerstate" updates which will force the local client to the position where the server thinks it is. It will also send out events (which last one frame) such as muzzle flashes, and if a weapon is fired it will inform the client of where it was spawned at what time and it is then up to the client to predict where it will be in it's ping time / 2 from when it was fired.
The server does a number of checks in regards to moves (such as only allowing one more per packet) as well as grants each client a certain # of milliseconds (believe the method is GiveClientMilliseconds()) which is a brief time to allow the client to move. It would take much too long to explain all the checks it does but I'd recommend looking at the main server game loop and browse through it and you should come across most of them.
This is where prediction comes into play which is not perfect but really helps in handling synchronization. Basically since the server keeps track of where all the clients are, if client X hits the medpack just before client Y, the client must wait for the event from the server before picking up the healthpack. The server predicts every frame where things are going and will fire an event to client X informing it that it picked up the healthpack and client Y therefore will not play the pickup animation or have health added etc. I think at this point the client would still predict that someone picked up the medpack and therefore remove it from the world and then wait for the server event saying "yes you picked it up".
Hope this has helped you out somewhat, like I said this is what I've gotten out of analysing the Quake II source so it's probably not 100% correct but should help to get you rolling.
Permafried-
[Edited by - Permafried- on September 15, 2004 11:13:07 AM]
I'll try to explain some of the answers you are interested in based on what I've learned from my own reverse engineering. Keep in mind this isn't official and is my own interpretation so it is most likely not 100% correct:
Quote:
what data is exchanged
Voxelsoft pretty much summed it up in his two lines. The client will send it's keyboard and mouse state as well as it's view angles (I believe) every frame. This data is sent out in the form of an unreliable message (with the exception of a weapon fire (and jumping/crouching) which is sent reliably) each and every client frame. This is the biggest reason that Quake II and Quake III implemented frame caps otherwise you would overrun your max rate and as a result you would lag.
As far as the server is concerned I believe it's every 10 or 20ms a "gamestate" update is sent to the client which will include items such as viewable entities (clients, spawned items, etc.) and "playerstate" updates which will force the local client to the position where the server thinks it is. It will also send out events (which last one frame) such as muzzle flashes, and if a weapon is fired it will inform the client of where it was spawned at what time and it is then up to the client to predict where it will be in it's ping time / 2 from when it was fired.
Quote:
how does server checks whether the client is not cheating
The server does a number of checks in regards to moves (such as only allowing one more per packet) as well as grants each client a certain # of milliseconds (believe the method is GiveClientMilliseconds()) which is a brief time to allow the client to move. It would take much too long to explain all the checks it does but I'd recommend looking at the main server game loop and browse through it and you should come across most of them.
Quote:
how are the clients synchronized (for example taking the same medipack)
This is where prediction comes into play which is not perfect but really helps in handling synchronization. Basically since the server keeps track of where all the clients are, if client X hits the medpack just before client Y, the client must wait for the event from the server before picking up the healthpack. The server predicts every frame where things are going and will fire an event to client X informing it that it picked up the healthpack and client Y therefore will not play the pickup animation or have health added etc. I think at this point the client would still predict that someone picked up the medpack and therefore remove it from the world and then wait for the server event saying "yes you picked it up".
Hope this has helped you out somewhat, like I said this is what I've gotten out of analysing the Quake II source so it's probably not 100% correct but should help to get you rolling.
Permafried-
[Edited by - Permafried- on September 15, 2004 11:13:07 AM]
Quote:Quote:
- how are the clients synchronized (for example taking the same medipack)
Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.
No, I don't think that was the problem the original poster asked. The original poster asked something like:
Suppose there's a medpak. Suppose two players run up to the same medpak, each on their own machine (there's some lag in where the other player is displayed). Only one player can ACTUALLY get the medpak, as it is consumed on "getting". How does Quake II determine which player actually got it?
I don't know how Quake II does it, but the source is available for public download from Id software. The way I would do this is have each client request the medpak, have the server validate the request (are they actually there, and does the medpak actually exist?) and then send out changes in medpak availability (and results of medpak application) to everyone. This means that you don't actually get your HP boost until the server sends you back the result and tells you that you won.
Quote:Original post by hplus0603Quote:Quote:
- how are the clients synchronized (for example taking the same medipack)
Name of media pack is compared, hashes of maps are compared. If not match attempt to download. If download fail, abort.
No, I don't think that was the problem the original poster asked. The original poster asked something like:
Suppose there's a medpak.
GIGO. Also already answered by another poster.
Thanks for all replies.
I already started to analyze the source code, but anyway, they will be very useful in some time.
I already started to analyze the source code, but anyway, they will be very useful in some time.
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....
Quote:Original post by DBX
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....
Pretty straightforward - if A's packets get lost and B's packets don't, then B will be first to take medipack:)
Quote:Original post by MickeyMouseQuote:Original post by DBX
I see how the client knows who picked up the medipack, but how does the server?
Suppose clients A and B both rush to pick it up. A gets there first (according to an observer watching both computers) but their packet to the server is lost....
Pretty straightforward - if A's packets get lost and B's packets don't, then B will be first to take medipack:)
So, basically players with lower pings and better connections get priority? Seems a little unfair.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement