ejabberd is a powerful and flexible tool to build large scale chat / Instant Messaging systems. It is used to power many of the largest Instant Messaging deployments in the world. In ejabberd 2, you will have more options to tune and architecture your Instant Messaging environment to adapt to any real life production situation.
Epeios: A first step toward fine-grained IM architecture
Building a powerful chat system for a web company is a demanding task because you need to provide a scalable system where components can be organised on the largest possible cluster, with the finer possible granularity. We made a first step with Epeios. Epeios allows you to run ejabberd components on any XMPP server. It also allows you to run those components outside ejabberd, on a separate server.
In which situation is this useful ? For example with Epeios, you can run several instances of the same ejabberd component without increasing the number of pure ejabberd nodes.
FlexArch: an architecture with finer grains
With our brand new architecture called FlexArch, we have pushed the idea further. FlexArch is a concept that includes and embraces Epeios. The main idea behind our change is to have independant components that you can gather, move, or rewrite depending on the project needs.
Example: Separation of connexion management and session management
In ejabberd 1 architecture, large parts of the software were monolothic. It was not possible to easily separate (i.e. with a configuration file) the connection manager and the socket manager, that are doing mostly house keeping tasks, from the core ejabberd, that need to focus on messages handling and processing.
The architecture of an ejabberd cluster and the flow of messages from client 1 to the client 3 (connected on different cluster nodes) are shown on the following diagram (simplified view):
With the Flexarch model it is possible to break the client manager into two parts:
- Connexion management and parsing
- Session management
The connexion and parsing can even be moved to one or several front-end computers. The architecture is efficient as it does not introduce any double parsing: front-ends and back-ends are exchanging parser XML data structures.
With this approach, the load and memory consumption can be distributed in a better way, between the front-end and the back-end systems.
The distribution mechanisms are relying on Erlang, so you can easily define your own balancing algorithm and you do not have to obey to a 1 to 1 mapping between backend and frontend.
Another strong advantage is that you can improve the fault tolerance mechanism in this approach. It is actually possible to write some code that keep the XMPP TCP connexion on the front-end but could survive to a loss of the back end managing its session (by “migrating” the process).
This component separation can be mixed with Epeios to increase flexibility. ejabberd keeps on relying on its unique clustered router, with no single point of failure.
By introducing Flexarch, we move further in term of components separation and scalability, while keeping the same level of reliability on the routing nodes. ejabberd is thus becoming even more flexible, making it the tool of choice for large and ambitious web chat architectures. If you add that to the fact that some components can become optional or can be rewriten to change their behaviour you know why ejabberd is becoming increasingly popular to develop interactive web applications and social networking tools.