Distributed Chat

Why chat?

Pomelo is a game framework, why the tutorial starts from chat?

Pomelo is really a game framework, but it is essentially a high real-time, scalable, multi-process application framework. In addition to the special part of the game library in the library section, the rest of the frame can be completely used for the development of real-time web application. And compared with some node.js high real-time application framework such as derby, socketstream, meteor etc, it has a better scalability.

Because of the complexity of the game in scene management, client Animation, they are not suitable entry level application for the pomelo. Chat application is usually the first application which developers contact with node.js, and therefore more suitable for the tutorial.

Generally the entry application of node.js is based on socket.io development of ordinary chat rooms. Because it is based on single-process node.js development, it hit a discount in scalability. For example, if you want to improve it to a multi-channels chat room like irc, the increase number of channels will inevitably lead the single-process node.js overloaded.

From a single process To multi-process, From socket.io To pomelo

A native chat room application based socket.io, take [uberchat] (http://github.com/joshmarshall/uberchat ) for example.

Its application architecture diagram is as below:

The server which only contains a single node.js process receives requests from websocket.

It has following disadvantages:

1. Poor scalability: only support single process node.js, can not distribute according to room/channel, and can not separate broadcast pressure from logic business processing either.

2. Code redundancy: make simple encapsulation of socket.io, and only the server side contains 430 lines of code.

Using pomelo to write this framework can be completely overcome these shortcomings.

The distributed chat application architecture which we want to build is as follow:

In this architecture, the front-end servers named connector is responsible for holding connections, the chat server is in charge of processing business logic.

Such scale-up architecture has following advantages:

• Load separation: The architecture totally separates the connection code from the business logic code, and this is really necessary especially in broadcast-intensive application like game and chat.Intensive broadcast and network communication consume large amount of resource, however, the business logic processing ability will not be influenced by broadcasting because of the separated architecture.

• Simple switch: Users can switch channels or rooms that do not need to reconnect websocket because of this separated architecture.

• Good scalability: We can launch more connector processes to deal with the increase of users, and use hash algorithm to map channels to different servers.