Parallel sessions & security, host/peers vs server/client

Hi all !

I am trying to understand the limitations of the host/peers model in terms of security in parallel game sessions. I've read various things here and there, but I'm still confused about one particular situation.

By "parallel game sessions" I mean a form of multiplayer where players don't interact with each others but all contribute to a shared central database (e.g. a leaderboard)

I am familiar with multiplayer concepts and low-level networking (packet handling), but I don't know much about general web-technologies (Ajax, etc.). I'll try to expose what I understand, and hopefully someone can confirm what is doable/not doable

Scenario 1 : actual multiplayer, parallel sessions. E.g. players divived in small groups in separate PvP or coop matches

The first player to enter the room becomes the host for the session ; the host processes all the gameplay logic, peers only process input and player feedback to present the game as the host sees it.

Cheating is possible but is mitigated by the fact that the host is selected "randomly". Unless all the participants are in on it, someone running a hacked version of the game is unlikely to become the host.

This is acceptable.

Scenario 2 : actual multiplayer, single session. E.g. a small "mmo"-type game where all the players are part of the same world

(Feasibility is debattable as dozens of players joining the same room would quickly cause some bandwidth issues on the host ; this example is only a "study" case)

As there's only one single instance, the developper can run its own copy of the game and make sure he gets selected as the host (i.e. join the room before anyone else). This prevents cheating by guaranteeing that a "clean" version of the game is running the gameplay logic.

So far so good.

Scenario 3 : parallel sessions, central database (leaderboard). E.g. a puzzle-game where participants compete to get the highest score. The gameplay is "single player" but the leaderboard is "shared"

That's where I'm stuck...

In a typical server/client architecture, you have full control of the server ; so your server can handle multiple "solo" sessions in parallel, or you can spawn more servers with bridges to balance the load if necessary.

Is this possible to emulate this behaviour with host/peers ? There's no actual interaction between players, so it wouldn't make sense for players to connect to the same host. But at the same time, you would want each player to only be a peer, connecting to a host you control (as a developper) to ensure gameplay logic is fair.

Imagine a CCG puzzle-game where players have to defeat AI/challenges (solo gameplay), but you want to maintain a central secure leaderboard to reward the best players with trophies and in-game items. You can't really have each player running their own logic locally, or the leaderboard will quickly get filled with 999999999 impossible scores…

I'd appreciate if someone could comment on this scenario, and if this is even possible, to present a brief overview of the technologies involved (implement my own server and low-level networking to spawn a host for each new peer ? etc.)

In its core essence, I think the problem can be summarised as "how do you make a secure shared leaderboard in a host/peer architecture ?"

Regards

Are asking in C2 MP context or MP architecture as general?

In the context of Construct 2 structure / behaviours / plugins / etc. In a more general MP architecture, I could do what I want

I'm wondering if it is at all possible to publish a game with C2 and have a "secured" (to some extent... read "secure enough") centralised leaderboard that would match the scenario 3 described in the previous post.

I have a game concept, but this is obviously a major technical risk. My investigations were inconclusive so far, and I am not sufficient familiar with general web/server technologies to know what would be a "sensible" approach.

I'm wondering if it is at all possible to publish a game with C2 and have a "secured" (to some extent... read "secure enough") centralised leaderboard that would match the scenario 3 described in the previous post.

Scenario 3 is doable, but that would require a very creative use of array and possibly dictionary. You don't need exclusive host for each game, that would kill your server much faster. I never tried this kind of scenario, which a serverhost hosting single player game, but I have a theory that this can be managed by handling the logic using array (based on your CCG case) and store the array in dictionary to differentiate between peers. Possibly make the calculation to always read/write the dictionary consistently.

Oh, that's interesting ! So if I understand correctly, you would have 1 host handling multiple peers in parallel, by storing and managing the data related to each individual game session in arrays (or other suitable data structures)

Thanks for the contribution, I'll look into this !

Oh, that's interesting ! So if I understand correctly, you would have 1 host handling multiple peers in parallel, by storing and managing the data related to each individual game session in arrays (or other suitable data structures)

Yes, you got it right. The only pain is the data structure, I'm certain that it would be one hell of a job to do.

You can have all peers communicate with a central "hive" Even if you are running multiple instances of the game 100 rooms with 10 players each... you can still send info to

A hive that would be an external database

Lets say

mysql

and players would send info to a php file which would interact with database

Getting and writing data is easy enough - couple tutorials already using mysql and php.

Couple of unknowns exist, you obviously can't write ever tick, or even every second unless you have a monster database server, or bridged (is that correct term?), but you will bottleneck...Because you will be limited by concurrent connections.

So when to pass the data on???? And what are the consequences? Lag, game freeze, etc

A single high scoreshould be fairly easy to do... (tongue in cheek, nothing is easy - lol)

I've been experimenting, not successfully with a multiplayer save feature... "I'm talking about trying to save players game whilst using the multiplayer plugin"

So it stores users login credentials and game progress in webstorage (fair enough), but I've been trying to store it in a "hive" an external server.

The idea is to have a login system that logs user into multiplayer game, but also logs them into hive, and then loads their game progress.

Why? Why not, I'm thinking along the lines of boardgames, card games, something where I can play a game with my family over the weekend, and next sunday it is all still there where "we" left off.

Of course, time restraints and everything takes a bit of a back seat.

But running multiplayer games. Limited to max users. or even independant single player games -no problem for highscore.

Thanks for your contribution, 'much appreciated !

Very instructional tutorial & videos, btw I have little first hand experience of databases and connectivity, so that'll definitely be useful !

That being said, I don't think this solution satisfies the "secure" criteria I am after. Storing scores in a shared location the developer controls is one thing, but there is no safety or control on the game logic itself.

As long as the game logic is running on the player's machine, and not a developer-controller server/host, there is nothing preventing a cheating user to hack the gameplay logic locally to submit bogus scores and feed the database with random values.

Hence the need for all players to be clients/peers, i.e. only displaying the state of the game sessions, but not running any actual critical game logic.

I guess for very simple games with few updates it would be possible to have that logic running as a php module on an actual server and query things via http requests, but while I'm no web-tech expert this sounds clunky and inefficient.

Obviously the solution to this problem is known, and has been used in games for ages : use a server/client architecture ; but since Construct 2 has a host/peer architecture built-it, I am trying to see if there is a way to mimic and reproduce that behaviour in an "easy" and practical way with the tools that are already available.

Also, while this has little impact on small friendly coop games, this is major technical risk for competitive games that offer in-app purchases. It is essential that the gameplay is run by a secure entity to ensure the fairness of the game, and to guarantee that, for example, in-game rewards are sent to the player with the highest score and that this score is valid (i.e. obtained by playing the game normally, and not cheating with a locally hacked version)

This is clearly stretching and pushing the limits of what Construct 2 offers in terms of built-in services and functionalities. I'm thinking there might be a solution to achieve this in a semi-sensible way that wouldn't be too convoluted, but there's no point trying to use a tool in a context it hasn't been designed for, and therefore maybe going for a completely different technology might be the way forward.

I will look into DuckfaceNinja's proposal ; the other alternative so far being to look at the low-level networking directly and see if there's a way to recreate that server/client architecture.

Though I assume that having an easy way to secure game logic to ensure fair gameplay&scoring would be a must-have for all games with a leaderboard.

Thanks for your contribution, 'much appreciated !

Very instructional tutorial & videos, btw I have little first hand experience of databases and connectivity, so that'll definitely be useful !

That being said, I don't think this solution satisfies the "secure" criteria I am after. Storing scores in a shared location the developer controls is one thing, but there is no safety or control on the game logic itself.

As long as the game logic is running on the player's machine, and not a developer-controller server/host, there is nothing preventing a cheating user to hack the gameplay logic locally to submit bogus scores and feed the database with random values.

Hence the need for all players to be clients/peers, i.e. only displaying the state of the game sessions, but not running any actual critical game logic.

I guess for very simple games with few updates it would be possible to have that logic running as a php module on an actual server and query things via http requests, but while I'm no web-tech expert this sounds clunky and inefficient.

Obviously the solution to this problem is known, and has been used in games for ages : use a server/client architecture ; but since Construct 2 has a host/peer architecture built-it, I am trying to see if there is a way to mimic and reproduce that behaviour in an "easy" and practical way with the tools that are already available.

You will never be able to stop cheats or hacks. No system is secure.

There is no solution to this problem, and since people started cheating, the only solution is to adapt.

It isn't feasible to stop cheating. You can just put in place some basics (salt everything) to discourage the majority, but you will get a few who just gotta hack it.

Sorry, haven't got a solution - shrugs

But peer talks to host, have server run chrome and let server be host, when peers join, let host add peers data to database.

You will never be able to stop cheats or hacks. No system is secure.

Yes, I am aware And I'm not trying to stop cheating, I'm trying to find a sensible architecture that would fit "easily" with Construct 2 built-in services, and that would make cheating non-trivial.

There is a big difference between "let everyone run the game and push random data around" and "have the game logic validated by an entity the developer controls". The second, and traditional choice for commercial games, at least limits the scope of the cheating and makes it somewhat difficult.

I think the consensus so far is to go for the solution I described as "scenario 2" in the initial post (1 host the dev controls, every player is a peer), and use DuckfaceNinja's proposal on datastructures to handle multiple game sessions in parallel.

Unless there are other suggestions, I guess that's what I'll be investigating next ! I already have some host/peer running, but I'll need to start measuring bandwidth requirements...

Salt

recieved = data&salt

salt2=right(recieved, count)

salt=salt passed

else

failed

DuckfaceNinja is lightyears ahead of everyone when it comes to multiplayer. Whatever he says, he has good reason for saying it. So go with his expertise

Ah ah, well, at least this thread confirms I haven't missed anything obvious that would make it all very easy

DuckfaceNinja is lightyears ahead of everyone when it comes to multiplayer. Whatever he says, he has good reason for saying it. So go with his expertise

Well I wouldn't say I'm ahead of anybody in terms of MP, it might be true that I'm using it more and longer than anybody else, given the complexity of my project

I already have some host/peer running, but I'll need to start measuring bandwidth requirements...

think you might want to hold out on that thought first, because I don't think it is helpful to measure anything without actually seeing the actual data comes in/out. I think the best practice is to always build your events by considering network load in mind, especially the host. There are things that you can let the peer to process instead of host, so prioritize the logic but for a start, let the host do all the logic first until you have good grasp on which logic can be leveraged.

If you want to measure your bandwidth, you might want to avoid mistake I did in human error.

[quote:2hjk33ff]There are things that you can let the peer to process

Definitely ! Usually, when cutting it down to the core critical gameplay logic, there isn't that much in terms of processing that needs to be happening on a dev-controlled server/host.

Though if the idea is to go with the suggested scenario (i.e. 1 host handling multiple game sessions in parallel, every player is a peer), I'll want to have realistic estimates for min/max bandwidth bounds (i.e. knowing the load I can put on the host connection, how much game sessions can it handle at the same time), to assess the practicality of the whole solution. A working technical implementation that is not viable in terms of scalability wouldn't get me very far, therefore this is still a major risk.

Coming from a background of much lower-level programming (consoles, etc.), it is always tempting to try to push the boundaries, but beyond a certain point it simply becomes counter-productive (time invested vs. technical advantage)

Btw, thanks for all the input It's always great to be able to bounce ideas and make sure we're not missing the obvious !