views:

420

answers:

4

Hi All,

I may be asking a bit much here but I have faith in the community so it's worth trying. I'm making a game and I'm trying to pick the connection type to use for communicating between a Java mobile client and a Java server backend.

Socket programing in Java is easy - there's a lovely tutorial on the subject and two way communication is trivial.

Trouble is that on a mobile client (Android) it's not guaranteed that the cellular network will let you make TCP connections. That makes me think using an HTTP connection is the way to go.

HTTP connections are request based but I need a way to push notifications from the server to the client. It seems the solution to this problem is to use 'long polling' I have read a bit about it but have yet to see a simple example for what I'm trying to achieve.

Again I might be asking a lot but this seems like a fairly common problem, is there a library or framework I can import / use to wrap a Http connection and provide a two way long standing connection (That reconnects automatically etc). I read a bit about cometD but it doesn't seem to have a Java library that I can just pick up.

The communication I need is not heavy, not constant two way streams of data just occasional updates either way to keep the game going.

Thanks in advance for sifting through my ignorance,

Gavin

A: 
Christopher
A: 

The Comet model tries to solve this problem when using HTTP. There's some Java examples here.

You'll find examples/articles mostly talking about ajax/XMLHttpRequest on the client side, but all you really need to do is ensure you're using a client library utilizing http/1.1 and http keepalive, and "poll" the URL in a loop.

The idea is the server server blocks and doesn't send you a response until there's actually something worth noting, while http keepalive keeps the connection to the server up between the requests so you don't pay the price of setting up a new TCP connection for every request - I'm assuming android already has a standard http library which should handle all this for you, including reconnects.

On the server side, Tomcat suports Comet processing as mentioned in the developerworks article above - unless you want to do it "manually" in a servlet which is also pretty starightforward until you need to really scale the no.. of client.s, and there's frameworks such as gwt-comet

leeeroy
A: 

Android does XMPP, if I'm not mistaken, which might be quite appropriate to your needs.

alex
XMPP support was included before the 1.0 SDK release, but not since then. See the first link in my answer for more XMPP-related info.
Christopher
+1  A: 

Doing long polling on the device has some disadvantages on a mobile device.

  • If the handset is moving your it will constantly loose the connection and you have to recognize this and reestablish it. Most of the time it will make your game unusable if the player is sitting in a train or car.
  • The connection will cause the handset to constantly send and receive data and therefor use a higher antenna level. This could drain the whole battery in one hour of playing even if you don't need much energy for processing, graphics and illuminating the screen.

If you want to try a game that shows this problems try Parallel Kingdom Age of Emergence.

I would look into XMMP as proposed by alex. If you can't find a XMMP librarie on Android use Smack. Or have a look at this question.

Janusz
I linked to a similar (better ;)) question/answer relating to XMPP, including mention of an Android-specific version of Smack.
Christopher