Sign in to follow this  

Peer to Peer Multiplayer

This topic is 4752 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

Im new to the network forum so I dont know if this has been brought up before and this kinda crosses over with design but .. oh well. :) The idea is obviously to, rather than a server client model, use a robust peer to peer network to maintain a constant game world. The advantages mean that even if one user drops, the entire system does not necessarily go down (in client server model, if server drops, everyone drops). In addition it is possible to reduce latency for some players depending on the system used to propagate changes in the gamestate. Probably the largest advantage however is that a multiplayer world can be sustained using a number of interconnected clients without the need for a server with a fat connection. This would allow freeware and low budget multiplayer games to maintain constant game worlds (as long as at least one host-capable machine is running) as good servers arent cheap. Depending on the game type however there are some unique problems with this system. For one thing, with a server client model everything happens in "server time", a client will tell the server that it has preformed an action but it does not occur until the server recieves this message. The server is the judge. With a peer to peer system you could either wait for changes to propagate to all clients (latency for everyone is equal to the largest latency on the network), or designate a client as judge. This designation could change as the network changes. Another problem comes from network splitting. If the network is divided into two "supernodes" with each having a lot of clients but the only connection between the two halves being between the supernodes, should that connection be severed both halves will think the others dropped and continue maintaning their own game world effectively forking the game in two. You could solve this again with the designated judge machine. The side that is connected to this machine is the "true" network and any machines that lose connection to it have lost connection to the network and must drop. Another interesting thing to think about is giving each connecting client (node) a piece of the game world or expanding the game world as more nodes connect. Each node is then responsible for maintaining its own area and serves as the judge machine for that area. Should a node drop, it takes down the area of the world which it was assigned. Upon return these areas are reconnected. This provides a way to reconnect split networks. What happens to characters that get the ground dropped from under them this way is something the game designers have to deal with. :) In addition it would take some creative thinking as to how to connect the nodes to make good neighbors (considering relative latency and actual game map geographical concerns). One solution is to give each node a n-by-n tile square and no more and upon connection this square is inserted into the first (or best, latency-wise) available location. An interesting thing that could be done with this is connecting networks which werent connected to begin with. Allowing small games to attach to larger ones. The game genre ends up dictating a lot of the implementation details but I hope I got the general idea across. It seems best fit for some kind of user-driven MMO. Thoughts/Comments?

Share this post


Link to post
Share on other sites
its an interesting idea that has been talked about on the forums before.

my one concern is security. how could you secure such a game? i don't think it would be possible, i mean, if a client is at any one time the "judge" as you say, this client could detect when he is the judge and then start changing variables in memory, effectively making him god. you cant trust anyone except the server, and if you eliminate the server, then who can you trust?

also, don't forget, your still going to need at least a smaller server to run the database. you can't store the world and character information on client machines obviously. so at least one server for this is needed. this is another security issue. will clients directly access the database themself? if so, this is another security problem. if not, then this is more load on the database server.

Share this post


Link to post
Share on other sites
well i think a "weak server" model sounds pretty good. The server is basically there for sync and auth. all though, thats pretty much everything anyways... hrm... its something to think about htats for sure
-Dan

Share this post


Link to post
Share on other sites
There are tons of discussions about this sort of thing if you look around.

Another problem is that peer-to-peer has higher bandwidth requirements on the clients. Each client ends up as basically a mini-server. Instead of sending updates to one machine (the server) you have to send to all the peers you're working with at the moment. In the other direction instead of one big update from the server you get a bunch of little ones from everybody else - more packets means more overhead plus probably lots of redundent information that can't be filtered out.

And of course everybodies favorite p2p problem - NATs and firewalls. In today's Internet, just because you can connect to somebody doesn't mean they can connect to you.

Share this post


Link to post
Share on other sites
Well for the easy part, there are several ways of handling the master server. The ideal way is of course not to have one. This means you must either have at least one 24x7 node with a static IP (or a dynamic DNS hostname) which accepts connections and can transfer a list of other nodes to the connecting client or the old fashioned "heres my ip" way, which would mean no MMO. :) If you do use one, an old fashioned master server which would list ips for all nodes instead of just the server would work.

Now for the tough part, a peer to peer network fundamentally relies on trusting the other client. Like Filla pointed out, especially if its the judge server. There are ways to get around this however. You could use one or more designated trusted nodes which are the only nodes that can be used as judges. You could rely on players vote-kicking cheaters (traditional but not a good solution). The most "peer to peer" solution here is to use majority-rule synchronization checks. If one client reports their character using the Almighty Vorpal Sword of Doom that no other nodes knew about then you either have a sync problem or a cheater. Either way you resync or drop the offending node. This requires nodes to have their neighbor nodes data which would open up the game to client-side hacks giving away more information than the player should know, but it does prevent the nastier gameplay variable modifications.

As for bandwidth limits, NATs, and firewalls the peer to peer system would still work. Its a question of how you connect and assemble your network. You need at least one host machine, which if no other hosts are found will end up a vanilla server-client setup. Each client does not need to be connected to every other client. When a node is connected the network should assemble optimal information flow routes to and from each other node depending on how the network is setup. These can be calculated by testing the bandwidth/latency down every possible path (via the ant trail method for example). Admittedly a bunch of 56kers wont make a very good network no matter how hard they try but with broadband becoming ever more widespread (not to mention college connections) bandwidth may not be such a serious problem. Of course in the end it depends on what youre trying to play. A tick based game for example could afford to wait until every last client is synced before a game frame is taken while a shooter or and RTS cannot.

Share this post


Link to post
Share on other sites
No offence to you, but this is the difference between people who like to talk about P2P systems and those who actually have experience of them and/or better education in the discipline of dist-systems:

Quote:
Original post by Risujin
As for bandwidth limits... Its a question of how you connect and assemble your network. ... When a node is connected the network should assemble optimal information flow routes to and from each other node depending on how the network is setup. These can be calculated by testing the bandwidth/latency down every possible path (via the ant trail method for example). Admittedly a bunch of 56kers wont make a very good network no matter how hard they try but with broadband becoming ever more widespread (not to mention college connections) bandwidth may not be such a serious problem.


I see many plans for P2P systems (often on websites for a P2P system in development but not yet popular enough for them to discover the obvious flaws in their plan) with statements such as:

"and each node is tested for it's b/w and the bigger ones are given higher-level positions within the tree, so we get the big T1's sending the big chunks of data, and everyone only handles what they can manage"

Sadly, in the "real world" (tm) 99% of your players will not have anything more than standard broadband, which means you have zero fat pipes, and so your system doesn't work at all.

For a large dist-system, you need a lot of links with a hell of a lot more b/w than a home broadband system. Perhaps if you have many many players with 2Mbps full duplex DSL you'll have a chance.

So...those of us who suggest people avoid P2P architectures for games often say that b/w is your biggest problem (or security, depending upon the game/application design; one assumes you are smart enough not to even consider P2P unless you have a game-design where security isn't all that important).

Shrug. It's nice to talk about these theoretical P2P systems, but I'd prefer it if people spent more time on real systems and less on talking about ones they cannot build for another decade or so. I have nothing against P2P, except that it's largely useless for any game being written any time in the next 5 years.

Share this post


Link to post
Share on other sites
Quote:
Original post by redmilamber
Sadly, in the "real world" (tm) 99% of your players will not have anything more than standard broadband, which means you have zero fat pipes, and so your system doesn't work at all.


Well I see your point and you're absolutely right. My point however wasnt that you would be able to P2P together a million clients and run EverQuest server-less. :)

Although it kills some of the fun, the kind of network Im describing would really only be usable for games that can accept high latency, namely slower-paced and tick based games. Tick based games for example, are completely immune to latency--you simply wait until everyone is on the same page before updating, whether that be a second or two or half an hour.

Share this post


Link to post
Share on other sites
Quote:
Original post by Risujin
Although it kills some of the fun, the kind of network Im describing would really only be usable for games that can accept high latency, namely slower-paced and tick based games. Tick based games for example, are completely immune to latency--you simply wait until everyone is on the same page before updating, whether that be a second or two or half an hour.


Yup. And altering the game-design to obey the constraints of the real world and get the performance you need within the architectural constraints is a tried and tested approach :). But it's usually just plain easier to go with a better architecture..

Once you get started along this path it can be surprising how far you can get with smoke-and-mirrors, making it look like something much more impressive is happening than truly is happening.

Share this post


Link to post
Share on other sites
It takes alot of thought, but one can design games that can accept HUGE latencies. Such as a game where players themselves dont directly interact, but their missles do. Then as long as the other guy can know about the missle before it hits him, everyone can stay in sync, and that could be a long while in terms of ms.

Or a game where you have to charge up a move before you do it, but you select the move before the charge up sequence happens. That charge up time is free as far as latency goes.

Share this post


Link to post
Share on other sites

This topic is 4752 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