quote:Original post by Ironside
Magmai Kai Holmlor:
Your system has potential and you acknowledge that there are some assumptions being made for peer validation. I would like to present some counter point as to why this implementation may make the game "harder" to hack, but is still not as secure as a client/server model.
Yeah, I realize that, but please do point-out any problems you find; I'd like to refine the model to the point that it's feasible.
quote:
Firstly, in a peer-to-peer model the bandwidth requirements are actually greater per client.
Absolutely true; though I (think I) understand all the bandwidth issues at stake. Modem users could be supported as leaf nodes in the peer-update tree, they would only have one active connection to a broadband user for propagation (additional idle connections as backups in the event that the active broadband user disconnects).
quote:
Any action a client takes must be sent (as a general rule) to all the other peers in the peer-to-peer session.
No! Errr... oohhh. Well, I planned on having each node only propagate changes to 4-5 connected nodes, and then they would send updates to 4-5 others. In the end, it's the same amount of aggregate bandwidth as having every client connected to one another, though you could save a marginal amount on packet headers.
There is a situation where you can gain bandwidth - if two nodes have a faster, alternate route to each other than to their peers, you gain that bandwidth by making them peers of each other (call them cable1 & cable2). This would occur whenever people play on the same LAN. When a peer in the graph decided it needed to send data to cable2, it would send it to cable1, and cable1 would send it on to cable2. You could also mutli-cast or even broadcast on the LAN, taking advantage of cable networks' unsegemented nature.
However much bandwidth is coming up the pipe, must be approximately equal to the bandwidth going down the pipe. You could pick someone in the zone to be the master, and every one would send their updates to them and they would send the updates back down. Maybe, each round of updates would go to a different node in the zone, round-robin style. So any given zone-master would only need 1/6 to 1/10 the bandwidth needed to update the entire zone every tick… synchronization might be "challenging".
If all the status updates about everyone in the zone come down a 36kbps connection, doesn’t that mean all the status updates going up take 36kbps? Whatever would only have been sent to the server before, would only to be sent to the one validating node (plus you could be a validating node for someone else).
Where you run into a problem, is when you try to run 300+ zones on the same network, now it’s 10.8 Mbps of bandwidth needed to support 36kbps/zone status updates – now add in event messages per node. We cleave off the event handling messages, by sending them to one (or maybe two) other nodes in the network, and then can have one (or a set of) nodes handle the status updates. The status update machines need to cull the updates, and re-broadcast them. The validating nodes need to generate random numbers, and send them to their client node and send the resultant state to the TOTS, and make sure the sent client actions are valid action for their state. It’ll be tight, but one broadband connect should be able to support a zone – with the round-robin updating, the average bandwidth usage plummets but still has the same peak demand. I think a tick is like 3 or 4 seconds long in EQ, and I think you could acheive that rate with this method.
quote:
In this circumstance it's very likely that a group of 10-20 players could go out in the middle of a desert or some other place with low player density and be in control of an entire peer to peer session.
I planned on having two connection trees; one tree for validation, wherein a randomly selected node is used to validate your actions (have enough mana, can’t just heal instantly, moved in the correct way), and handle your events (generate random numbers). These nodes could send status updates infrequently up to the TOTS, maybe once every couple of seconds or even ten seconds. Their job is to run your game, and occasional persist the state on TOTS.
Then there would be an additional low-latency peer-peer update graph for informational purposes only. Since the validating/TOTS tree catches cheaters, we can assume the information sent out on the peer graph is good (unless they just started cheating, which [hopefully] means they will shortly be kkk'ed).
quote:
In this case they could bypass validation. Even if your server checks binaries, clients could fake the response. Also checking binaries doesn't stop clients from hacking code execution in memory to skip the validation code.
It does when the code that's validating their client is in another random client. They could hack their client, which would let people who connect to them cheat, but not vice-versa. A viral worm would take it down.
quote:
There are solutions... I thought of a few, like the server would randomly join various peer-to-peer sessions and become the validation for that session. But this isn't really a solution, because clients need to synch up with the peer to peer group when they join; it would be pretty easy to detect when the server was entering and leaving your session. Also, the purpose of using a peer-to-peer model was to avoid the server having to participate in the gamestate, if it's roving around joining peer to peer sessions, the game might as well have been client server to begin with.
The difference is, the server doesn't need a ton of bandwidth - only marginally more than a client (maybe twice as much). Nor need a ton of processing power, as the checks are also distributed. TOTS could peek in by simply connecting to one of the peers, all the peers need-not-know TOTS is currently watching their zone. If the client we connected to was hacked, it could tell other cheaters; we would again have to rely on statistics. Then TOTS could ensure that the updates peers are receiving about a player, contain identical information to the ones it is receiving. In fact, I think this is a required portion of the system.
[edited by - Magmai Kai Holmlor on April 2, 2002 12:31:55 AM]
