Skip to content
This repository has been archived by the owner on Sep 25, 2023. It is now read-only.

Distributed Chat

py8765 edited this page Oct 26, 2012 · 35 revisions

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:

uberchat

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:

multi chat

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

Clone this wiki locally