Topology of the network
Contents
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 :
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.