p2p streaming with Flash Player 10 (Proof of concept)

I have thought more deeply about the idea of creating a native FP10 p2p streaming network. I believe is really possible to exploit the new RTMFP protocol to create such a platform. But let’s start with a short intro about p2p networks.

peer-2-peer

I don’t want to bore you with technicalities (if you like them, take a look at this article on Wikipedia), here I want only to summing up the pro and cons of this technique for delivery data over the Internet.

The main pro of p2p delivery is, as you know, that data flow from client to client reducing the load of servers (which usually are still necessary as backup). The data-flows are distributed geografically, differently from the traditional client-server paradigm where the data-flows concentrate to a server and so to a specific region.

You know that this startegy is very good and cost effective for the distribution of generic content (who have never downloaded “something” in p2p with satisfaction ?), but what about AV streaming ?
The (bad) experience of well financed projects like Joost and Babelgum who attempted to create video streaming delivery platforms using p2p, teaches us that p2p has two worst enemies: the need of a specific plug-in/desktop app. and the too much low upload bandwidth available at consumer users.

The difficulties arise when you have not to simply deliver content to the user, but to stream it with a good QoS (Quality of Service), that is assuring a consistent experience, low latencies, a fast channel switch time and so on. It’s easier to stream live content istead of video on demand but also for live, with an average upload bandwidth in the range 200-400Kbit/s it is still not possible to trigger the “avalance effect” peculiar of the p2p paradigma for streaming contents which requires more than 500 Kbit/s.

Someone can say: “can we use multicast to reduce the load in AV streaming ?”. We could, but only a very limited portion of Internet infrastructures support efficiently this protocol; usually only private networks are really able to use multicast.

So p2p remain a very promising technology, probably the future for streaming, but today it is really difficult to make it usefull and profitable for AV streaming, similarly it’s difficult to use multicast.

Audio only streaming & p2p

But what about audio only streaming ? Audio only streaming is a completely different thing especially live stream (Internet Radio). Let’s suppose to handle traditional 128Kbit/s MP3 streams. A user can easly receive the stream and re-distribute the same packets to at last 2 different users using an upload speed of 256Kbit/s (indeed very common). This is sufficient to trigger the “avalance effect“, so a server can feed 100 users, they can redirect the stream to 100×2 users, these 200 users again can redirect and feed 200×2 users and so on. With only 100 concurrent connection to a central server, your p2p service serves 1000s users saving a lot of bandwidth and therefore a lot of money.

p2p with Flash Player 10

Streaming audio, a p2p network can leverage the avalance effect, so it remain only the second limit of p2p, the need of a new plug-in or desktop application. The idea is therefore to implement a p2p network using the new RTMFP protocol supported by Flash Player 10. If the p2p system could be implemented in simple AS3 code, without external plug-in, it would be the Columbus’s Egg for Internet Radio and suddenly, an immense number of nodes would be added to the biggest p2p network for audio streaming.

I continue to speak about audio streaming and not other data sharing, because of the security limitation of FP10, where you are not able to load or save data locally without the user intervention. Therefore is quite difficult to implement the behaviour of a standard file sharing application. So let’s start from the simpliest p2p network.

The rule of RTMFP

RTMFP (read the previous post for detailed info) permits a FP10 swf to connect to another FP10 swf using a client to client UDP connection. You need a support service (Stratus) to initiate the connection, but the communicaton is then hold on between the two connected clients using the traditional NetStream API. As you know, NetStream has a “send” method which can be used to trigger a call-back on the subscribers. A send can also be used to transport a packet of data, as it supports all the AMF3 data types, in particular bytesArray.

Proof of Concept

So in short the idea is this:

1. INPUT BLOCK. An swf client receives an MP3 packet stream from a source. There are several possible sources. It is possible to read an MP3 locally, receive it from an HTTP binary request or from a RTMFP (an MP3 can be splitted in small chunck and sent using send method, read more over, point 4) or also receive it from a socket connection. It is not possible to access mp3 packets from a RTMP connection today but we can suppose eventually to implement a simplified RTMP client in AS3 + socket to circumvent this limitation.
In any case this block manages the input connection and every time interval produces a BityArray in output containing a number of MP3 packets.

2. MUX/DEMUX BLOCK. This block of code receives data packets from the INPUT BLOCK and mux or demux them in the necessary container format. For example, the PLAYOUT BLOCK needs a complete MP3 file with headers and the like, so this block of code must compose a buffer of MP3 data (a few seconds), rebuild on the fly the header for that portion of audio and send it to the PLAYOUT. Data packets are sent to OUTPUT BLOCK in demuxed format (raw packets), so in this case the block works as a buffer.

3. PLAYOUT BLOCK. This block receives a complete MP3 file (a few seconds long) from the MUX/DEMO BLOCK. Then it uses the new “extract” method of sound object to decode the MP3 audio data to raw wav data and inserts it in the sound card ring buffer (read Tinic Uro’s Blog to know more about this new FP10 possibility).

4. OUTPUT BLOCK. At the end, this block fetches the MP3 packets from a buffer and sends them to 2 or more p2p connected clients. The packets can be aggregated in a byteArray and sent using the send method of the RTMFP netConnections.

5. CONTROL BLOCK. This block holds the network intelligence. A specific protocol is used to discover the nearest client nodes and to establish several RTMFP connections. It can be usefull to establish backup connections both in input and in output to compensate for temporary or permanent unavailability of a node.

That’s all, what do you think about it ? Someone is interested in trying to implement a such schema ? Mail me with suggestion.
In the meanwhile, I’m starting to code…