The Module Header

First off I define the module, which is named echo and so it should go in the file “echo.erl”. Then I export the functions that make up the server. The last line of the header defines a constant called TCP_OPTIONS with a value which is a list of options which will be used by the sockets in the server program. This constant may be used in code later as ?TCP_OPTIONS (note the question mark). The options are as follows:

binary

Data received through the sockets should be in the form of a binary object. There’s no need for me to cover binary terms right now, as they aren’t really covered in this example.

{packet, raw}

The data received should just be the raw data. It is possible to have the data delivered with a header specifying how much data was received, but I don’t want that here.

{active, false}

Data will only be read when requested by the program. It is possible to have the data delivered to a process in the form of a message, but again that isn’t what is wanted here.

{reuseaddr, true}

This makes sure that the listening socket can be bound even if there is already a socket bound there. This prevents errors if the server crashes and is restarted before the original socket becomes properly closed.

Starting the Server

This function starts the server. It takes one argument which is the port to listen for connections on. First it calls the function listen from the gen_tcp library with the port number and the TCP options constant as defined in the header. This attempts to open the listening socket.

If this succeeds, spawn is called to create a new process. The three arguments to this function are the module in which the function to run in this new process resides, the name of the function and a list of arguments to the function. In this case the function is called handle_connections and it is in the current module (?MODULE is a macro which is replaced with the name of the current module). We pass the listening socket opened with gen_tcp:listen to the function.

If opening the listening socket fails, we call io:fwrite to write an error message containing the reason for the error.

Handling Connections

This is the function that is run in a process created by the start function. I takes as an argument a listening socket to listen for connections on. This function calls gen_tcp:accept to accept a connection from the listening socket. Again if this results in an error we print a message. If it is successful, a new process is started to handle the client that connected. This runs the function handle_client in the current module and passes it the client socket as an argument.

Once this function has completed, it calls itself again with the listening socket. As Erlang provides no looping constructs, loops are created by recursive calls. As long as the call to the function is the last line executed in that function, this will not cause stack problems as it would in many languages such as C and its derivatives. This function keeps accepting connections and spawning client handler processes until the process it is running in is killed.

Handling Clients

This is the function spawned whenever a client connects to the server. It first attempts to receive some data from the client socket passed to it with the gen_tcp:recv function which takes the socket to receive from and a number of bytes to receive. As we want to receive all available data, we pass 0 which means there is no specified maximum number of bytes to accept.

If successful, the data is sent back to the client (this is what the echo server is designed to do) with the gen_tcp:send function. The function then calls itself to create a loop as with the connection handler. Here the recursive call is not the last line of the function, but as none of the rest of the code in the case statement will be run if the data is successfully received, it is the last line executed. There are therefore again no problems with the call stack overflowing.

If the result {error, closed} is obtained, this means that the client has closed the connection. This is normal behaviour, so no error message is printed, the function simply exits and the process will stop. Unfortunately, the case statement must evaluate to a value, so it is necessary to give a value here. In this case I have chosen ok although any value would do.

The final part of the case statement prints an error message again if there was a problem receiving data from the client. It is assumed that this error is fatal and so the process stops.

The Complete Program

Here is the complete code for the program, put this in a file called “echo.erl”. To run it start an Erlang shell in the directory where you have saved the file and run the following two commands to get it started:

This will start the server listening for connections on port 1234. You can then connect to it via telnet or something similar, anything you send to the server should be echoed back to you. There is no way of stopping the server appart from killing all the processes that are handling connections and clients so it’s probably easier to just to close Erlang down.

This is a basic “Hello World!” program, don’t miss the full stops, they’re very important. The first line defines the module that is provided in this file. The file and module name must be the same, so this would go in the file hello.erl. On the next line, the functions that this module provides are given, in this case a single function called hello which takes 0 arguments.

Next the hello function is declared, the code which makes up the function follows the arrow ->. This calls the function format, from the module io, which takes a string and outputs it to the terminal.

To run this code, we need to start erlang in a terminal, compile and load the hello module and call the hello function from within it. This should go as follows:

The Erlang shell is started from the command line by running erl, then we call the compiler with the built-in function (BIF) c with the argument hello, which compiles the module and loads the compiled code for use. Assuming this is successfull, the function returns a tuple consisting of two elements. The first is ok, which means that the action was successful and the second is the name of the compiled module. This tuple value is printed to the terminal before the shell returns to a prompt.

Finally we call the hello function from the module hello with no arguments, which prints the line “Hello World!” to the screen followed by a newline. This function returns the value ok which is then printed before the shell returns to the prompt.

NOTE: Exiting the Shell

Getting out of the Erlang shell is slightly more complicated than you might expect. Unlike most shells where a simple Ctrl-D will signal the end of input and get you out of there, you must press Ctrl-C to cause a break in the Erlang virtual machine and then press “a” and return to tell it you want to abort execution and quit the program.

First Attempt

This takes the basic definition of Fibonacci numbers and translates it into code. The first two numbers are both 1 and any following numbers are equal to the sum of the previous two numbers. As this function calls itself recursively twice, it is very slow and ends up preforming the same calculations twice if a number greater than three is passed as an argument.

An Improved Algorithm

This function uses another “fib2″ to calculate numbers past the first two. This new function calls itself recursively, but keeps track of the last two numbers in the sequence in the first two arguments. This means that it only needs to perform a single call to itself, drastically reducing the time taken to calculate the values. The final argument simply counts down to let the function know when it has finished and to return the sum of the last two values.

Speed Comparison

I timed the running of both algorithms on my laptop (not the most powerful computer, but I think it still shows the speed difference). With the first algorithm, calculation of the 30th Fibonacci number took 16 seconds. With the second, it took only half a second. In fact in the time it took the first algorithm to find the 30th number, the second algorithm could compute the 120,000th number in the sequence.

These comparisons were done without compiling the code, so there would be some interpreter overheads involved, but as shown, these overheads had only a small impact on the overall run time.

The first line says that this is the Main module of the program being compiled. The next line main :: IO () declares a main function which performs IO operations and returns nothing, shown by the symbol (). The function main in the module Main is where the program execution begins.

These first two lines are actually omissable as the compiler assumes that unless specified, we are in the Main module and it can guess the types of functions from their implementations.

The final line specifies what the main function actually does. It performs the action putStrLn (print a string and then a newline) on the string “Hello World!”.

To compile and run this program using GHC (Glasgow Haskell Compiler) simply put the code in a file called “hello.hs” and type the following at the command line:

The next thing I usually write in a new language is a program to calculate numbers in the Fibonacci sequence, for which I have an easily understood program and a much faster algorithm which I will write about next time.