[icecast-dev] p2p streaming?

Alex Strasheim alex at strasheim.org
Tue Jul 10 09:19:05 PDT 2001



I'm new here, and I hope this isn't too flaky for the list.

I've been thinking about whether or not it's possible to combine p2p
techniques with streaming media to reduce the load on the server that's
originating the feed.  It seems like an obvious idea, so I doubt it's new.
But I haven't seen anything that suggests that anyone's working on it.

The win from this is pretty obvious -- it would be economically possible for
an individual to stream out to a mass audience.  Something like this is
necessary to break the stranglehold on media distribution that large
companies have now.

The basic idea is that if you're going to listen to a stream, you'll have to
pass it on to other people as well.  The central problem -- which is hard to
solve, but hopefully not impossible -- is reliability.

I don't have any expertise in designing protocols or in error correction,
but I was thinking about a system that would use central servers to organize
the topology of the streaming p2p network.  Because the network would be
tree-like, more or less, the central servers ought to be able to scale.

When you wanted to listen to a stream, you'd talk to a server that would
tell you who is going to feed you and who you have to feed.  I was thinking
that the stream could be cut up into slices, and that a little redundancy
could be added so if someone feeding you dropped out you could recover.
You'd get fed from several people, and you'd feed several people, with the
bandwidth on each slice a fraction of the full stream's bandwidth.  If
someone dropped out, you could still construct the feed out of the streams
you have left, and talk to the central server to replace your incoming
slice.

This is still simplistic -- people will probably drop out all at once when
content changes, so error recovery designed for random failures probably
wouldn't work.  If we were streaming a TV station, for example, a lot of
people might drop out at the top of an hour when one program ends and
another one starts.  But I think problems like this could be solved too,
perhaps with some sort of reputation system:  People who don't disconnect
without giving folks upstream time to make other arrangements could be put
into slots that are higher up the tree, and more reliable.  Unreliable nodes
would tend to be leafs, and would have to live with service that's less
reliable.

There are other issues:  timing, keeping people in synch, and the issue of
wasting network resources by having a p2p topology that doesn't have
anything to do with the physical network topology, to name a couple.  But I
think they can be solved.

Does this make any sense at all?  Has someone else thought of this more
deeply, and is anyone working on it?  It seems like an obvious idea.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Icecast-dev mailing list