Topology of the network

Context And Goals

This tasks is intended to address and fix some problems inherent to GISS 2.0 which was based on a centralized topology with one central access point, the master server ( giss.tv ). This topology was leading sometimes to a saturation of the system as all the sources could only emit to the central server which upload bandwidth was limited and sometimes got saturated.

Work achieved

Upgrade of servers

First, before changing the topology, we started by upgrading our servers to make all software servers coherent. The main server has also been migrated to a more powerful machine ( courtesy of hangar.org ). After the cleaning up of the servers, we reached this configuration :

List of servers before reconfiguration

Name	Location	Icecast Version	Mode
giss.tv	Paris, France	Icecast 2.3-kh34a	Primary
stream.r23.cc	Bergen, Norway	Icecast 2.3-kh34a	Relay
thescreen.tv	Vienna, Austria	Icecast 2.3-kh33	Relay
whitmanlocalreport.net	New York, USA	Icecast 2.3.1	Relay
live1.radiovague.com	San Antonio, USA	Icecast 2.3-kh33	Relay
live2.radiovague.com	San Antonio, USA	Icecast 2.3-kh20	Relay
stream.goto10.org	Amsterdam, Netherlands	Icecast 2.3-kh33	Relay
labbs.net	Malmö, Sweden	Icecast 2.3-kh20	Relay
stream.horitzo.tv	Berlin, Germany	Icecast 2.3-kh20	Standalone

As you can see, we had one primary server and 7 relays, stream.horitzo.tv is a standalone server but all its activity appears in the map also.

Setting up a secondary server

When a clean list of servers has been established, we installed one of them as a secondary server by doing a database link between the primary and the secondary server, this means that all mountpoints created on the primary server ( giss.tv ) are now also known of the secondary server and thus, a source can emit to a server or the other one.

The database link is a scheduled task that updates mountpoints both en the primary and secondary servers.