Scalability and load balancing

Scalability and load-balancing

Presentation

Even if RTMFP is a P2P protocol, RTMFP has need to have a server end-point to negotiate the P2P connection between both clients. Then, RTMFP can be used just for its UDP based abilities, like real-time video/audio streaming, in a classical client-server way (without using P2P feature). For these reasons, server load is always applied and central availability required. Of course, one machine has always some hardware limitation (CPU/memory), and when load required becomes too important, a CumulusServer instance can not be enough.

To solve this loading requirement, a full framework included in CumuluServer allows to make communicate multiple CumulusServer instances, to enlarge computing and receiving capacity. It allows to configure a multiple CumulusServer environment, it offers detection of server connection and disconnection, exchange of data between them, redirection of clients between servers to deploy a load-balacing software system for example, and some well-thought features to synchronise client informations for the rendez-vous service and the NetGroup RTMFP options. Every communication between servers is done in a raw TCP way.

The main idea is simple: by default, each instance is an independant server and share nothing with others, it's you who decides what are the resources that it has to share between all the server instances.

This page intends to describe every features of this framework illustrated with some code samples and context usage. Of course, the Server Application, API page lists all these feature but without code samples or any utilization context.

Configurations

Firstly to make communicate many instances of CumulusServer, you have to configure them. These configurations are grouped in the servers sub part (to know how using configuration file, read Configurations part of Installation page). Here follows a description of each of them:

• servers.port, port choosen to accept a CumulusServer connection. If you don't configure this port, no one CumulusServer can etablish a connection with it.

• servers.targets, list of CumulusServer addresses (separated by commas) to connect. When the server will start, it will try to etablish a connection to these addresses every 10 seconds.

Warning Exchange between servers is done in a uncrypted TCP way, so to avoid an attack by this incoming end point the servers.port should be protected by a firewall to allow just a connection by an other server and nothing else.

• servers.publicAddress, address like it will be seen by clients, this option is mandatory to make working all redirection features.

Here follows an illustration of one configuration with two servers:


Here follows a file sample of one configuration with two targets, but without incoming port configuration (this server can't be a target of one other).

	; CumulusServer.ini
	publicAddress = www.myhost.com:1935
	[servers]
	targets = 192.168.0.2:1936, 192.168.0.3:1936

Exchange data between servers

CumulusServer allows to custom its behavior by way of scripting, and

	function onServerConnection(server)
		-- RPC function declaration, called by one other server
		function server:onHello(name)
			self.name = name
		end
		-- send my name to this server (it will receive it on its "onHello" method)
		server:send("onHello","CumulusServer")
	end
	...
	-- anywhere you can find name of each server now
	for index,server in cumulus.servers:ipairs() do
		NOTE("Server '"..server.name.."' at address "..server.address)
	end