How should Erlang deal with common data?

Question

Suppose that I\'m building game server using Erlang.

It\'s very common circulation each user to check something (eg finding the closest player), so there\'s a manager cl

Answer 1

Now, before you continue, you may look at these questions and answers: Erlang: Distributed work on an array , Erlang gen_server with long-running tasks , and What is the best, most efficient, Client pool technique with Erlang

Now, learn about ETS Tables and Mnesia. Then you can perhaps look at GProc. Making a process to hold state data especially for a game is dangerous coz the state may get lost when the process exits. Its easy to restart a crashed process, but the data it was holding is lost. Normally, we need in-memory data storage which cannot get lost UNLESS the WHOLE erlang VM goes Down (In which case, if you need persistence beyond RAM, you will need DETS Tables or Mnesia still ).

Process Dictionaries are usually discouraged, yet they still prove to be extremely useful. However, personally, ETS Tables have saved me alot. They can be transfered from one crashing process to the next one alive. They can be dumped to disk or loaded from Disk and they can handle a lot of data.

Just study more on IN-Memory storage used in Erlang. Its BTW also possible to use storage outside the erlang VM, like Memcached, Raik, CouchBase, e.t.c. However, in some cases, a Game can be broken down to just a data structure like Queues, or Lists or Records , a data structure that can be saved within the process dictionary. Also, it will depend on how the game services to clients are rendered. If the game uses HTTP (RESTFUL), then you will also learn which Erlang libraries to apply (Mochiweb, Yaws, e.t.c.). Just follow this whole tutorial, you will discover everything.