In an architecture like this the server is "listening" to all the movement and only speaks up to correct/stop a cheat.
I don't quite understand what the benefit is of that.
The benefit is reduced server load.
Its a question of what is 'critical' v. 'noncritical' data If you have a design that sends a monmement packer per player 10 or twenty times a second and the server has to respond to all of that on the logic level, you will hit a scaling wall pretty fast.
OTOH if it effectively "p2p" then it deos not invovle the GLE and has a much lower system load (negligable in comparison) on the back end. Keep in mind that the world of the GLE is fully rpesistant wherase the comm layer is not,.
If you really have a need to filter a comm layer stream its far mreo efficient to do it by plugging in a com-layer filter (next revision of the API will have this alon with the extension docs. We already have it in our development code base.)
But in the end thre is no such thing as a 100% cheat proof game that scales massively and doesnt require obscene levels of hardware to do so. What you need to do is asses the real "threat risk" of various kidns of cheats and if they ar worth the power it will take to make them impossibole. Threat risk is a combination of how easy a cheat is to accomplish, how much damage it does to the game AND how easily noticable it is. If the damage is low they probably arent worth scraficing play expereince for. if the chance of beign detected is high then any cheaters will get caught and delt with promptly so damage is mtigated.
And as you say, it really coems down to game design on those points.
If the distribution to the other clients goes through the server, and the server "listens in" on this stream, then the server might as well be in the loop, and discard illegal data before it's even distributed. What would be the benefit of only broadcasting a correction after the fact, when the server is already involved in the distribution of the data?
The advanatge is that *critical* things ARE dealth with server side, for instance comabt. and access to rewards. Lets take an example with and withotu the detector:
(1) Without the dettector, I disabl;e wall collision on my server. Now I can go around combats and straight to rewards.
(2) With the detector, when i try, I get reset to where I was befoer the cheat. MOnsters and rewards still know me as beign at my correct place even if I try to cheat.
Wait, you say, you are sending everyones motion to the GLE arent you? yes, but with two key differences: (1) It can be much lower resolution then what I send to players because how it "looks" is not important, only results are and (2) it can "lag" in its response under heavy load without effecting apprent game play of non-cheating players.
This all comes down to game design,. There are NO easy "one size fits all answers" that look good, don';t lag, and maximally scale. Designing MMOS is very much a world of balancing trade-offs.
This is just one desigtn above, ofcourse, there are mahy others. But overly simplistic "Im just gonna make the serve do everything" approaches don't succeed for any serious size with any kind of serious load.