How it works
Advanced config

Broadcast help
Get your Streamer Widget

>>> more Info <<<
Iain's BLOG
Version History

Spheres of Chaos


#Resistance is not futile
p2p radio
Current version 2.20 (26 Sep 12)
Status:  netstatus 15 stations, 21 listeners 

How it works

With conventional internet radio each listener (red) connects directly to the broadcasting server (green), like in the image on the left. If the station has a lot of listeners then it needs a lot of server bandwidth to send the stream to them all, which usually costs money. If the server is using all it's bandwidth then no more listeners can tune in.

Streamer on the other hand forms a network that looks more like the image on the right. The listeners relay the stream on to more listeners, and the broadcast server only needs to send the stream to a few of them, so needs less bandwidth. There is no theoretical limit to their number because there is always spare bandwidth at the edges of the network. Each listener must have enough upload bandwidth to relay the stream of course or the distribution tree can't form.

The network/tree gradually shuffles it's connections around, bringing the higher bandwidth relays closer to the broadcast source to act as a backbone, with all the low bandwidth / modem users on the outer edges of the network.

Listeners disconnect politely when they leave, waiting for their downstream clients to find alternate sources before disconnecting them. There is also a large internal buffer to cope with the upstream source vanishing unexpectedly, and it also masks temporary net congestion.

Streamer uses UDP to deliver the stream data, and does not slow down because of large ping times, or suffer the uploads and downloads clashing effect that TCP sometimes exhibits.

It keeps a list of 1000 other hosts, and randomly throws a request for either more hosts or info about stations, to one of them about twice a second. Non-answering ones get removed after a while, and there are several 'seeds' preset in the list for it to connect to the first time it is run.

The stations list builds up passively as other Streamers send info from their own lists. The actual info sent is chosen randomly, but all Streamers soon get all the stations. They are ranked by listeners in Streamer's display, and that is counted from how many others yours can talk to that are tuned to each station. Stations with no hosts tuned to them are deemed offline, and are sorted by last time seen alive. After 2 hours they are removed.

When you double click a station in the list (or click a 'streamerp2p://' style url on a web page) Streamer starts asking other hosts if they can supply the stream. It mainly asks ones who are on the required stream, but also ones who are not more slowly, in case they have changed stream recently. Usually you get a feed within a second or so. Streamer will then begin playback if the internal player is selected, or make a '.pls' file and run it (as if it was clicked on). This makes Windows run the default 'owner' of pls files (winamp/media player/realplayer etc), which then reads an IP from the file and tries to connect to get the stream from it. This is the standard way net radio works, but in this case the IP in the pls file is your PC or what is commonly referred to as localhost or

It works transparently on Local Area Networks(LANs) and through Network Address Transtation(NAT) routers etc, for both broadcasting and listening. Streamers on seperate LAN/NAT or behind some firewalls can connect directly, which eliminates the problem of the firewalled host effect. A stream will not become unavailable because all feeds are disappearing into lans which then can't send them out again. Broadcasting from a lan is fine, even without port forwarding. It also tries to find feeds from inside the same lan to reduce the total traffic in and out of the lan.

If you are on a lan and can set up port forwarding, then you will not need the help of a proxy, and also make the best possible proxy for any other Streamers on the same lan. A proxy is a volunteer Streamer that is used to open connections into a lan that can normally only make outgoing connections. This is always true of NAT, because the pc inside the lan will have a private IP address that is not routable from outside the lan. So a Streamer on a lan contacts another outside the lan, or a special case one on the same lan, and asks it to volunteer for proxying. The lan Streamer puts the proxy's IP in it's own info that is passed around the net. When another Streamer wants to make an incoming connection to the lan, it sends a message to the proxy, who then sends it to the lan host through it's persistantly open connection. The lan host then sends the reply directly to the IP:port that the proxy saw the message come from. This opens a 2 way path in the nat for Streamer communication. Messages going inwards are sent to the port the router assigned, and if the second Streamer was also on nat and having ports changed in it's messages, the replies will also be being sent to a router assigned port. Even if the proxy is on a different ip from lan host 1, the replies lan host 1 sends to lan 2 are allowed in by the router, so a bidirectional connection is set up with router assigned ports being used on both ends, and TCP can't do that.

Sometimes a router will give port forwarding to one pc if it is the only one using that port, which is very handy. The first Streamer gets 8466 directly, doesn't need and can be a proxy itself. A second Streamer will have the port used for it's messages reassigned by the router, so it cannot be contacted from outside the lan, and will automatically try and get a proxy on the same lan, and it should choose the first Streamer.

The bandwidth test in Streamer is necesarry because if a Streamer tries to send more feeds than it is actualy able to, downstream listeners will get buffering. If I try to send even a few % more data through my cable modem than it is capped at, almost no data actually gets through ok. 128k of something arrives at the other end, but it's not recognised as valid packets anymore by the receiving Streamer. (Caping bandwidth by mangling the data but still sending it out, seem to me to be a silly way to reduce the overall data on an ISP's network.)

Streamer will accept encoded stream data from all the popular broadcast tools, Oddcast, Shoutcast, Sam, etc, and play back those formats internally. At the moment mp3, mp3pro and Ogg Vorbis are supported. Decoding of mp3Pro however is limited to external players only.  More formats are planned for inclusion into Streamer in the future.

Streamer was originally inspired by a large webcast that failed because the centralised servers got swamped, and I thought 'all the listeners have upload bandwidth that could be used'...

It was published in anger when the superb Audiogalaxy was assimilated by the Borg, coincidentally at the same time as the CARP royalty rates scam happened in the US (scam, because the purpose appeared to shut down all independent webcasters).

It was also envisiged as a potentially anonymous system, although currently it can be fairly easily traced and it is not at the moment being developed to be stealthy.

© Iain McLeod 2003-2012.
"And the meek shall inherit the Earth" (Rush/2112)

Hosting by KMeat Hosting