We have finally made the switch from the async_events branch to master. This branch includes a host of new features that make Licode more potent, configurable, scalable and stable than ever!
Here we will discuss the new distributed MCU architecture. As you know, erizo was a single process started with erizoController, the whole MCU is a single process. From now on, each publisher in Licode will have its own process in the Licode server.
What once was the erizoController process has been divided into three components. These new modules follow the same design philosophy we use in all Licode, they can be deployed separately in different machines or together. This components are:
ErizoController: The good old erizoController, it still has the same function in terms of control and signalling.
ErizoAgent: This new component is in charge of starting new processes. Any machine running erizoAgent will be able to host resources for the distributed MCU by starting and stopping ErizoJSs. These ErizoJSs can be started on demand and/or have a pool of pre-started ones.
ErizoJS: A single broadcaster of the distributed MCU.
This iteration in the architecture brings many new features. Let’s go over some of them:
Improved Scalability: A single Licode Room can be now easily distributed among an array of servers. By starting erizoAgent in different machines and configuring them properly, the workload of a room will be intelligently distributed.
Improved Stability: Before, an irrecoverable error caused by a single stream could potentially bring down erizoController, shutting down all the rooms managed by it. In the new distributed architecture, a fatal error in a stream will only shutdown that stream, while the rest of the room(s) keep working.
Configurable: You can manage this behavior in the revamped Licode configuration file (licode_config.js):
config.erizoAgent.maxProcesses: The maximum amount of ErizoJSs this particular ErizoAgent is allowed to start.
config.erizoAgent.prerunProcesses: The amount of prestarted processes ErizoAgent will have at all times.
Some of the other new features have already been documented in our Server and Client API Doc pages, or even in this blog:
To ease the transition, we will move the current master branch to legacy in our github repository. As always, feel free to write in the list with any problems, suggestions or ideas you have!