Thread-safe checking variable for a midlet

Question

Hi, I'm programming a game in j2me in the client side, that connects to a server written in java. This game is going to have a chat feature, but as a secondary feature.

For every midlet that connects to the server, a server-game thread is spawned. These threads talk between them, so that they can synchronize and write in turns to a series of config files in the server. Now, if a chat message is written in one of the midlets, it's passed along to a client-side thread that manages the socket communication and gets sent to the server. In the server, all other players of the same game are notified, and the chat messag is relayed to all of them. So every server thread (but the one of the user that sent the message originally) send to their correspondent client thread the message.

Here comes my question. How can I signal each midlet so that it knows there's a new incoming message?

I thought about making a thread that polls the client-side communication thread to see if there's any new message. But then, how can I know from the midlet, without interrupting it halfway? Ideally, I'd want to read directly a string that's in the client-side communication thread, but that string could be being written, so I need a thread to access it and synchronize to it.

Can any of you guys give a hand? I don't really know how to proceed, and it seems this should be pretty straightforward...

thanks in advance

Answer 1

You almost never want to poll. Polling is a terrible waste of resources in almost every case. With the design you are suggesting, you are going to have a context switch every time the polling thread triggers, which will also then take a few cycles to check if it should process the request. Add polling to network code, and you are talking about some serious delays.

The problem you are facing is easily resolved using the Observer pattern. (Here is a pdf explanation of this pattern from patterndepot.org. Here is an explanation on JavaWorld.com) Additionally, working in a multi-threaded environment, polling has the disadvantage of a context switch, and synchronization, and then finding out that you didn't need to spend those resources on checking your message bus. Look at using a concurrent collection out of the java.util.concurrent package to store your messages.

Finally, your general architecture sounds like it will need some reworking on the server side. If you plan on having a high user load, as the introduction of a new mid-tier handling thread for each user will eventually cause the server performance to degrade, as you have more context switches, and tasks become beefier.

Answer 2

Unfortunately, since mobile phones generally do not spend most their whole life connected to the internet, the only true push mechanism available is SMS/MMS via the PushRegistry API. The real problem with true push is that the server needs a way to identify the client and you can't rely on a temporary IP address given to your handset by the Mobile Network Operator.

If you plan on using an HTTP connection channel, you NEED to poll the server for chat message updates. However, there are ways to make this less of a bad situation.

If your game is supposed to regulary send/receive data to/from the server anyway, you can bundle the chat data into your own protocol in the body of the http requests and replies.

You can technically mix the two approaches by using SMS push to trigger the HTTP retrieval of data but that can become expensive.

About the proper use of the synchronized keyword in your MIDlet java code, I suggest you ask a more precise question, with included code sample as it is a different problem domain.