Hi, are you around Arfff? You gave me some advice about using a long lived connection as a backchannel, would be grateful if you could get in touch with me as I would like to duscuss this further and ask your advice.
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?
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.
i have implementet a long live connection in that way. Means i keep the output stream open on server side and push data in the stream until the client closes the connection. That works fine on the emulator, but it didn't works on my 7650 device.
On the device, I get an IOException Status=-20019 when I try to open the InputStream or read the responscode from the connection or close the OutputStream where I have written some POST parameters.
My server gets the request and sends the first block of data.
Have anyone tried the long live connection and had more ore less success?
Hi, likewise, mine works ok on the emulator, but not one the phone, a 7210.
I get an exception when closing the input stream that I have been writing too, however at this stage, there is no sign that the connection is going to be kept open, and when it's not kept open afterwards, the same code works fine! Does it store up these connection commands somehow? Otherwise there is no way of knowing that we are trying to keep the connection open at this stage surely ????
Hi again, I may have managed to get it working now, not too sure though. It seems to stream stuff back to the phone from the server, just a certain amount of numbers sent at a certain interval.
I think you have to send something down the backchannel within a certain time to keep the connection open.
However the interval between each number seems to have an affect on whether it works or not. Am still investigating a decent interval, it seems to change though, so I may have to implement a networking algorithm that increases the time day each time sending back, and then records when it fails, and then re-opens the connection, using intervals that are smaller than the interval at which it failed. Possibly even half the interval, and then gradually building it up again.
The reason I am doing this is I want to send as little useless information back as possible, but keeping the connection open for incoming messages.
However this may not be working at all, it takes quite a while for the first message to get back to the phone, a lot longer than to the emulator. So perhaps it is actually just running through my while stream and then sending this all back in one go once finished processing my stream.
I will have to investigate this further, making sure it will be able to send messages back in real-ish time. It may depend on the network at the time, if it works or not?
Currently though I am just getting authentication-failed messages on my phone when using GPRS, eventhough using same code as when it was working, all very odd............
Am now pretty sure that the phone isn't taking in streaming at all, it doesn't start reading in until well after the servlet has finished writing and flushing to the stream, finally closing it.
Whereas on the emulator, it is reading in data as it is being flushed out.
May investigate further at a later point, but with limited time before my thesis is due on I must give up for now and explain heavily in my thesis how it works in theory on the emulator but not on the actual device!