start_link() ->
  supervisor:start_link({local, ?MODULE}, ?MODULE, []).

Which in turn calls the initialization callback:

init(_Args) ->
  %% do some stuff.

Notice that the initialization callback takes 1 argument event though the params list (the third parameter) is empty in your start_link func.

So, naturally (am I alone in this?) I assumed that when defining a Child Spec for a Supervisor, the {M, F, A} definition would follow the same pattern:

Childspec = {child1,
            {child1, start, []},
            permanent, brutal_kill, worker, dynamic},
%% ...

But the above definition does not call child1:start/1, where the one parameter is the emtpy list. Instead, the list items are extracted as individual parameters. So {child1, start, [p1, p2, p3]} would call child1:start/3, and {child1, start, []} calls child1:start/0. Just something to look out for if you’re new to erlang and the supervisor behavior like me.

Besides being a good lesson in how nothing really every dissappears from the internet, I mention it because studying the source has given me a lot of insight on how to approach a multplayer server in erlang.  I highly recommend checking it out, even if you don’t use a single line of code from it.  At the very least it’s a great working example of how to implement gen_server.

Also here’s a good primer on gen_server.

1. Ubuntu Server Hardy 8.0.4
2. Apache 2 listening to port 80
3. Erlang R12B-3
4. CouchDB 0.8 listening to port 5984
5. Yaws v1.76 listening to port 8080
6. MochiWeb Library

The instance ID is ami-12ae4a7b and I’ve made it public so feel free to use it to your hearts content!

I plan to add to this instance whenever I find time.  I definitely want to get SSL socket communication going using this tutorial.  I’m also interested in Kevin’s virtuerl project over a hypotheticalabs for quick and easy VM management because the whole reason I’m going through the trouble of doing this on EC2 is I think development on any erlang system should start and end with multiple physical machines.

I find his post especially interesting because I think the multiplayer gaming infrastructure of the future is going to be on these Cloud-type services.  Not just static data like Valve’s new Steam Cloud, but dynamic real-time multiplayer services that you can “just throw another box to” to handle load peaks, etc.

Their approach to “worker” instances I like a lot – they are completely stupid when they are born, but once started they execute a small script that fetches their intelligence.  Brilliant!  Updating your core software is dead simple – update it once on your mother ship, and all your worker instances will be up to date automatically when they are born.

This is in contrast to packaging your machine instance with all the necessary software to start work immediately, which limits you to the role that you’ve packaged it for.  Also, you don’t have to create and test new AMIs every time you want to update… have you ever made one of these things? – it’s hard! On a scale of one to ten I would rather take a fork in the eye than create, upload them and test a new instance.

The workers in the system Don outlines are isolated and receive their intelligence and work from a central server, but what if you were to take the advantages of an Erlang based system – immediate awareness, concurrancy – and throw it into the equation?  Veeeery Interesting….

When we start talking about the technology required to provide a backend for the actual game, that’s when the choices get interesting.  Most multiplayer games on the PC or console probably use some sort of custom framework for handling network traffic, probably written in C, C++, Java or some other low-level language.  But, I kinda want to mix things up and jump on what I think will be the next generation infrastructure for networking/multiplayer in games – Erlang.

There was an article on Reddit quite a while ago – Writing Low-Pain Massively Scalable Multiplayer Servers – that really says it all a lot better than I am qualified to.  I highly suggest reading it, but I’ll talk about concurrency here.

Erlang is a great choice for multiplayer infrastructure because it was built from the ground up to be a high-concurrency system.  It’s trivially easy to add nodes to an Erlang cluster because there is built-in node detection; so once you create your new instance of the Erlang emulator and connect it to any other node in your system, all other nodes become aware of it.  The bottom line is, you don’t have to spend any resources creating this network effect  – it’s a fundamental part of the language!

In the article I linked to above, Joel recommends creating a node for each processor on a machine.  It’s not uncommon for servers now to have 8 processors, definitely at least 4.  So if erlang is your platform of choice, you can immediately create 4 or 8 instances, each doing separate tasks and maximizing your CPU usage out of the box!  Amazing.

I’ll continue this discussion in later posts as I gain more understanding of how things fit together in an erlang-based multiplayer infrastructure.

Some of the reasons he wrote Twoorl:

The reasons I wrote Twoorl are:

- ErlyWeb needs more open source apps showing how to use the framework. It’s hard to pick how to use the framework just from the API docs.
- Twitter is awesome. Once you start using it, it becomes addictive. I thought it would be fun to write my own.
- Twitter is very popular, but I don’t know of any open source clones. I figured somebody may actually want one!
- Some people think Erlang isn’t a good language for building webapps. I like to prove them wrong

Could the next big stack to hit mainstream be LYCE – Linux, Yaws, CouchDB, and Erlang?

Given that scalability is such a huge issue right now, and Elastic/Cloud computing is almost certainly the next big infrastructure movement, I certainly think at least Erlang and CouchDB will go mainstream.

Another variant could be LYSE – Linux, Yaws, SimpleDB, and Erlang.

Little did I know this would be a 5 hour long journey through rpm hell, failed dependencies, yum repository management, and who knows what else. Heck, I didn’t even succeed completely, but I did manage to get Erlang up and running. Whew. CouchDB, I’ll come back to you later.

Anyways, to save anyone who is trying to do this a whole lot of time – don’t worry about rpms, yum repos, any of that crap. Go here. No wait, better yet go here. The CEAN project packages and distributes binaries for OTP/Erlang as well as binaries for a whole slew of applications. It’s a nice framework and easily updated. Simply SSH into your media temple dv and grab the binary with:

wget http://cean.process-one.net/pub/R11B/prod/linux-x86/cean_installer.bin

Make sure and give the installer executable status:

chmod +x cean_installer.bin

Then execute it:

./cean_installer.bin

Voila – you now have Erlang installed and running on your Media Temple Dedicated Virtual. At the time of this writing the latest Erlang release is R12B-2, but CEAN distributes R11B.