БэФ블로그

Erlang's pool module provides a very easy to use load-balancing pooling mechanism implementing a master-slave pooling paradigm with one master and many slaves. By starting the pool, the master tries to log in to all slave machines and start the slave (see slave(3)). At that point the pool is set up and ready to use - basically. Stey by step: First of all a useful pool needs at least one additional slave node (with the pool module the master incorporates a slave node at the same time). The full hostnames must be listed as erlang atoms in the file .hosts.erlang, which resides either in the current working directory or in your home directory. Example:

'foo.bar.priv'.
'blubb.bar.priv'.
(newline)

Make sure that it is possible to log in to all machines without a password prompt. ~/.ssh/authorized_keys and ~/.ssh/config might be of help here. If you get an error involving "ssh-askpass" later, try to log in manually first. In order to let the erlang nodes communicate with each other their cookies must be synced. This can be done by setting the ~/.erlang.cookie or by passing the command line argument -setcookie COOKIE. That's all for the basic setup. To try it out we could start erlang like so:

erl -pa boo -setcookie pooltest000 -name pooltest@`hostname` -rsh ssh

and start the pool by

pool:start(pooltest, lists:concat(["-setcookie ", erlang:get_cookie()])).

The argument -pa boo adds boo to the code search path and -rsh ssh tells pool to use ssh instead of rsh. Next, it would be nice to automatically distribute our local code base to all the slave nodes. Luckily the code module provides a simple way to do this:

...       
{_Module, Binary, Filename} = code:get_object_code(Module),
rpc:call(Node, code, load_binary, [Module, Filename, Binary]),
...

Distributed processes can be easily created using pool:pspawn/3.

A complete example:

Using the Erlang bit syntax it's an easy task to unpack the tags of an SWF file. With this thought in mind erlswf has been specifically designed to analyse SWF Tags and ActionScript ByteCode for security issues such as the previously mentioned oversized branch offset or pattern matching against URLs loaded during runtime. The toolkit could also be used to implement a transparent proxy filter for exchanging pictures inside Flash files on the fly. Or if you had no choice but to accept prebuilt SWFs from a third party (e.g. ad hosters), it would still be possible to check for arbitrary conditions or restrictions respectively prior to delivery. The other pure erlang SWF library eswf places emphasis on SWF construction and related data formats (AMF, ABC).

Just in case you ever wanted to develop a web-application in Erlang and Javascript, you probably stumbled upon JSON-RPC. The idea of JSON-RPC is as trivial as it sounds: You assemble a JSON object describing a remote procedure call, which usually consists of a method name, parameters and a unique id for asynchronous calls. This might look like the following:

The string representation of a JSON object will then be sent to our yaws-JSON-RPC-server. The documentation describes a simple case which is always successful in returning the requested result. A JSON-RPC reply looks like this:

Using the recommended yaws_rpc module, our erlang program looks - in essence - somewhat like this:

out(A) ->
    ...
    yaws_rpc:handler_session(A2, {?MODULE, handler}).
handler(..., {call, login, Params}, .....) ->
    ...
    {true, 0, Session, {response, true}}.

Now we assume, that every once in a while your server function fails internally, let's say due to an unstable database connection. Naturally we have to reply with an error in this case. The error could - for example - be indicated by a HTTP return code other than 200 (200=success). The handler function of our server code would then simply return the error like {error, "message", 500} instead of {true, ...} (the last line). Alternatively the error could be coded into the JSON-RPC reply like so:

Unfortunately this error reply is not easily determined by the handler's return value using the yaws_rpc module, unless it's been patched: yaws_rpc.erl-1.73.diff yaws_rpc_fixed.erl

After applying the patch, a return value of {jsonrpcerror, 23, "this and that"} should do the trick.

I don't like mondays, ... humming even though it is thursday. What I do like, however, is erlang. This functional programming language has been around since 1987 and is still as up to date as it can get. The most prominent example of software written in erlang probably is ejabberd, the jabber server.

It has been argued that object oriented languages like Java might eventually render functional languages obsolete. Object oriented code resembles the reality where objects interact with each other. Each object has properties and functions altering these properties. On the other hand there is erlang, which can also resemble real life, only that the interaction is being emphasized. Erlang programs run in processes, commonly known as threads in other languages, which interact using messages. The message passing is built into the language, so that you would not need to write complicated networking code. Now, if we think about the processes resembling objects we'll end up in an object oriented concept - at least vaguely. ( what a comparison )

In the end erlang is a functional language mostly consisting of functions, not objects. Although it can be used for much more, in real-life it is used for - optionally distributed and event driven - server applications. In my opinion this is definitely worth a look for the open-minded developer.

A little programming example:

Bed time reading: erlang Publications