Current version 2.0 (26 Sep 12)
Status:
4 stations,
1 listener
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
127.0.0.1.
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.