Distributed multiplayer server pattern

Started by
5 comments, last by VildNinja 10 years, 1 month ago

Hey networking people, this may sound like an mmo question, and yes maybe it is, but I am doing it for science! Or at least considering it a project for next semester at my University.

You can skip the next three paragraphs if you just want to go to the question :)

So.. I'm very interested in alternative networking models especially the ones that don't trust their users! Recently I've been looking into ways of distributing (massive) multiplayer rpg servers. The current model I'm working on is based on splitting slow "macro" events from the faster "real time" events. I categorize the two by whether other players care or not. With the exception of chat, where people usually care, but a delay on a second or two shouldn't matter (maybe I'll leave that out and add a dedicated chat server (but not important now)).

Macro: Inventory management and skill management are not important in the faster aspects of the game, meaning users can do their changes locally, and later (1-3 seconds) sync with the macro server. This doesn't work too well with consumables, as their effects are usually needed asap. Therefore I want to add a tiny inventory to the real time part of the game - think Project Zomboid, where eating an apple takes less than a second if your'e holding it, but if it's in you backpac you need a second or two to unpack it first.

Real time: this is where the game is running. Every player have their active abilities, stats, current hp/enegy, and a few quick items such as weapon, consumables and other usable equipment. The point about only having a tiny inventory is that this the inventory in general is unnecessary information for the server, and I would rather keep the player footprint as small as possible.

And now to the interesting part. I would like to distribute the real time servers to the clients (who I do not trust). The idea is to have the clients do the real time actions and keep players in sync, but still be as stupid as I can possibly make them. What I want to do is to let the client servers report the game state to a trusted master server every x seconds. The master server will then verify (or pass randomly selected states on to a verification server) and calculate the next actions for the client server.

The actions from the master server should be instructions for what the client server must do. This should be in the form of direct instructions mixed with a state machine for individual interactive objects/AI. This could be in the form of "the seed for the random gen is xx + package id", loot for all dead creatures, if (creature reaches 30% life) {it will flee}

I am planning to use some message signing so the client server can't lie to the master server about the actions of individual players.

My question is whether this has been done before (or rather links to games/people who have done this or similar before)? And what you generally think of the idea?

I would also greatly appreciate links to article of not so similar models, if you think it would be to use for me.

/Jannek

Advertisement

If you want to do calculations on the client and you dont trust the client, the only option i see is to instead say that you dont trust the clients as individuals but do as a group.

This allows you to have multiple clients do the same calculations and only accept the result the majority of the clients agree with. If there is not 100% support by all clients towards a decision, more clients should determine the solution to increase the reliability. Perhaps faulty clients could be detached from the network if the majority agrees that the client is not reliable.

This of course will increase the required communication by a lot (need more bandwidth/latency will increase etc.) and doesnt fully take advantage of the available computing power because all calculations must be redundant (you can probably remove redundancy from random calculations and not let the clients know which ones, so that they can never be sure whether they will get caught, but of course this will increase the probability of someone being able to mess with the data) and of course will not work very well if the majority of the clients are cooperatively evil (which is probably easy to arrange if the circumstances are right)

Maybe you could do the calculations on single clients if you can verify the correctness of the result on the server in less time than it takes to calculate the result itself. This will only make sense for well structured problems that are actually computationally heavy.

o3o


and of course will not work very well if the majority of the clients are cooperatively evil (which is probably easy to arrange if the circumstances are right)
I tried to do something similar with a two teams fps, but in this case I don't trust groups either. Of course I can try to avoid players on the server being related to the server - such that one player in one region will host for players elsewhere.

I would rather keep i at only one server per player group.

My entire point of sending the game state to a master server would be to verify cheat. Such that the master server wouldn't have to deal with a ton of clients several times a second, but rather just see a game state and generate conditional actions for the next two seconds, and then not having to deal with it again before that. If the client server got specific instructions to make a creature flee if a player got within a certain range, it should be fairly simple to see if that happened.

My biggest fear is that the players knew too much about the random generator, such that they could decide when not to take a hit, and when they should.

Is your goal to create a fun game, or to do untrusted networking research?
And, if your goal is to create a fun game, does it have to work even if players don't pay you for it?
And, if it has to work "for free," is it sufficient to penalize cheating server hosters with a review/reputation system?
enum Bool { True, False, FileNotFound };

For the current scope I'm entirely in it for the research. Just wanted a few comment's on it before asking some of my professors to supervise the project.

I would however like to create something that could be used in a real game. But I'll look more into this next winter.

My project would be focused on regular mmo systems, but with a lot of the real time logic distributed to clients. I am still expecting this system to require some expensive servers.

In short No I do not expect to be able to run a server for free.

I have been thinking of some sort of reputation system, but I would rather not have to trust any users. I am aware that I can't prevent cheating, but I would like to be able to detect it, in order to ban users from the network.

The business and trust model for MMOs very heavily favor centralized authority. So, doing theoretical research is fine, but the "could be used for a game" part is unlikely to actually be true.

There was a research project a while back called VAST about peer-to-peer MMO/virtual world simulation. You might want to look up that for some idea about what's been done before. It has showed up on GitHub now: http://vast.sourceforge.net/
enum Bool { True, False, FileNotFound };

VAST looks quite interesting, and definitely have some great resources. It is not what I have in mind though. I don't want to make a decentralized server model, I just want to delegate the real time communication to the users where possible. For the scope of this project I think I'll just go with region based or a quad tree for deciding which users should be on the same server.

U56plhJ.png

My goal is to run the game server as a turn based strategy game, receiving a snapshot of the game state from the real time servers every two seconds, and responding with instructions on what the real time servers should do next. The two green servers connected to all the users is not interesting for this project. This is just for tasks like inventory management and the like.

The plan is to let the real time servers be hosted client side as much as possible (with a few self hosted as a backup) this will of course also require a bunch of facilitators and proxy servers (not in the diagram), in order for the players to connect to each other, but NAT is not what I'm worried about for this project.

As shown in the diagram the actual game server(s) is self hosted such that all loot, xp, and what not are being dictated from an authoritative server. This means that time from killing a monster to actually seeing the loot will be 2-4 seconds, but I don't see that as an issue, as irl looting also takes a few seconds .. I've been told..

The user hosted real time servers should connect to x number of users. Every two seconds they will receive instructions for what to do, based on the game state 2 seconds ago. Theese instructions should include loot for newly dead monsters, new monsters to spawn, new players entering the area, some random numbers, simple state machines for monster/environment ai, etc. Possibly also requirements for additional data in the next game state i.e. all of user#23's movement just to verify that the user didn't get too close to a monster, without the server triggered its attack state.

This way my self hosted game server only need to spend resources on 10-30? players once every two seconds, as opposed to every tick. And it only needs to communicate with one player for every group of players

My main issue is user servers cheating with the random numbers to make players damage more and monsters less. Servers sending information about traps to players via their own channel, I try to avoid this by only letting the server know what will happen two seconds at a time. In pvp I will probably need self hosted servers, as delaying opponents packages is practically undetectable.

Hopes this helps to clarify the project a bit :) I am very grateful for any response, as this is a big project, and probably also a bit too big for a regular 15 points project (do you use ects in the states? otherwise that's half of the time in one semester), so I might consider cutting it down to smaller pieces.

This topic is closed to new replies.

Advertisement