multiple flush() not work for j2me httpconnection?

[tiansun]

Hi, I come across a problem related to flush() in j2me environment. Thank you for taking some time to read.

A server writes data to a midlet through HttpConnection established by the midlet. The expected behavior is like this

Server side:
server writes some data
server flush
server wait
server writes some data
server flush
server wait
server writes some data
server flush

Midlet side:
receive some data
processing
wait
receive some data
processing
wait
receive some data
processing
wait

This behavior works in J2SE perfectly. Some Sun emulators also supports all these well. But in Nokia emulators, and most importantly, real handset (e.g Nokia 7610, Moto v303), it is not working as expected at all.

They do something like this:

Server writes data and flushes, midlet waits on getResponseCode()
Server writes more data and flushes, midlet still waits there
Server writes more data and flushes, midlet still waits at getResponseCode(), like it hangs.
Server closes, midlet finally moves, and receives everything in one go.

All makes flush() method seem not to support j2me httpconnection.

I was firstly thinking that's because of nokia implementation. But the fact that it does not work on real handsets (nokia and moto) inspires me that it's not simply due to nokia implementation.

if nokia, moto and others all implements j2me http networks in such a way, we have to say "that's for j2me".

The real confusing behavior of Sun WTK emulator gives me a little hope by showing everything received well from server sides' flushes. I'd try my best to find out if there possibly exists methods that could tune either server sides or midlet somehow to correct and realize this process.

Thanks in advance.

[axs]

Hi,

IMHO for real phones you should implement communications in a simple request-response-and-finally-die manner only. The reason for this is not only in Nokia or Motorola firmwares, but rather in mobile operator settings, which are cutting off connections after some time.

As we have discovered, the real communication on Nokia mobile phones happens when you open InputStreams from the HttpConnection. Only after that you should check for response codes. As we also discovered, the best way to communicate with the server (with Nokia's J2ME and real-world networks) is to post an HTTP request, then try to open Input- or DataInputStream, and wait for response code. We used "flush()" only once, because as we realized, output buffers are flushed by Nokia mobile phones automatically. However, it's a very good technique to remind once the output buffer to flush itself, just for sure.

And please try to remember, that by using Sun WTK or Nokia SDK emulators (without specifying bytecode interpretation speeds and network bandwidths), you are dealing with a PC computer, not with the really limited mobile phone's hardware or real GSM networks.

[tiansun]

Thanks for the reply, axs.

I totally understand what u said. That's also what my developer friends told me "one httpconnection doing one thing". However, I don't really agree that unstable mobile connection would be the reason encouraging people to communicate slowly at cost of speed and efficiency. But if it's true, what a pity.

I encountered this flush problem during the study on "server push" techiques for j2me. Http server push is used in many places, for example, motion-jpeg with server push gives us simple online monitoring. In such a case, request-response-finally-die loop could take too long to be endured.

If everything proves http server push does not possibly work for j2me, I will go for socket connection.

[peterblazejewicz]

hi,

something similiar what asx posted is written here:
http://developers.sun.com/techtopics...ing/index.html

One way to reduce the number of chunks is to eliminate flush() calls and use only a single write() call if possible. Flush only if there is something significant about starting the HTTP request at that point in the application. Let the system handle its own output-stream buffering. Each platform might have a different optimal mechanism for segmenting the data.

also simply calling getResponseCode on HttpConnection will always flush any data in buffers afaik,

regards,
Peter