Hm. Or maybe it will...

Posted: 2 years ago (2009-07-03 23:51:51 UTC ) / Updated: 2 years ago (2009-08-22 02:51:02 UTC )

One of the problems I was having with the original RailsMUD architecture was of synchronization. I'd like to be able to have one or more AI servers for monster AI, or weather, or other potentially time-consuming calculations. It would make sense to parallelize that way, and to connect in roughly the way that players already do.

However, that opens up a pretty big can of worms. In case of server problems or network latency, you don't want the player to keep playing along merrily while the monster AIs stop working, for instance. But how do you make sure it all stays synchronized without causing all kinds of problems in the normal no-error case...

So this rethinking thing can also fix that problem.

I'm thinking of a server architecture with a single primary "physics server" which connects to Rails and sends out notifications to players via Juggernaut, so that part is similar. However, with only a single connection from an AI server to Rails, you can just make players wait on it in most cases and it's not a big deal -- if that goes down, you want all action to stop.

And by making it the only extra server that gets its own Rails connection, you've given it potentially much tighter control over its sub-servers. It can keep connections to them constantly open rather than messing around with Rails and HTTP all the time. It'll still need to be able to handle the monster AI going down, but it'll have the authority to stop things like combat as well, so the monster AI going down isn't just giving the players a free pass to whomp on them. That's good in case players get clever about things like denial-of-service attacks...