Best way for a Flash client to talk to a Java server through a full-duplex connection (chat or game)

Question

My client is in Flash/Flex (game with chat) and it will be talking to a Java server. What is the best way (protocol / interface) for my Flash client to talk to my server? I heard about Flash Remoting MX, but it is a request / response mechanism. I could always request something and wait for asynchronous notifications from server. Then request again, implementing something like a Comet server.

Anyways, what is the industry standard for this type of communication: Flash Client talking to Java server, supporting asynchronous "push" notifications from server.

Thanks!

Answer 1

Consider using an RTMP-based solution (NetConnection in Flash). Remote shared objects or direct stream publishing may be able to do what you want.

Anything like that will require a Flash media server implementation, either Red5, Adobe's, Wowza's, or some other.

Answer 2

Look at ElectroServer examples.

Answer 3

You can use a streaming AMF connection to get real-time, two-way, asynchronous push. If you want something free, BlazeDS can do this for you (it uses a Comet implementation). I've had pretty good luck with this, and scaled a single channel up to a couple thousand messages per second — plenty for a simple game or chat application.

The downside is that BlazeDS uses blocking IO, so you're limited in how many concurrent connections you can support (since each one needs its own thread). The cutoff depends on the application server you're using, but in my experience you'll never get more than a few hundred without running out of resources.

So if you only need a couple hundred concurrent users, you're probably fine with BlazeDS and StreamingAMF. If you need anything more than that, you'll have to take Michael's advice and pay for something expensive with non-blocking IO.

Answer 4

You have several options to do that, when using products like BlazeDS, LCDS, Granite, Red5 etc. Note that I'm aware only about LCDS to include all the options a) b) c) d) listed below(if I'm wrong maybe someone one can add a comment).

a)RMTP over full duplex sockets b)Streaming c)Long polling d)Short polling

for b) c) d) you can choose between blocking IO and non blocking IO. a) is using non blocking IO.

All of them have advantages and disadvantages. For example Streaming is implemented with 2 connections - one is kept open for ever and the server will push messages with ti and the second one is open when the client wants to send a message. However some proxy can decide that it will not allow an open connection more than 20 seconds and in this case streaming is out of the question.

More details can be found on Damon blog. At first glance you can be find too much information on that link, but its not the case. In fact you need to read many more articles(or books, like Livecycle Developer Guide). It is not an easy subject and you need to understand in detail all the aspects if you need to build a professional solution.

There is another option, to build your own custom protocol using Flash sockets with fallback to another type of channel but the development type will be significant.

You can also take a look on servers like ElectroServer or SmartFox from what I know they are specially built for the gaming industry.