mirror of
https://gitlab.xiph.org/xiph/icecast-server.git
synced 2024-11-03 04:17:17 -05:00
77 lines
5.1 KiB
HTML
Executable File
77 lines
5.1 KiB
HTML
Executable File
<?xml version="1.0"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
|
|
<head>
|
|
<title>Icecast v2.x Documentation</title>
|
|
<link rel="stylesheet" type="text/css" href="style.css" />
|
|
</head>
|
|
<body>
|
|
<div class="boxtest">
|
|
<h1>Icecast 2 Relaying</h1>
|
|
<hr id='titlebar' />
|
|
<br />
|
|
<br />
|
|
<br />
|
|
<h2>Overview</h2>
|
|
<p>Relaying is the process by which one server mirrors one or more streams from a remote server. The servers need not be of the same type (i.e. icecast can relay from Shoutcast). Relaying is used primarily for large broadcasts that need to distribute listening clients across multiple physical machines.</p>
|
|
<br />
|
|
<br />
|
|
<h2>Type of Relays</h2>
|
|
<p>There are two types of relays that icecast supports. The first type is when both master and slave servers are icecast2 servers. In this case, a "master-slave" relay can be setup such that all that needs to be done is configure the slave server with the connection information (serverip:port) of the master server and the slave will mirror all mountpoints on the master server. The slave will also periodically check the master server to see if any new mountpoints have attached and if so will relay those as well. The second type of relay is a "single-broadcast" relay. In this case, the slave server is configured with a serverip+port+mount and only the mountpoint specified is relayed. In order to relay a broadcast stream on a Shoutcast server, you must use the "single-broadcast" relay and specify a mountpoint of "/".</p>
|
|
<br />
|
|
<br />
|
|
<br />
|
|
<h2>Setting Up A Master-Slave Relay</h2>
|
|
<p>In order to setup a relay of this type both servers (the one you wish to relay and the one
|
|
doing the relaying) need to be icecast2 servers. The following configuration snippet is used
|
|
as an example:</p>
|
|
<pre>
|
|
<master-server>192.168.1.11</master-server>
|
|
<master-server-port>8001</master-server-port>
|
|
<master-update-interval>120</master-update-interval>
|
|
<master-username>relay</master-username>
|
|
<master-password>hackme</master-password>
|
|
</pre>
|
|
<p>In this example, this configuration is setup in the server which will be doing the relaying
|
|
(slave server). The master server in this case need not be configured (and actually is unaware
|
|
of the relaying being performed) as a relay. When the slave server is started, it will connect
|
|
to the master server located at 192.168.1.11:8001 and will begin to relay all non-hidden
|
|
mountpoints connected to the master server. Additionally, every master-update-interval (120
|
|
seconds in this case) the slave server will poll the master server to see if any new mountpoints
|
|
have connected, and if so, the slave server will relay those as well. Note that the names of
|
|
the mountpoints on the slave server will be identical to those on the master server.</p>
|
|
<p>To extend on the idea of load sharing, it is possible for a slave icecast2 to communicate
|
|
certain information to allow for new listeners to be redirected from the master server to the
|
|
slave. In such cases, the master will send to the listener a HTTP 302 response code with a URL
|
|
of the slave server which has been randomly selected.</p>
|
|
</p>To enable this certain settings have to be enabled. In the master</p>
|
|
<pre>
|
|
<max-redirect-slaves>5</max-redirect-slaves>
|
|
</pre>
|
|
<p>This limits the redirection mechanism to 5 slaves, the default is 0, preventing any attempts
|
|
to redirect new listeners. In the slave </p>
|
|
<pre>
|
|
<master-redirect>1</master-redirect>
|
|
</pre>
|
|
<br />
|
|
<br />
|
|
<br />
|
|
<h2>Setting Up A Single-Broadcast Relay</h2>
|
|
<p>In this case, the master server need not be an icecast2 server. Supported master servers for a single-broadcast relay are Shoutcast, Icecast1.x, and of course Icecast2. The following configuration snippet is used as an example:</p>
|
|
<pre>
|
|
<relay>
|
|
<server>192.168.1.11</server>
|
|
<port>8001</port>
|
|
<mount>/example.ogg</mount>
|
|
<local-mount>/different.ogg</local-mount>
|
|
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
|
|
</relay>
|
|
</pre>
|
|
<p>In this example, this configuration is also setup in the server which will be doing the relaying (slave server). The master server in this case need not be configured (and actually is unaware of the relaying being performed) as a relay. When the slave server is started, it will connect to the master server located at 192.168.1.11:8001 and will begin to relay only the mountpoint specified (/example.ogg in this case). Using this type of relay, the user can override the local mountpoint name and make it something entirely different than the one on the master server. Additionally, if the server is a Shoutcast server, then the <mount> must be specified as /. And if you want the Shoutcast relay stream to have metadata contained within it (Shoutcast metadata is embedded in the stream itself) then the <relay-shoutcast-metadata> needs to be set to 1.</p>
|
|
<br />
|
|
<br />
|
|
<br />
|
|
</div>
|
|
</body>
|
|
</html>
|