By implementing peer to peer connections between clients in a client-server network model I should be able to increase the prediction fidelity as this theoretically would provide the client with other clients commands for a given tick earlier than it would receive the servers game states for the same tick.

One problem I can think of is that clients would have to be able to interpret other clients commands (usually they just have to listen for game states, not commands). This would be a little bit like an RTS model I guess. This should be solvable without any negative effects on gameplay.

Another problem is that clients could cheat by sending fake data to their peers when it is beneficial to them. This can be mitigated by having the client aware of the real commands through the server and have them immediately stop listening to any clients that fed it false data. This should therefore be solvable with different degrees of negative effect on gameplay depending on the design of the game and how impactful a few ticks of wrong command info is at the worst possible moment.

(Unfortunately, you can't have the server punish any client because it has no idea who's lying, it can only help clients themselves understand if they are being lied to by providing them with correct data).

Am I correct in assuming that this would increase prediction fidelity or is there something I'm not accounting for? The idea is that this allows the client access to some information about the other clients faster than in a traditional non peer to peer model where it would base predictions solely on its own commands.


1 Answer 1


I'm not aware of this ever being used, and I suspect it's because it has very limited benefit for greatly increased complexity and bandwidth use. It might make an interesting experiment, but it seems impractical.

Consider that to support such a scheme, and assuming that most traffic is generated from player actions, you would need to double the downstream traffic and multiply the upstream traffic for all clients, not to mention opening a large amount of new connections. Double downstream because now you are receiving player commands from the peers as well as the server. Multiple upstream because clients need to send their commands to all peers as well as the server.

But perhaps the biggest cost is that you run into tricky situations when you now have three points of reference. With a traditional client-server architecture, there are two: the client and the server (technically the other clients have their own points of reference but the server multiplexes them into a consistent, single one using techniques under the latency compensation umbrella). Now you have three (or more): client, server, and peer. Consider this scenario:

  • Peer tells you that they shot and killed you
  • Server later says that you weren't shot (maybe the peer->server shot packet was dropped)

What happens on your client? Do you momentarily die and revive? Do you ignore the peer's input altogether (then what's the point of having p2p)? I'm sure you can come up with many more edge cases like this.

Finally consider the limited benefit of such a scheme. It might be a boon if you and your friends are all geographically close (say, you're all in Nauru) but the nearest hosting server mandated by Modern FPS 2015 is in US West. You will have a horrible time playing each other, so p2p will make things a lot better and the server turns into a glorified command validator. In practice, such a situation is rare, as most peers will not be significantly closer to you than the server.

  • \$\begingroup\$ Good points. Some things that could reduce the issues you've mentioned: - Upstream traffic: The client only needs to send information to peers that are relevant. The server can tell the client when other entities become relevant and not relevant to it. This at least reduces the pressure. - Discrepancy between server and peer information: First off, the peers would only tell you that they took the shot, not that you were actually shot. Depending on travel time of bullets etc. this is more or less of an issue. There would probably be some events where the client simply only trusts the server. \$\endgroup\$
    – Willem
    Aug 27, 2014 at 11:47
  • \$\begingroup\$ - Limited benefit: Even when the peers are as far away as the server, it does save the round trip so it's twice as quick. I.e. 100ms to server and 100ms to peer. Then to get the info from the server, it actually takes 200ms because it takes 100ms from peer to server and 100ms from server to your client. While it only takes 100ms from peer to you. You effectively cut lag in half, right? \$\endgroup\$
    – Willem
    Aug 27, 2014 at 11:49
  • \$\begingroup\$ Also, what happens when a packet of command info is dropped in a server-client network model? I feel like Counter-Strike and other games that employs this architecture seem to have some kind of redundancy? Could it be that they keep telling the server what they did in old ticks to ensure that some commands get through regardless of individual packet loss? \$\endgroup\$
    – Willem
    Aug 27, 2014 at 11:54
  • \$\begingroup\$ The Source engine delays each update in the client by up to 100ms so that dropped packets can be interpolated. \$\endgroup\$
    – Jephir
    Aug 27, 2014 at 16:07
  • \$\begingroup\$ But what if a packet that contains "fire AWP" doesn't reach the server? The user only tapped his fire button for one tick, so that message should be lost forever? The gun didn't go off according to the server? \$\endgroup\$
    – Willem
    Aug 27, 2014 at 16:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .