Question

I’m building a multiplayer card game using Flex on the client side and Java on the server side and I wanted to know if I must sockets and the accept method in order to connect users to the server for in order for them to join a game room or create one or to chat.
In the past I’ve learned how to build a game server which both sides are JAVA and connection was in sockets but now days the client side will be in FLEX which has few ways to connect to a Java server (XML,SOAP,BLAZEDS(AMF)) and I find it hard to understand how to write the Java server in order to do all the features of a game server , especially managing the rooms and sending data back to the users.
In the sockets way, when a user was connecting to the server and he had opened a room, this room was opened on a thread and who ever was joined that room then he was connected to the same thread and sending the messages to the right place was easy, so the problem is understanding how to do the same using SOAP or BLAZEDS.
Any help would be appreciated.
Thanks.

Answer 1

Using raw sockets gives you the benefit of control. Control of your protocol format ( how your message data is structured). And because of this you can tweak your messaging to be more secure, or faster, or more robust, depending on your application requirements. All that control comes at the cost of complexity and maintenance. Because you get to say exactly what you want to send and how you want to send it you need to write and debug alot more code. Another issue with raw socket communication is that it has a significantly greater chance of being blocked by firewalls.

Using web services removes some of the complexity of deciding on a message format (with that being it’s main benefit). You don’t have to worry about things like byte endian-ness, string encodings, or data conversions (as much). As such web services really excel at data communications amongst heterogeneous clients and servers where inter-operability is key. The cost being that it’s relatively complicated to serialize/deseserialize, and as such, slower than binary messaging formats. Web services are good to use when you have to communicate with client applications that you have little control of (not really your case). Web services are traditionally tunneled through HTTP, so there is an additional advantage in being able to worry less about a firewall blocking access to your game.

BlazeDS attempts to bridge both worlds – it gives you some of the robust features of web services (fallback communication options, firewall interoperability etc), but uses it’s own binary format for serialization/ deserialization. This gives it some of the speed of using raw sockets without a lot of the downsides. I think it’s a great candidate to explore, but if you find yourself needing more speed then raw sockets would be worth messing around with.

Good luck.