Why Erlang Gateways? - Part 3

After protocol decoding and client implementation, the third major challenge was making sure the gateways were scalable. Each gateway instance must handle a large number of active client sessions and multiple instances must be clusterable using some form of session-based load balancing.

Every heysan user has a jabber account that is registered with one or more gateways. Upon login the jabber server sends a presence probe to each gateway which then connects the user to the appropriate legacy network. A client session consists three Erlang processes that communicate via message passing: socket reader, FSM, and translator of protocol-specific events into a common format. This style of concurrency oriented programming is very quite and elegant, but is not possible in many languages due to the overhead of native OS threads.

Erlang's SMP VM distributes runnable processes across all available CPUs. IM clients spend most of their time waiting on network IO, so the gateways run with the +Ktrue command line option which instructs the VM to use epoll/kqueue/poll rather than select() to efficiently determine which processes are runnable. We have yet to explore the limits of a single gateway instance, but our most popular network has reached > 700 active clients and load on the gateway server was very low.

Of course at some point a single gateway instance will become constrained by the finite amount of CPU power, RAM, IO bandwidth, etc available on a single server. So the gateways have been designed to support multiple instances running in a cluster. Persistent data such as user credentials are stored in OTP's distributed database mnesia and accessible from every instance. Our jabber server, ejabberd, provides built-in support for load-balancing sessions across multiple instances of a gateway. Bringing a new instance online is a simple matter of telling it to join an existing cluster and updating the ejabberd config file.

So, in the final analysis, Erlang/OTP served as an ideal platform for building jabber gateways. Which isn't particularly surprising since such a system isn't far from Erlang's original telcom applications, and ejabberd has already proven itself in large deployments. In upcoming posts I intend to discuss some of Erlang's other libraries as well as some of the difficulties encountered due to MSNP v15's extensive use of SOAP and XML.