Table of Contents
To use and configure the FreeCast node, you need to understand a part of the internal components.
The peerprovider component manages the connection
between the node and the tracker. It must be configured with the tracker's TCP address.
The sender component listens to requests from other
nodes (peers), manages the opened connections and controls the sending of data. The
udp sender implementation uses a TCP socket by default. The
none sender implementation disables the node relaying (..
discouraged).
The udp sender implementation waits for UDP
connections initiated by other nodes. Once a connection is opened with another node
(peer), the sender forwards the received streamed data to this peer.
Via the connection assistant, the udp sender is reachable even behind a NAT (NAT traversal).
The node reference is used to localize it over the network. The default reference specifies the IP address and UDP port where the node waits for connections from other nodes (see the section called “UDP sender”).
By using stun reference, the FreeCast node
determinates its public address (and natted UDP port) via a STUN request.
The stun reference configuration allows to specify the
STUN server to be used.
Node local addresses will be determinated automatically to make the node reachable in the local network(s).
![]() |
NAT traversal |
|---|---|
|
A node must use a |
The reference can be specified manually via an
inet reference by giving host and port.
Take care by using an inet reference, if the specified
information is wrong, the node won't be reachable.
You can specify several references. It allows the node to be available from several IP addresses. For instance, you can specify a reference with the public IP address, and another with a local network address. Your node will be available both on Internet and on your local network.
The auto reference is obsolete, use stun reference instead. See the section called “stun
reference”.
The receiver component manages the stream reception.
According to the implementation, the stream can be received from other nodes (peers) or
created by the node (root node) from a classic Ogg stream.
The peer receiver component receives the stream from
other nodes (peers). It doesn't require any configuration. It will use the tracker to
find other nodes.
The shoutclient receiver component opens a connection
on a shout server (like icecast or fluemondo) to retrieve an audio or video ogg
stream.
The shoutclient receiver configuration defines the URL
where the stream can be received.
The shoutserver receiver component acts like a shout
server. It can receive an audio or video ogg stream sent by a tool like ices2 or
oddcast.
The shoutserver receiver configuration defines the
listen address used to wait for the shout connection.
The playlist receiver component uses a M3U playlist which lists the ogg
files to be read (a file per line).
The playlist receiver configuration contains the URL
where the playlist can be found.
The encoder-playlist receiver component uses a
M3U playlist which lists the
files to be read (a file per line). By default, wav, ogg and mp3 files are supported.
The Ogg stream is created via a native library which depends of the runtime platform. For the moment, the library is available for linux x86 and windows platforms.
The encoder-playlist receiver configuration contains
the URL where the playlist can be found and stream encoding parameters like wanted Ogg
quality, channel count and sample rate.
The checksummer and validator components are used to validate the relayed nodes into each
listener node. The checksummer is deployed into the root
node in order to add a verifiable information to each packet (checksum). The validator is used by each node listener to verify the checksum of each
packet. According to the chosen implementation, it allows to verify that:
the network transfert doesn't corrupt the packet
the authentification is created by the root node
Every packet that is not validated by the listener node will be skipped. It won't be played and relayed.
![]() |
Root and listener compatibility |
|---|---|
|
Remember that the validator configuration of the listener node must be compatible with the checksummer configuration of the root node. Otherwise, all packets will seem invalid to misconfigured listeners. |
Deployed into the root node, the digest checksummer adds a checksum to each packet (using the SHA
algorithm).
Deployed into the listener nodes, the digest
validator verifies that the packet data still matches
this checksum.
No specific configuration is needed
Deployed into the root node with a given private key, the signature checksummer signs each
packet with an encrypted checksum (using an RSA private key with the SHA algorithm).
Deployed into the listener nodes with the associated public key, the signature validator verifies that the
packet data still matches this digital signature.
To create a key pair, use the freecast-keygenerator tool:
[host:~] freecast-keygenerator Generate a RSA 1024 keypair Write private key to freecast-private.key Write public key to freecast-public.key Take care to the private key file securityThen, you can use the two created files. Take care to protect the private key file.
The FreeCast nodes can connect through NATs by using the connection assistance service (which is started into the FreeCast tracker).
By default, FreeCast nodes use the connection assistance service available at cas.freecast.org on port 1666. The node configuration allows to specify the wanted connection assistant. You can use the connection assistant service provided by your tracker. See the section called “Connection Assistant Service”.