As I’ve reported, the inclusion of P2P in Flash 10 Beta represents a fundamental disruption of the Internet platform. As with all disruptions, however, this one will progress in fits and starts. Flash 10’s details limit the full power of its P2P features. While features like VoIP will be fully enabled, it will take some ingenuity to turn Flash 10 into a more generalized P2P platform. Here are the issues:
1) Flash Media Server (FMS)
You’ll need Flash Media Server (FMS) to take advantage of Flash P2P. At $995 for the “Streaming Server” and $4,500 for the “Interactive Server”, FMS is beyond the reach of most developers working on their own projects, severely limiting Flash P2P’s disruptive potential. In an ideal world, the new P2P protocols would be openly specified, allowing open source developers to write their own implementations. As it stands now, a single company controls a potentially vital part of the Internet infrastructure, and encryption will likely thwart the initial reverse engineering efforts of open source groups like Red5.
2) No Flash Player in the Background
As David Barrett (formerly of Akamai/Red Swoosh) has emphasized on the Pho List, Flash Player only runs when it’s loaded in your browser. As soon as you navigate to another page, Flash can no longer act as a P2P server. P2P programs like Red Swoosh, BitTorrent, and LittleShoot don’t have this limitation, and it means Flash can’t save web sites as much bandwidth as those full-blown applications can. This limits but does not eliminate Flash’s threat to CDNs. Sure, you could get around this using AIR, but that creates another major barrier to adoption.
3) Usability
While Flash 10 has the ability to save files to your computer and to load them from your computer (essential for P2P), it pops up a dialog box each time that happens. While this is an important security measure, it cripples Flash 10’s ability to mimic BitTorrent because you’d have dialogs popping up all the time to make sure you as a user had authorized any uploads of any part of a file.
4) Limited APIs
While all the required technology is there in the Real Time Media Flow Protocol (RTMFP), ActionScript’s API limits some of the P2P potential of Flash 10. P2P downloading breaks up files into smaller chunks so you can get them from multiple other computers. Flash 10 can only save complete files to your computer — you can’t save in small chunks. As a result, you’d have to use ActionScript very creatively to achieve BitTorrent or LittleShoot-like distribution or to significantly lower bandwidth bills for sites serving videos. It might be possible, but you’d have to work some magic.
So, that’s the deal. There’s still a lot more documentation coming our way from Adobe, so there are undoubtedly useful nuggets yet to be discovered.
Even given all these limitations, however, the key point to remember is the Internet has a new, immensely powerful protocol in its arsenal: Matthew Kaufman and Michael Thornburgh’s Real Time Media Flow Protocol (RTMFP). While Flash might use it primarily for direct streaming between two computers now (think VoIP), it introduces the potential for so much more.
Keep your helmet on.
Route 183 
I just wanted to throw a quick response your way about issues #2, #3 and #4.
The Flash Player actually has a local file storage service called ‘Local Shared Object’. Essentially, this feature lets developers read and write arbitrary bytes to disk – including files and parts of files. End users are prompted once (ever) to authorize a particular amount of disk space (up to limitless).
This feature would allow a peer to peer network exactly the kind of access they would need to distribute the downloading of large files across those users that are currently connected to their site. This could be especially powerful (and cost-effective) for high traffic sites that present high-popularity, large file-size content like Youtube.
As an end user, I would only be prompted when I wanted to take a file out of the application and save it to some other location on my hard disk.
Of course peer-to-peer implementations in SWF are not likely to look like today’s general purpose peer-to-peer clients. The SWF versions are far more likely to be more tightly coupled to a particular content type and application. A music or video player for example.
With all that said, issue #1 is still a very big problem to me at least, but it’s probably far, far more cost-effective for popular sites to unload terabytes of bandwidth costs (and risks).
Hi Luke- Very interesting stuff. I am far, far from an ActionScript expert, and I’ve just now glanced at the Local Shared Object API. Looks like the NetStream/NetConnection changes along with Local Shared Object might actually do the trick.
I’d love to talk offlist about the details of this. Can you shoot me an e-mail at “a” at my domain (littleshoot.org)?
-Adam
nice article.
i gotta say i was much more excited about the whole thing before yesterday. thats when i found out there still has to be a fms in between – i guess it will take some while for the red5 team to implement rtmfp, if ever.
my conclusion to the whole thing is dissatisfactory for now. 😦
$4,500 is nothing for a RMTP connection. Imagine all the possibilities we can do with a P2P connection! Games, conferences, chats, entreteinment…. the imagine is the limit! I want this in my hands! I´d pay one arm for it! 🙂
I agree it’s not much for what you get. It’s just a lot compared to the ideal: an open source implementation of the same thing using open protocols. Why settle?
Well, I’m not quite sure if Adobes attempt to p2p is a full blower. As far as I’ve heard, p2p funcitonality is only possible with the fms and then there’s a direct connection between the clients – but well, p2p is about FINDING and receiving files from vom clients you maight not know, but getting them from cleints which as act bridges. So in terms of scalability I’m not quite sure if Adobe will be able to compete against real p2p overlays with no central infrastructure (like e.g. kademlia). I think Adobes attempt goes more in a direction of let’s play a game against each other, and such…
The finding part is both better and more easily handled centrally, though, turning it into a simple problem. Overlays like Kademlia are cool, but the only reason to use them is to limit liability. If/when P2P networks are used for more general purposes outside piracy (sure, they are to some extent now), the basic reason for overlays like Kademlia existing disappears. A centralized index is way faster and way easier to code, ultimately making it cheaper with developer hours factored in. Sure, you’ve got to pay for a server or two, but that traffic is extremely lightweight and cheap in the scheme of things.
Don’t get me wrong, Flash has a long way to go before it’s a real P2P contender. They’re solving the most important problem, though — reliable connections between any two peers on the network with firewall properly traversed. Their firewall traversal in particular is better than almost any P2P app out there.
Addressing (1), it’s not true that you’ll have to buy an FMS server in order to establish a p2p connection: Adobe is hosting a server cloud called Stratus that you can use to establish the handshake:
http://labs.adobe.com/technologies/stratus/
Of course, you’re still going to need FMS for any kind of centralized infrastructure that’s going to require server side scripts.
@thedavidmo Stratus wasn’t released when I wrote this post, but your point is more or less correct. The only issue is Stratus can’t establish a p2p connection with every NAT combination out there (and neither can anything else), so any truly robust solution will always need a relay. In other words, they’ll need FMS. Stratus alone will likely work in about 90% of cases, though, so it gets you pretty far.
If you desire to grow your know-how only
keep visiting this site and be updated with the newest information posted here.
I enjoy looking through an article that can make people think. Also, many thanks for allowing me to comment!|
Therefore, you are saving cash at the end. Get a feel for the game by playing for free online. A late surrender indicates player wait until the dealership reveals his cards.