1
\$\begingroup\$

I am creating a multiplayer JavaScript game with a PHP central server. Each user will be able to move around in a 3D world, with other users and NPCs. It came to my attention that SQL is not going to handle all the requests being made in a reasonable time. So I cut down on SQL requests being made as often, using RAM when I can, but each user that logs into my world, or switches worlds requires a lot of data to be filtered from the server (So the client does not get any information it should not have, and so I don't have to distribute the entire world for every logon) and then uploaded to the client. So I had an idea: What if I can get the World data from the users near to the player(In the 3D world), like a BitTorrent? How to resolve syncing issues? What are my options to prevent Hacking? My ideas were: check with more than one user, get a hash from a server(will probably have syncing problems), have bots who request worlds from clients: then checks with server to see if they are being honest, how ever they all seem to have their problems, and am not sure which one(s) I should incorporate, or if there is a better way I could get correct world data from peers, with minimal server interaction.

Note: Peer to Peer is only used to get the world, block/world updates are still handled between the server and each client

\$\endgroup\$
5
\$\begingroup\$

For peer-to-peer communication between web browsers, WebRTC is likely the best option available. But keep in mind that it is not universally supported yet.

Also keep in mind that while you might save traffic on the server this way, the perceived performance for your clients might be far worse, because consumer-grade internet connections will likely have far worse peering than your server in a datacenter. But even when the client has a good connection, sending data to a client first and then from that client to another client will almost always have a higher latency than sending it to the other client directly. So I would only recommend this technique for large bulk-downloads, not for time-critical frame-by-frame updates.

To prevent players from spreading misinformation, you could use public/private key cryptography.

  • On login, give each player the server's public key directly from the server.
  • When the server sends a chunk of data to a player, have the server sign it with their private key.
  • When a client relays that chunk to another player, include the signature from the server.
  • Have the receiving client validate the signature of the server with the server's public key before you trust it.
\$\endgroup\$
5
  • \$\begingroup\$ I was planning on using WebRTC, and my game is going to be aimed at Google Chrome, and I'll try to get Firefox working as well, if it isn't too inconvenient. @Philipp Thanks for your help. Your key idea is going to save me a lot time, and make things a whole lot easier. \$\endgroup\$ – Grant Davis Nov 5 '15 at 15:30
  • \$\begingroup\$ Unless I hash the changes and verify it with the server. Would that work? \$\endgroup\$ – Grant Davis Nov 5 '15 at 18:34
  • \$\begingroup\$ @GrantDavis You certainly don't want clients to be able to change the world without the servers permission. That means the authoritative world state would always originate from the server. When the server sends an incremental update of the world state, it can also submit the signature of the new world state. \$\endgroup\$ – Philipp Nov 5 '15 at 18:40
  • \$\begingroup\$ Wouldn't that require the server to read the world from memory to make a new signature? The point if this is to reduce large SQL requests. \$\endgroup\$ – Grant Davis Nov 5 '15 at 18:45
  • \$\begingroup\$ @GrantDavis But the server only needs to calculate the signature of the world state once after every change, no matter how many players are connected. \$\endgroup\$ – Philipp Nov 5 '15 at 18:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.