[newmania]

Rather than setting up an HTTP connection, sending a message, and then receiving a reply, is there a way to keep the connection open, so that further messages can be received without anything else being sent?

I need this to work with standard HTTP, or with sockets, so that all java phones are capable of it.

I am implementing a turn-based game, but I don't want the midlet to have to keep polling to see if new moves have been made by the opponent, I want them to come in to the midlet when they are made. Any ideas?

Thanks, Tommy

[arfff]

You can use a long-lived HTTP request to stream messages from the server back to the client. You'll need to use a separate request channel to send future requests though which ought to work but doesn't due to the thread/network problems on the handsets.

For the 'backchannel':

1) connect to a servlet from the handset to be used for messages from server-> client
2) servlet sets contentLength to something 'large'
3) servlet permanently stays connected to handset for sending messages from game
4) messages from game get sent across connection and flush()ed
5) handset (in background thread) reads byte by byte and needs to know when a complete message has come across.

--lee

[newmania]

Sounds like it could work. But do you mean it's not possible to use a seperate request channel? Can I only have one connection open at one time?

Another way I have thought of having a realtime 2 player turn based game is to open a connection and send the move, and this move is passed to the other player in their HTTP responce, they then make their move and send it to the server, and this move is returned to the initial player in their return HTTP connection.

Do you know if there is a time limit to the HTTP connection?

THanks, and I will give the backchannel idea a go.

TOmmy