P2P multiplayer on a massive scale.
Arena Net has a good article concerning P2P. And its actually been used before in "school project" type MMOs (look for a guy named Wei Xu, he's a guy from UPenn who's been in some groups that have dealt with implementing it). Speed, breaking up the server tasks, etc. are easy to implement (everyone pretty much becomes a mini server dealing with their own character). The hard part is cheating. The best solution I've seen are the ones similar to Guild Wars, you only play with the people you want, certain data is server centric while others are not, etc.
Author
What if each server checked itself, say with a hash (to check crucial data and binaries) and then verified it with the central peer tracker?
Quote:Original post by Grizwald
What if each server checked itself, say with a hash (to check crucial data and binaries) and then verified it with the central peer tracker?
Checking your own binaries won't work - what prevents you from sending fake hash?
I myself gave thoughts to that idea some time ago. Superpig posted something similar one or two months ago in his journal, those interested can check it out.
One important point which i haven't seen mentionned, is (in addition to the problems already reported) that this P2P solution will not automagically reduce your bandwidth costs to zero.
Think about it:
1. Not all players are equal faced to bandwidth (56k anybody?).
2. The upload bandwidth of a player is generally very low compared to the download one. You might have an ADSL connection of 4 MBits+ download, but if your upload is limited to 256 KBits, the limiting factor will be this last one.
3. As such, this P2P model only works when you can find some groups of players, where all players in a group have good connection conditions.
4. And obviously, since the server is out of most transactions, the latency between the players become an important parameter. What if 3 players are interacting; two of them have a good latency (50 ms), but the latency to the third one is very high (350 ms) ?
So, you need to design your system to support extremely diverse bandwidth/latency combinations. If you thought it was hard with a centralized server, expect some real troubles now.
Yet, i do believe it can be done, and reduce a lot the bandwidth required by the server. I might try to implement it in the more or less distant future.
Y.
One important point which i haven't seen mentionned, is (in addition to the problems already reported) that this P2P solution will not automagically reduce your bandwidth costs to zero.
Think about it:
1. Not all players are equal faced to bandwidth (56k anybody?).
2. The upload bandwidth of a player is generally very low compared to the download one. You might have an ADSL connection of 4 MBits+ download, but if your upload is limited to 256 KBits, the limiting factor will be this last one.
3. As such, this P2P model only works when you can find some groups of players, where all players in a group have good connection conditions.
4. And obviously, since the server is out of most transactions, the latency between the players become an important parameter. What if 3 players are interacting; two of them have a good latency (50 ms), but the latency to the third one is very high (350 ms) ?
So, you need to design your system to support extremely diverse bandwidth/latency combinations. If you thought it was hard with a centralized server, expect some real troubles now.
Yet, i do believe it can be done, and reduce a lot the bandwidth required by the server. I might try to implement it in the more or less distant future.
Y.
Quote:Original post by FlowingOoze
How about some kind of random auditing to catch cheating. Each peer could at any time query the state of another peer and all of the transactions (ie. trading items with other peer and such) made by that peer. This would be done in a random fashion and cross checked against data from other peer for consistency. This would be best done by a server, but the load would be small. Potential cheaters would then get flagged and could be examined more closely.
If for example peer A is queried and claims to have gotten a Sword +10 from peer B, but B doesn't say that he gave a Sword +10 to A, then A is likely to be a cheater. This wouldn't really work for cheats that just enhance abilities, like speeding up movement.
Then all you need to defeat this system is for both A and B to be cheating.
Just a few ideas from ym thoughts on this:
1) When splitting up tasks, do so at a very fine grained level. For example, a client should not be "Inventory for 1000 Players"; ;instead it could be "Iventory for 10 players, commerce for the bar in Nagshead, and player movement on Acre G-43". That way any single player has difficulty doing large scale cheats because the client has control over only a small bit of data.
2) Never give a client control of its own player's data. Very obvious, but it instantly makes it much more difficult to cheat.
3) Distrtribute copies of the same data to IPs that appear to be geologically seperated. Although these IPs don't give location precisely away, it should allow you to put one copy of the data in Texas and the other in Virginia. This lowers the chances of the multiple clients collaborating.
4) Instead of having two clients have complete copies of each others data, also fragment who clones what. For example, if I have data A, F, and J don't protect it by giving another client A, F, and J. Instead, split it up among three clients that have (A, D, R), (C, F, K), and (I, J, Z). This way if clients are collaborating they still only have access to a small bit of the data on their machine.
5) In the case where a discrepency is found, check all clients affect by the discrepency by comparing each piece of their data against all copies of the data on all clients. Unless there is a very large and pervasive (50% of players) network of cheaters who work together, this will point at any client simply modifying lots of the data it has access to. Since the N data fragments are spread across at least N (or 2N if data is triple stored) clients it is more difficult to get the required number of collaborators with the same data.
1) When splitting up tasks, do so at a very fine grained level. For example, a client should not be "Inventory for 1000 Players"; ;instead it could be "Iventory for 10 players, commerce for the bar in Nagshead, and player movement on Acre G-43". That way any single player has difficulty doing large scale cheats because the client has control over only a small bit of data.
2) Never give a client control of its own player's data. Very obvious, but it instantly makes it much more difficult to cheat.
3) Distrtribute copies of the same data to IPs that appear to be geologically seperated. Although these IPs don't give location precisely away, it should allow you to put one copy of the data in Texas and the other in Virginia. This lowers the chances of the multiple clients collaborating.
4) Instead of having two clients have complete copies of each others data, also fragment who clones what. For example, if I have data A, F, and J don't protect it by giving another client A, F, and J. Instead, split it up among three clients that have (A, D, R), (C, F, K), and (I, J, Z). This way if clients are collaborating they still only have access to a small bit of the data on their machine.
5) In the case where a discrepency is found, check all clients affect by the discrepency by comparing each piece of their data against all copies of the data on all clients. Unless there is a very large and pervasive (50% of players) network of cheaters who work together, this will point at any client simply modifying lots of the data it has access to. Since the N data fragments are spread across at least N (or 2N if data is triple stored) clients it is more difficult to get the required number of collaborators with the same data.
It is technically impossible to have a large scale p2p (on the Internet) game, because of bandwidth and latency issues. Plus, it makes absolutely no sense, the client/server paradigm works great.
Quote:Original post by Raduprv
It is technically impossible to have a large scale p2p (on the Internet) game, because of bandwidth and latency issues. Plus, it makes absolutely no sense, the client/server paradigm works great.
Not at all. I know there has been at least one game that could count as an MMO that was essentially a P2P network. It involved every client have a patch of land that it owned, and releasing your own AIs into it. The AIs could then be teleported into other clients through a P2P network formed by them. As they spread through the network they reproduce and compete with the other AIs. Not your standard MMOG, but since it managed to have a 1000 players or so I think it counts.
Even for a more standard MMORPG, I don't think it is "technically impossible". At the very least, there are possible reqards to a hybrid type system. I heard that WoW streamed (a la BitTorrent) patches to clients from other clients, at least a proof of concept of P2P.
Once the security issues are dealt with there are certain cases where a hybrid system comes to mind. Any sort of operation that is a little more lag tolerant could be offloaded to the P2P network. For example, commerce systems can usually deal with a a little lag and can easily be "dealt with" since even a real simulation of any transaction would take longer than the transmission. As already mentioned, patches and levels can be distributed via P2P. All non combatant NPCs could probably be put on the P2P network, and so could all messages through the chat system. I think these are enough to make at least a dent in bandwidth, and they are all pretty easy once the network is there.
There are other more difficult possbilities too. If a player is off on their own, not engaged in battle, then it could make sense to manage that players movements and inventory on the P2P network. Crowded cities and combat situations would then be handled by the more reliable servers, which don't have to bother with lag tolerant situations.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
