Sign in to follow this  

P2P game networking?

This topic is 3485 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Would P2P networking as well as client/server combination networking be any kind of feasible idea? Would combining the two reduce the load on upload bandwidth for the server(s)? How would this work? What would the data streams look like? If it's not feasible, just ignore any other questions :P (pressed post twice, sorry. this is the good one :P)

Share this post


Link to post
Share on other sites
Generally p2p for games isn't practical, even if you ignore issues like cheating or any other intentional attempt by a user to break the game you just have a organizational nightmare in trying to figure out what information goes to what player while having reasonable latency and keeping key information synchronized.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kaze
Generally p2p for games isn't practical, even if you ignore issues like cheating or any other intentional attempt by a user to break the game you just have a organizational nightmare in trying to figure out what information goes to what player while having reasonable latency and keeping key information synchronized.
I'm sorry but this statement just isn't true. P2P for games is sometimes a necessity. P2P features half the latency of client / server, and also uses less upstream bandwidth for the host meaning that even average users can host games. The price you pay is that everyone uses more upstream bandwidth (same data sent to every peer), so you have to be really careful and compress your data. Figuring out what information goes to what player is really simple .. All information goes to everyone, it's pretty much that simple.

Logically it doesn't make sense that you would mix client / server with P2P. In client / server the peers don't speak to each other, just the host. In P2P the peers all speak to each other, but there's nothing stopping those peers delegating certain tasks to the host.

I hope this helps, and good luck!

Share this post


Link to post
Share on other sites
For a well connected server, the notion that P2P features half the latency is not true. Supposing the server is in California, I'm on DSL in California, and you are on cable in Texas. Also suppose the server is well connected to the Internet backbones. In that case, the path from "internet" to server is on the order of a millisecond in latency; compare to the path over DSL or cable, which is at least 10 milliseconds each, and the transmission latency from California to Texas.

Even if we both were in California, the addition of the well-connected server doesn't add that much, because a large part of the delay is on our "last mile" connections.

Meanwhile, if the server is in California, but we are both in Texas, the server starts getting in the way. That is, of course, assuming you can get around the problems with P2P cheating. Else the server is still necessary.



That being said, the "VAST" P2P MMO project is moving towards using P2P as a server acceleration or peer aggregation mechanism, instead of as a fully distributed system.

Share this post


Link to post
Share on other sites
In cases where client A and client B do not benefit from screwing with each other (ie are on the same time or are not enemies), I could see benefits from a p2p system. Instead of the server notifying A that B moved, B just notifies A directly which, as both TheGlib and hplus pointed out, could be faster or slower, but either way it does mean the server does not have to spit that message out, thus slightly reducing the work done by the server. If B misinforms A about their state, this often wouldn't have any beneficial advantage. In the case of a team-oriented game, it'll most likely result in a disadvantage since A is no longer sure what or where B actually is.

But then you also introduce a whole new world of technical issues. Does the peer have enough bandwidth to keep everyone in interest in sync? Is their ping low enough to prevent themselves from looking incredibly laggy with other players? Is the connection correctly established and functional? Yada yada yada.

There is a good chance that, because of the limitation of how much you can actually push on each client's network I/O and that client<->client interaction is completely insecure, the amount of work the server is doing is going to be more than you hoped. The cost of time and complexity will probably have quite a huge toll, too.

I think this would be a fun one to play around with FOR THEORY. I would not recommend to anyone to try this out for a real-world implementation for a game they actually want to get done and working.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
For a well connected server, the notion that P2P features half the latency is not true. Supposing the server is in California, I'm on DSL in California, and you are on cable in Texas. Also suppose the server is well connected to the Internet backbones. In that case, the path from "internet" to server is on the order of a millisecond in latency; compare to the path over DSL or cable, which is at least 10 milliseconds each, and the transmission latency from California to Texas.

Even if we both were in California, the addition of the well-connected server doesn't add that much, because a large part of the delay is on our "last mile" connections.

Meanwhile, if the server is in California, but we are both in Texas, the server starts getting in the way. That is, of course, assuming you can get around the problems with P2P cheating. Else the server is still necessary.
I dont know about you but to me the obvious solution is to ping the host and trust that the player will join a session with a good connection (read: force the player to join a good session). In this case a P2P network architecture effectively halves the RTT to get a message to a player and receive a response from that player, assuming you don't have the super dooper network server costing upwards of several thousands. I'm talking here about your average home user, with a rubbish consumer broadband connection, hosting a game so him and all his mates can play their favourite 'twitch' game online - FPS, racing, sports, anything that requires reflex actions. In this scenario the ping to a peer may be on average ~50ms, but under a client-server architecture the RTT might be ~100ms.

I think games like TF2, CSS .. Anything based on a Quake III Arena style client / server network architecture has popularised the use of client / server. Truth be known the single biggest benefit is probably that you can have many more peers with consumer broadband playing on a server at once because the bandwidth requirements more accurately match their connection capabilities (ie: low upstream bandwidth, high downstream bandwidth). Who would care about one of those games if the maximum number of players was capped at 16? (hint: there was in fact a big AAA game that came out not that long ago with similar restrictions and it got slated for it .. do you remember it? Doom 3) Even the latest games suffer from lag, then the gamers often experience issues related to the workarounds necessary to compensate for the extra latency and commonly associate it with cheating (ref: Source Multiplayer Networking)

Quote:
Original post by Spodi
In cases where client A and client B do not benefit from screwing with each other (ie are on the same time or are not enemies), I could see benefits from a p2p system. Instead of the server notifying A that B moved, B just notifies A directly which, as both TheGlib and hplus pointed out, could be faster or slower, but either way it does mean the server does not have to spit that message out, thus slightly reducing the work done by the server. If B misinforms A about their state, this often wouldn't have any beneficial advantage. In the case of a team-oriented game, it'll most likely result in a disadvantage since A is no longer sure what or where B actually is.

But then you also introduce a whole new world of technical issues. Does the peer have enough bandwidth to keep everyone in interest in sync? Is their ping low enough to prevent themselves from looking incredibly laggy with other players? Is the connection correctly established and functional? Yada yada yada.

There is a good chance that, because of the limitation of how much you can actually push on each client's network I/O and that client<->client interaction is completely insecure, the amount of work the server is doing is going to be more than you hoped. The cost of time and complexity will probably have quite a huge toll, too.

I think this would be a fun one to play around with FOR THEORY. I would not recommend to anyone to try this out for a real-world implementation for a game they actually want to get done and working.
In the situation you describe I'm not sure how player B could misinform player A about his state. The usual issues of lag / latency are persistent in p2p or client/server, you just have to work with them.

The issue of peer bandwidth however is a valid one. It's not uncommon to compress your data enough so that in a worst case scenario you are never using more than 64Kbps upstream bandwidth to ensure you capture the majority broadband network users. In practise this is not difficult, it becomes more difficult when you introduce voice chat though.

The issue of establishing connections to peers is relatively simple too. Before a player is allowed to join the session he has to establish a connection to all his peers. Once he's done that he is allowed in, if he cannot establish the connections then he is not allowed in. It sounds more difficult than it really is.

The fact is that you can make life for a hacker more difficult without too much trouble. Encryption and randomised sequence numbers will stop the majority hackers, but even client / server network games are potentially exposed. I see hacks for counterstrike source all over the place - you just can't beat the hackers either way. All you can do is plug the holes as they become exposed.

I think P2P is very much a reality for games. If you've ever played Halo3 (You know, that little game for Xbox 360), you'll know it's a reality because that's P2P ("P2P technology is key to the whole experience," - See-Mong Tan, Microsoft's director for P2P networking). Microsoft have strict bandwidth limitations in place for developers (to ensure end-users have a consistent, high quality experience), and those limitations often mean you can't use client / server because it would use too much bandwidth on the host.

The company I work for has released triple A titles for all the major console platforms with networking based on a P2P network architecture. It works, we all know how to use it, you just need to be careful.

[Edited by - TheGilb on May 27, 2008 11:15:09 AM]

Share this post


Link to post
Share on other sites
P2p network are comming into forefront now, the tranditonal server/client arch. is being more blurred with p2p tech. This is esp. true for console games, which are protected hardware, it solves one of the major problems with p2p networks, peer integreity.

I'm surprised we don't have 100+ player console FPS games yet, it's not beyond reason to use a p2p network to achive that.

There was a long thread about open p2p mmos a while back, the biggest problem with all the impl. was peer security. That's pretty much impossible on the PCs but the conosles are another matter. It should be possible to deploy a pure serverless p2p mmo on the consoles, data storage being redundantly distrbuted, even new content can be stored this way.

With the new open sdk for the consoles (XNA), it would be possible for even an indie developer to develope this.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
The issue of establishing connections to peers is relatively simple too. Before a player is allowed to join the session he has to establish a connection to all his peers. Once he's done that he is allowed in, if he cannot establish the connections then he is not allowed in. It sounds more difficult than it really is.

Well I wouldnt underrate this difficulty, hosts of dedicated servers know they have to setup port forwarding etc in preperation. In a p2p system, every player has to setup portforward or the system has to use some kind of NAT, which isn't guaranteed.
Quote:

The fact is that you can make life for a hacker more difficult without too much trouble. Encryption and randomised sequence numbers will stop the majority hackers, but even client / server network games are potentially exposed. I see hacks for counterstrike source all over the place - you just can't beat the hackers either way. All you can do is plug the holes as they become exposed.

I'm not saying that you can't encrypt the traffic, but just wanted to point out your comparison using counterstrike isn't fair as all the hacks (i've seen) for counterstrike aren't based on network hacking but on directx injections etc. Using p2p does theoretically make the system less secure as all players have to know the IP addresses of everyone else which can lead to players sending malformed game packets to each other.


That said, I think P2P is the way to go as a scalable solution as long as you dont make out the upload stream, and can reduce syncronisation issues (which CAN be more of a problem, as neutral physics objects all have to be updated and due to varying timesteps, different hardware etc they will go out of sync.)

Share this post


Link to post
Share on other sites
Quote:
In this case a P2P network architecture effectively halves the RTT to get a message to a player and receive a response from that player


I'm talking about a co-located server, which sits near the backbone.



The time to transmit from client A to client B directly is 90 ms.

The time to transmit from client A to the server, on to client B, is 94 ms, plus processing delay.

When it comes to large-scale distributed systems, the cost of putting servers in a backbone connected co-location facility is marginal compared to all the engineering, service, production and other costs involved.

Share this post


Link to post
Share on other sites

This topic is 3485 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this