Split talking about MMO servers (and Erlang) from this thread.
You’re “preaching to the choir” on actor model. Although I don’t think I would put forward “Facebook” as a positive example. To put some numbers to your “Apache” example, in 2007 a test was done on the same machine and Apache went “boom” at 4K connections and YAWS was able to hit over 80K. I’d never suggest using shared state concurrency for any moderately complex MMO server senario (Notice: I recommended never using more than ~(2 x effective-cores) active “real” threads).
Agreed. Your examples are some of the “risks” that would make me want to avoid using Erlang. You’d pretty much want your entities and connections to be actors and everything else in some other language. So you’d be stuck with at least two languages, one for actors and one for all the “other stuff” and potentially a third if you wanted to “script” your entities in some other language. And if you really wanted that scripting language, it would probably require some massive changes to the OTC (or whatever runtime) source. Yikes!
Since this a Java forum, let me throw out a potential Java solution, which I think covers most of the bases with much less risk:
Feasibility test:
Use kilim to insure that it’s capable of handling a large number of actors & messages. Both for processing entities and handling connections.
Proof-of-concept:
Merge kilim with the start of a hot-deployment codebase.
Modify janino to support annotations (not much work)
Merge kilim into janino. The default distribution loads bytecode classes and the performs the weaving (at the bytecode level) if an annotation is present. We’d want to change that so that the weaving occurs at compile time (within janino) instead. A little more work the the previous.
Create custom classloader to handle hot-loading. (not much work)
This is actually much more complicated that strictly needed, but having a runtime compiler opens up a lot of possible features. I’m fairly confident about the above working pretty darn well. The up-side of this is all the programming is in a widely known language with a more than reasonable runtime.
At this point we’re missing the following:
Load balancing, which I’d want explicitly handle at a higher level than the runtime anyway.
Messaging between actors on different servers (This was under active discussion on the kilim forums the last time I bothered to look).
Database handling.
OK. I’m out of time for the moment. Yeah, there’s still “risk” in my proposed solution, but it seems much lower to me than an Erlang solution.
In Erlangs defence, there are libraries you can use to build what look like Erlang nodes in C and Java. I believe to the Erlang runtime they then just look like any other Erlang process that you can send messages too.
So you could use existing C or Java game libraries for the Physics (with some integration code on top), Erlang for handling the server, and then Erlua or Reia for the game logic itself.
The downside is having to write across 3 languages, but in fairness all three are suited for their specific tasks. That doesn’t seem so bad to me.
