Internet Radio System

This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.

This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.

There are two popular schemes by which a low-budget radio station could broadcast on the Internet: Real Audio and Napster. The problem with Real Audio is that you need a massive server with a fat Internet connection to distribute packets directly to every listener in real time. The problem with Napster is that you can’t deliver in real time and you can’t guarantee that people will always be able to find a given program.

This project is to invent a new distributed protocol for Internet Radio that requires only a modest server no matter how many listeners there are.

The key notion is that every listener also acts as a relay station to other listeners. Ideally every listener could relay to several other listeners, but in practice you will be lucky if any one listener can even provide the bandwidth to handle one other listener. The central problem is user uplinks are usually slower than downlinks. The other major problem is that a chain is only as strong as its weakest link.

By creating daisy chains of user listener stations relaying the packets, you might be able to create a very long chain and still deliver packets with only a 5 minute delay, possibly sufficiently real time for a phone-in radio talk show.

Stations that are not receiving packets would nak the central server to request being added to a different chain, or to pick up a missed data packet from some other chain that still has that packet in transit. If a user had a fast Internet connection, they could relay to several other listeners instead of just one. You might find volunteers willing to host relay software on servers to act as primary relays.

The central server sends administrative packets directly to listeners requesting them to relay packets to other IPs. It sends the bulk of the traffic indirectly by daisy chains. Listeners with faster links are put earlier in the chains so they can increase the fanout early on where it has maximal benefit. This way the central server need not have all that big a bandwidth connection to the Internet. The server can request that relay stations sometimes send ack packets back to the central server to monitor the progress of packets down the chains. These administrative packets can be very small, e. g. every 10th hop might trigger an automatic ack home.

For this to work, you need super compression. Think about voice only. Commercial music radio can afford Real Audio. Political/issue talk radio cannot. Perhaps there is some research on voice compression which models the vocal tract and recreates the voice from phonemes or other digital clues. At the very least, you would do MP3 compression on each jumbo packet.

The downside of this protocol is that when you first tune in, you might not hear anything for five minutes or so. It needs a very large amount of buffering to deal with the flakiness of the relay scheme.

If you solve this, one of your first customers might be infidelguy.com among many others. It is important to get all points of view heard, even those you disagree with. You can’t very well move forward into this complex new age with confidence until all voices have been heard.

I later learned there are already implemenations of this idea. The official term for it is P2P radio. Since I wrote this, BitTorrent was invented, which works along similar principles. BitTorrent itself might be used to distribute non-real-time broadcasts. Youtube has taken to hosting free in return for inserting advertising, so that take the urgency off this project.

	This page is posted on the web at:	http://mindprod.com/project/internetradio.html
	Optional Replicator mirror of mindprod.com on local hard disk J:	J:\mindprod\project\internetradio.html
	Please read the feedback from other visitors, or send your own feedback about the site. Contact Roedy. Please feel free to link to this page without explicit permission.
	Canadian Mind Products IP:[65.110.21.43] Your face IP:[18.191.202.45]
Feedback	You are visitor number

Internet Radio System

Disclaimer