Flash 10 p2p and CDNs – Deeper Analysis

Yesterdays piece on Flash 10 received lots of interest and generally a great response. However there were a few complaints about the fact that the Adobe press release didn’t actually say p2p, or that the Amicima technology was only about VOIP, etc.

One esteemed member of the Flash community and old friend, Brian Lesser, a Flash server guru and author of Programming Flash Communication Server suggested in the comments to yesterday’s article that there might be restrictions on p2p usage that might limit some of the CDN possibilites I described yesterday.

On the other hand the piece did get some great coverage over at GigaOM from the likes of one of my blogging heroes, Om Malik, who essentially concurred with my assessment of the import of all of this. And so given the high level of interest, I thought it would be useful to do a deeper dive into the subject and respond to some of the commentary.

1. Adobe didn’t make any announcements about a CDN.

This is true, but it is not the point. My point is that developers will be able to build p2p networks on top of Flash 10. Flash 10 provides low-level tools that are the core of what p2p is about. NAT traversal and the general ability to connect one Flash client to another is all that is required. In this case, the p2p coordination of this will be based around Adobe’s Flash Media Server, or perhaps open source Red5 once they figure it out. In any case a server of some sort will be required for any of this to work to serve as the central hub for establishing connections.

We don’t know the details of how discovery will work, but presumably Flash clients will register with a server, and then it will be possible for registered clients to connect with each other. This core functionality will allow p2p CDNs to be built.

2. This technology is only UDP or only for VOIP and so can’t be used for files.

Bits are bits. I am quite sure that RTMFP (the protocol that is responsible for these p2p services) does not specify that it can only be used to deliver voice, and not data files or video. This would be stupid and based on the current Flash architecture, likely impossible. Moreover, as stated on their Wikipedia page, the Amicima technology before Adobe acquired it, was demonstrated using voice, video, files, and presence. Regarding the point that you cannot do files with UDP because it is lossy (i.e. designed to be able to drop packets), this purported limitation of UDP is misinformed.

Yes, UDP is not a guaranteed protocol like TCP/IP, but many p2p systems use UDP. The way such systems work is that the sender and recipient have to communicate about what is being sent and what is actually received. So if you are expecting 100 packets labeled 0-99, and packet 49 does not arrive, the sender needs to send it again. This is a *very basic* aspect of designing services on top of UDP. UDP is indeed a very effective low-level building block for anything, and is totally capable of supporting guaranteed delivery at a higher level of the design.

3. p2p will not be able to offer security for content on user’s hard drives.

This is, just not so. Kontiki, introduced a highly secure p2p CDN in 2000. As far as I can tell there will be no impediments to implementing security since all that is required is file encryption on the hard disk (which is trivial) and transmission encryption, which is built into the protocol.

4. Couldn’t Adobe’s security model get in the way here?

It is true that we don’t know how Adobe is going to approach security. How restrictive are they going to be? In order for Flash 10’s new RTMFP protocol to work for building any kind of CDN, it must be accessible programmatically (i.e. from Flash’s programming language ActionScript) without user intervention.

For example, if Adobe requires that every time you want to establish a p2p connection between two Flash clients, you need to click on one of those Flash security dialogs then the whole thing comes crashing down. I could see if Adobe required that you click on such a dialog once for each website that required p2p access, but if they required that user interaction for every p2p access it would really be problematic. Aside from such draconian security measures, I cannot see any other impediments to implementing full-blown p2p CDNs. Of course any of you serious Flashers who have other thoughts please leave them in the comments.

5. Can this technology *really* kill CDNs?

Well, not in a literal overnight sense. There will still be a role for CDNs, but as I see it the heyday of growth, at least in their current form, is coming to an end. This is because companies like Amazon are commoditizing the central storage benefit through S3 (and will continue to do so) and because p2p technology will reduce, though certainly not eliminate the need for premium, centralized storage.

Of course the best such CDNs, using Kontiki as a design example, will of course also have servers that provide central storage and delivery for when the requested content is not available from another peer – a blended strategy. So the idea of centralize services will not go away. But killing growth is, in my estimation, the same thing as killing a category. If you do not grow, you die.

And so I believe, p2p is now poised to put a serious hurt on centralized premium server downloads. Of course it is entirely possible that CDNs will find some other significant value add, but as I see it this technology will take a huge bite out of the CDN market and for the CDNs that just ain’t good.

Post Author: Ruby H. Rosenbaum

Leave a Reply

Your email address will not be published. Required fields are marked *