Flash Sockets, Peer-to-Peer Capabilities

Question

Quick Intro: We have a flash tetris game finished and we are looking to add multiplayer functionality to the game. After a few days of research on the capabilities of flash and sockets, I've gotten even more confused. A quick disclaimer, I am new to sockets/networking in general.

From what I gathered online, general flash tcp sockets cannot handle peer to peer connections due to the policy system in place. In order for flash to do p2p, one must use a RTMFP-capable server (such as flash media server, etc) to deal with the initial handshakes and from there, flash is able to pass data in a p2p fashion.

Edit: See the first answer for a comprehensive update on the question.

Hebron

Answer 1

1) For socket policy take my Perl-script or the Apache module (both work well): http://code.google.com/p/mod-socket-policy/ - it will serve clients connecting to the port 843.

But this is not enough because of corporate users behind firewalls / proxies - who can't connect to port 843, so you need to add socket policy handling to your own server code too (i.e. respond to incoming <policy-file-request/>\0 requests).

2) For RTMFP - don't do it, because:

a) Cirrus is not an option, because it is beta and not for commercial use. Also it seems to be outdated by the FMS4, so how long before it's discontinued?

b) Flash Media Server 4 option is very expensive. For the enterprise version (required for RTMFP) Adobe doesn't even list the price publicly. Your only option is FMS4 for AWS, but it is expensive too: adobe media server 4 cost with amazon?

c) There is an OSS project for RTMFP, but it isn't ready yet: OpenRTMFP Cumulus

d) For some users RTMFP just doesn't work

So my suggestion is to go with RTMP/RTMPT which works for all users, incl. corporate ones and use Red5 for that: http://red5.org/

Your

Thanks for your answer. As I suspected, Cirrus and Adobe's solutions were not ones that we'd like to follow at this point (RTMFP). Your perl script seems useful, but we've implemented basically the same thing using Node and it works (however, I have some other weird questions to ask on that one). Anyway, RTMP/RTMPT using something like red5 basically limits us to a client-server architecture, correct? Either we use a fat server with light clients... or use the server as a intermediary as communication between clients only? – Hebron

I run a multiplayer game with 5000 active users myself and use Red5 for audio/video chats only, while having my own code (non-forkable server poll()-ing sockets) handling the game. You could do the same: use RTMP(T) for gimmicks and handle the game by node.js or whatever you're comfortable with. – Your

Ya, I think my planned implementation is to have a semi fat node.js server that handles game logic on an instance-by-instance manner, and either use another node.js process to handle user groups/chat (or red5). We don't plan on any elaborate communications beyond text chat in our game. Do you mind linking me to your multiplayer game? Would love to see it. – Hebron

apps.facebook.com/video-preferans - it is a Russian card game, 400-500 simultaneous users in (european) evening time. Do you have a link for your game already? – Your

Answer 2

Red5 has no support for RTMFP. Prices for Flash Media Server you will get on the adobe webpage.

Preceptor

Answer 3

There is a technology on Adobe Labs called Cirrus. It's completely free and you won't need to have special servers running besides a regular one (php, ruby...) that will perform an initial handshake (a regular http request should do it).

So, if you have for ex. 2 players that want to play together, the first one gets his Cirrus-id, passes it to your server and that value is stored in a bank of "available players". When the second client connects, the servers checks the bank and returns that id to the second player, and vice-versa. Finally, two flash-player clients establish a direct connection via rtmfp. There's also an article that explains it all in more details.

Capriccioso

Thanks for the info. I also came to the conclusion that Cirrus was the only option for P2P. Apparently, there is no direct answer on how Adobe plans to handle the system in the future. On the official forums, people have asked how / when the "beta" phase will end and what that would mean for those who have implemented RTMFP software relying on Cirrus. No answer was / has ever been given regarding this question. I'm a little weary to jump into a solution with this kind of uncertainty. – Hebron