Lagless Server, Invincible Security.

[Tyhm]

I think I have it. The way to make the System stronger, faster, and harder to hack. We farm out the Server's tasks to random players.
Not just
Server: "Give player42 all the processor load of the Server", but more like
Server: "player2's asking what the Bomy Lord's doing. Have player(int(rand(0,playercount))) figure it out."
Then, since that raises the problem of some clever scriptkiddy coming up with a trainer that gives bad answers every time he's asked, have the server spend its idle moments testing:
Server: "Hey player38, player2 wants to know what the BomyLord's doing"
player38: "Now's my chance! Server, the Bomylord lays down a bunch of bombs in this pattern, then shouts expletives."
Server: "That's funny, by My math it should have moved to 32,28. FLAGGED!"
GP: "What the-Player 38 got flagged for returning...oh wow, yeah, that's a banhammer..."
-and because only the System NPC knows which ones are tests and which ones are actual requests, player38 never knows if he's Actually screwing with the server or just letting the server know he's being a bad little scriptkiddy.
Also, since player38's never asked to calculate things for player38, he can't very well edit the world to his own liking. If the only players online were all hacking at the same time it'd be a problem, but then again, Graal would have some considerable problems if the only people playing on a server were all trainerers...and it might be best to just let them have their fun in such circumstances. Similarly, the server would have to do the math on its own, normally, when the playercount got too low (but then, the server should be able to handle a load of 3 players)...and some minor scripting would have to go into "If player96 doesn't return an answer within 0.4 seconds, go to somebody else and raise 96's latency index. If they don't return an answer within 0.4 seconds, calculate it personally and return the answer immediately"

It's a thought, I dunno enough about the server infrastructure to say if it's really feasable.

[Twinny]

Wouldn't there just be more overheading triggering all the players to do these calculations rather than the NPC-Server handling them itself?

[Deadly_Killer]

I laughed.

[JkWhoSaysNi]

That would cause more lag for everyone because their computer would use more bandwidth it would also be significantly slower because you'd need to wait for the data to get sent across the internet (and back) before getting an answer. Not only that, potentially it could get out of sync because results from some players will come back slower than results from others due to network and cpu speed.

[Tyhm]

It seems to me that the server already is pretty good at handling intra-player dataflow. And that players are already pretty good at passing data and crunching numbers. And that network traffic is an inevitability.
As it stands:

Clientside (no lag, no security):
Player A enters the room of the Bomy Lord. (proc: P.A)
Player A calculates the Bomy Lord. (proc: P.A)
Player A reacts to the Bomy Lord. (proc: P.A)
Repeat.

Serverside (high lag, high security):
Player A enters the room of the Bomy Lord. (proc: P.A)
Player A contacts server. (network: P.A->server)
Server calculates the Bomy Lord. (proc: server)
Server contacts Player A. (network: server->P.A)
Player A reacts to the Bomy Lord. (proc: P.A)
Repeat.

Propsal: (low(er) lag (than serverside), high(er) security (than clientside))
Player A enters the room of the Bomy Lord. (proc: P.A)
Player A contacts server. (network: P.A->server)
Server reroutes connection to Player B (an insignificant network&processor load)
Player B calculates the Bomy Lord. (proc: P.B)
Player B contacts server (network: P.B->server)
Server reroutes connection to Player A (an insignificant network&processor load)
Player A reacts to the Bomy Lord. (proc: P.A)
Repeat.

I'll grant it only works if the server takes drastically less energy and time rerouting connections than processing and responding, and it requires a certain Battle.Net-like faith in the other guys' processors, but it beats what we're doing.

[JkWhoSaysNi]

but transferring data across a network is significantly slower than calculating it on the server.

You're also doubling the necessary network traffic, which will double the lag. Any small gain in the amount of time taken to do the calculation will be lost by transferring the data across the internet twice.

Unless you're talking about making a direct connection between player A and player B and make graal a p2p network, the problem with that is that graal will have to listen on a specific port... which not everyone will have open for incoming connections.

Then what happens if player B logs off in the middle of the transaction? You get even more lag because the connection has to be remade with a 3rd player.

You're also relying on the potentially limted network and CPU speed of individual players.

[Tyhm]

Yeah, Peer-To-Peer (as opposed to the other P2P, Pay-to-Play).
Like I said, I don't really know enough about the architecture...I don't reckon the AIM server has a whole lot of thinking to do in maintaining people talking to each other, even while masking their IPs from each other. But then, making random connections and randomly quizzing these connections could be just as bad.
Which pretty much leaves us back at "Either have the player do the calculations, or have the server do it." If we lived in a world where players could be assigned relative lag indexes, and said indices would be stable, we could trust the two high-powered processors to do each others' work: player1's fighting the bomylord while processing the mushroomlord for player 2, and player2's fighting the mushroomlord while processing the bomylord for player 1, and all the server's doing is occasionally checking up on them...
Pipe dreams, oh well, it woulda been nice.

[Twinny]

Waaay to impractical. For the most part, it seems most serverlag comes from triggers. The next would be poor scripting.

[Skyld]

Originally Posted by Tyhm

Yeah, Peer-To-Peer (as opposed to the other P2P, Pay-to-Play).
Like I said, I don't really know enough about the architecture...I don't reckon the AIM server has a whole lot of thinking to do in maintaining people talking to each other, even while masking their IPs from each other. But then, making random connections and randomly quizzing these connections could be just as bad.
Which pretty much leaves us back at "Either have the player do the calculations, or have the server do it." If we lived in a world where players could be assigned relative lag indexes, and said indices would be stable, we could trust the two high-powered processors to do each others' work: player1's fighting the bomylord while processing the mushroomlord for player 2, and player2's fighting the mushroomlord while processing the bomylord for player 1, and all the server's doing is occasionally checking up on them...
Pipe dreams, oh well, it woulda been nice.

There is no advantage in the NPC-Server passing the jobs to the clients. It'd be a security risk if the tasks were somehow intercepted (and it'd happen), and if a client dropped out, suddenly the server has lost some instructions. The transfer mechanism isn't fast enough, and the server would suddenly have to start regulating tasks instead of just doing them itself in a third of the time.

The machines that the NPC-Servers are running on are pretty good machines; it's just as easy to leave them there doing the work in the same fashion.

In theory the idea is probably a good one, but there are so many architectural limitations that make it highly impractical for something like this.

[zokemon]

Originally Posted by Skyld

but there are so many architectural limitations that make it highly impractical for something like this.

Well said!

[Tyhm]

Yeah...
hah, we should do P2S (Peer to Self) transfers.
P1: "Where did the Bomy Lord go?"
S: "I don't know, where Did the Bomy Lord go?" (Reflecting pings)
P1: "Right there."
S: "Right there." (Either reflecting pings or checking math - either all the load of 127.127.127.1 or part of the server's regular load)
P1: "Okay!"

But every time Stefan comes up with a clever way of checking that clients aren't cheating, the scriptkiddies come up with a clever way of bouncing the Right answer whenever they're being checked and the Wrong answer the rest of the time...