who said it needed to be pure p2p??.

and yes, for an mmorpg definitely you need an hybrid system, but not uber systems as those nowadays ...

Cheese I really like that idea, I think checking a subset of players action is a really nice idea

Myolp if you can go hybrid it would be a more general (just need to keep it cost effective, so companies can run free services, such as blizzard''s battlenet), if you want to leave companies services out of this you would need to go pure p2p, but as Cheese stated that would leave out persistent content ...

Cheese as far as I understand you are talking about an mmo with no level/skills advancement at all, am I right?, no item gainning as well, in fact nothing that would change your char permanently trough game actions ... That restricts a lot, did I get it wrong?

quote:

---

Original post by eglasius
Cheese as far as I understand you are talking about an mmo with no level/skills advancement at all, am I right?, no item gainning as well, in fact nothing that would change your char permanently trough game actions ... That restricts a lot, did I get it wrong?

---

If you want a pure P2P game with no cheats and no special servers, that''s what you''re looking at. That sucks for an RPG, but you don''t really need much (if any) persistent content for a game like planetside or WWIIOnline.

If you want character advancement, you would need a special server to _make_ those character changes, but once they''ve been made you don''t necessarily need to _store_ those changes on the server. You just need a secure signing mechanism so the clients can''t make changes.

yes, completely agree ...

I want to expand a bit on this:

quote:

---

All you have to do is duplicate the logic - you set each member of the P2P session to simulate _two_ sets of player actions, their own and their 'suspect.

---

well, some people might argu against it because if the other peer gets disconnected who would be checking you, and most important your position, the solution would be depending on if you are using hybrid or p2p:
hybrid:
- Stuff needs to be saved on the server, to protect in the event a client in a pair goes awfully down(crash):
Thinking on that, clients would from time to time update their position (not soooo often, remember that is just
to have the data in the event of a crash in the other client). they would also save persistent data, but that should be more custom.
Stuff that involved non reversible desicions (when you choose skill points or the likes when you gain a
level). xp should be saved just like the position but with a lot GREATER difference of time ... items,well, it
depends on the taste, ... ok, the thing is that this stuff needs to be saved, and some of them needs to be
saved at different rates than others, and that would be dependant on the specific game, you can give general
recommendations, but they would fall short because of the great variety of designs ...
- if another client crashes down, sadly updating that for
the other player wont be gracefull, since to keep trusting that client, it would have to be asigned another client
to watch it, and the only trusted data would be that still on the server ... (well, minor deviations might be accepted)
- In the normal event of a player logging out, the server
would quickly assing other client, and use the data obtainned in that moment (when one logs out both would send data) to the server.
p2p:
- gracefully loggin off would be much like the one on the hybrid, but it would be directly with a third client.
- ungracefully loggin off(crash) ..., well I dont have a clue ... CheeseGrater??


Ok, that obsiously is high level, when you start going into details you need to think more on network latency, etc, etc ... but dont go in there, untill you really need to, it is easier to change a bit your well done high level design, that think on EVERYTHING right from the start, you would miss things anyway ...

[edited by - eglasius on May 29, 2003 5:38:48 PM]

[edited by - eglasius on May 29, 2003 5:39:48 PM]

Well, nearby clients are going to need information to display the player objects and such, so if everyone in the vicinity is kept current, some random nearby client can assume ''police'' duty when a client crashes. You might end up policing more than one suspect at a time, but you can offload that once someone else connects or enters your immediate vicinity.

I was thinking on something similar but didnt think of to make it fair for others, but just as you said you would be updating them with the data anyway, so ... yes, any nearby client can assume the police duty ...

Myolp?? (it would be sad if he doesnt check the board ....)
Edit: I sent him a mail ....

[edited by - eglasius on May 30, 2003 10:19:13 AM]

Hi again!

I don''t agree that a P2P solution for a MMOG would be impossible. The problems boils down to one point; how can we build a trustworthy distributed system with untrusted peers?

In my opininon this is a problem that can be solved using a monitoring technique (this is done in JXTA). The problem is to design such a system that wouldn''t interfer to much with the process (i.e., the running game). We still like to be able to play the game in real-time (or what seems like real-time).

If n players are connected in a P2P network and playing a real-time game, only the players which are close to each other in the game world would have to synchronize their actions. When player X performs an action, the nearby players can decide if the move is ok or not. If the move is denied by a majority, the move is ignored. The game state would be updated to the central server in a slower rate, thus making a persistent world possible.

Cheating is still possible, but only when there are so few players that a small group could ensure they are the only ones who will see the moves. In these cases, the system would have to be designed to return to a traditional client/server solution.

Such a system would require much less hardware but a VERY advanced implementation. The system would work since we assume that each player will be cheating and leave the detection of cheating to the nearby players (who are better equipped in detecting the cheaters).

My thesis work is currently progressing towards solutions for distributed systems with untrusted peers. The systems I''m focusing on are MMOG and distance tuition systems.

Btw; someone requested a chat with me. My ICQ# is 3142620

Actually, I would say cheating would be one of the smaller problems. Since the whole things is p2p, it means that a cheater will end up only changing the instance of the game running at his computer, causing him to go out-of-sync.

For example you''ve got two players, player A and player B. A is the l337 h4xx0r dude and has modified his game so he''s wielding a Platinum Über-Sword of Doom™, however in B''s game he''s still just got the Wimpy Dagger of Geek™. If A takes a swing at B, it''ll just end up with that on A''s screen, B dies after one attack. On B''s screen however, the game runs as it supposed to do and B is still alive and able to continue.

Of course, that means that you''ll have to designing the netcode carefully, i.e. instead of sending "player A beats up player B with 100000 points of damage" you send "player A attacks player B with the currently equiped weapon"

Sorry if it seems incohesive, but I''m about to head for bed. Hopefully my point went through tho..

-Luctus

---

Statisticly seen, most things happens to other people.
[Mail]

My biggest worry with P2P security is things that would happen outside the game, such as DoS attacks from one peer to another (since they can find the others IP address). This post excludes security flaws like this and is for implementation in a hybrid not P2P system.

If you want a hybrid (P2P) system to be secure you would have to monitor the network traffic of which there are several ways of implementing. The method I'm thinking of using is to have N peers "control" (or perhaps a better word is monitor) an object's state and report to those peers that need know about it. If a "controller" gives different results to the other "controllers" action can be taken to find the fault and correct it (E.g. alert a peer it is out of sync, kick them, etc).

"Controllers" are selected by a central server. These can be selected from a knowledge base of the most trusted or more highly resourced peers.

If any "controllers" time out any objects it was processing will still be held by other "controllers". If all the "controllers" of that object disconnect, new "controllers" can be selected to take over. During this time (< 1 sec?) object movement can be calculated (or estimated) locally.

More bandwidth and resources are needed than a client would use in a C2S system but I think this could be worked down to a very acceptable amounts. Having one "controller" broadcast the change and the rest broadcast a checksum (or alternative check) being a big bandwidth saver.

In order to help clients on different systems balance their needs between bandwidth and system resources objects should be considered on a PER PEER basis. Low spec PCs with high bandwidth may make use of getting data remotely while high spec PCs with low bandwidth may make use of local processing.

Also, whether objects should be calculated locally or remotely should be done on a PER OBJECT basis. Objects that have simple movement and have no player interactivity can be processed locally. Objects that have high player interactivity or complex movement should be done remotely (such as players, NPC/Bots, Vehicles, Weapons, etc).

In order for the "controllers" to come to the same conclusions random values must be known before hand. These can be pre-determined by a central server and sent to all the "controllers" using number pattern (algorithm).

A problem with this system is if the majority of the "controllers" within a certain game area (P2P network) are infact working with each other so they agree on false information. (they could have the majority of the vote and therefore kick innocent peers and alter game world information).One way around this might be to have a trusted "monitor" peer on suspicious or small groups of users (all in the same clan, similar names, similar domain names/IP addresses)

Lemme know if theres anything I've forgotten or overlooked.

[NOTE]
Sorry for anyone who read this post before I edited it, it was very long and didn't flow so I made rather big alterations to it.
[/NOTE]

[edited by - DragonWolf on June 3, 2003 12:36:13 PM]

I just wanted to drop a comment about something Cheese posted.

quote:

---

Well, nearby clients are going to need information to display the player objects and such, so if everyone in the vicinity is kept current, some random nearby client can assume ''police'' duty when a client crashes. You might end up policing more than one suspect at a time, but you can offload that once someone else connects or enters your immediate vicinity.

---

Alot of times the problem-children seem to run in packs. The thought occurs to me that using vicinity to determine whom your ''policeman'' is, may be exploitable with such a group effort.

I like the idea of being able to do a P2P MMO, that could really open some doors. Plus, it could be the only way anyone will ever see an indy-MMO.

quote:

---

Original post by Anonymous Poster
Alot of times the problem-children seem to run in packs. The thought occurs to me that using vicinity to determine whom your ''policeman'' is, may be exploitable with such a group effort.

---

You''re right about that. I considered that and discarded the idea at the time, because I think the first couple of MMP2P games are going to be non-Persistent (Planetside-ish FPS or possibly a massive RTS), so that''s what I mostly was thinking about.

In a non-Persistent game, it''s not really such a problem if a group of players want to go off alone somewhere and start cheating. They can kill each other however they like, but in a non-persistent game it won''t get them anywhere.

The only people who will care are the ones that don''t cheat, and as soon as one of them enters the area you''ll have an uncompromised ''policeman'' on the scene IDing the cheaters.

You will need some special handling for this case in a persistent game. A couple of ideas present themselves when I think about it, but I really haven''t come up with anything iron-clad for the persistent case yet. My first thoughts are a variation on the ''trusted monitor'' DragonWolf suggests, but I prefer untrusted monitors, of course - I hate special casing clients.

I''d set it up such that clients with lots of bandwidth would also join other sessions to watch events in some distant location, perhaps rotating around to increase coverage. If you find a suspected cheat, you send out a signal and some more randomly selected clients verify your findings. If they agree on a cheat, they tell the main server which imposes some appropriate penalty.