my dog learned polymorphism*
The moose likes Java Micro Edition and the fly likes Real world network delay problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Mobile » Java Micro Edition
Bookmark "Real world network delay problem" Watch "Real world network delay problem" New topic
Author

Real world network delay problem

Vivek Viswanathan
Ranch Hand

Joined: Mar 03, 2001
Posts: 350
Hi
I have written a simple MIDLet that fetches images from the server and displays it on the Mobile screen. The user is allowed to refresh the image which fetches a new image from the server. I have tested the application on a Nokia 7210, I seem to be getting horrible response time when ever each image is to be downloaded. The image that I am downloading is about 10 to
13 Kb png image.

Location: London(UK)
Mobile Network Used : O2(GPRS)
Phone : Nokia 7210.
Here is what my application code does ( I know it is a pain reading through code but I have included a lot of comments to reduce the pain)
...
// Open and HTTP Connection to the server
waitScr.setMessage("Connecting");
httpCon = (HttpConnection) Connector.open(url);
// Set up request headers
setUpConnectionRequest();
// Add the application specific headers.
httpCon.setRequestProperty(REQUEST_HEADER_DEST_IMG_MIME_TYPE,
IMG_MIME_TYPE);
httpCon.setRequestProperty(REQUEST_HEADER_IMG_SRC_URL, hImgUrl);
httpCon.setRequestProperty(REQUEST_HEADER_IMG_WIDTH, hImgWidth);
// Open the connection
waitScr.setMessage("Sending Request");
din = httpCon.openDataInputStream(); // Here is long delay
waitScr.setMessage("Got the connection");

int contentLength = (int) httpCon.getLength();
// Create the byte array for storing the data read from the server
byte[] raw = new byte[contentLength];
waitScr.setMessage("Reading data");
din.readFully(raw); // Read the data from the server.
waitScr.setMessage("Almost Done");
Image img = Image.createImage(raw, 0, raw.length);
srtCamDisplay.setImage(img);
raw = null;
// Clean up.
din.close();
httpCon.close();
din = null;
httpCon = null;
...
The code also includes the usual error checking and exception handling stuff but I have not included it.

Here is the problem that I am facing.
I have tested the application on 'Java 2 Micro Edition Toolkit' using a dial up connection to the internet. The application runs perfectly fine and I get all the differnt status messages on the mobile screen indicating the
progress. The status messages are displayed on the screen in the method waitScr.setMessage("....")
So when executing on the toolkit I get the following messages
'Sending Request'
( after about 10 - 20 sec )
'Got the Connection'
( after about 1 sec or less )
'Reading Data'
( after about 10-15 secs )
'Almost done'
After which the image is displayed on the mobile screen.

Now when I am running the same application the mobile phone - Nokia7210 ( UK Network - O2)
I just a see a single message 'Sending Request' for a variable period of time ( from 20 to 50 sec ) after which I see image on the mobile screen, I dont see any ofthe other messages like 'Reading Data' etc.
For testing I included a short sleep time in between the differnt messages displayed on the screen, after
which I ran the application on the phone and I could all the differnt messages.
So I assume that when I run the applicaton on the real phone (with out the sleep )I am facing a long delay at the following location in the code
din = httpCon.openDataInputStream(); // Here is long delay
Since I after I get the connection to the server every thing else process really very fast so I dont see the messages following 'Sending Request'.

I have also noticed something else, whenever I am downloading an Image there should be a symbol 'G' appearing
at the top indicating the phone is accessing GRPS, at times I can see the message 'Sending Request' but I dont
see the 'G' symbol, after a while ( 10 sec ) see the 'G' symbol after which I get the image.
Since my application allows the user to refresh the image, as a result of the whcih the application makes a
new request to the server which takes the same amount of time again.
The server application which provides the images to the MIDLet is a servlet which generates the images based on
the request. Since the MIDLet is going to download images quite frequently is there any way that I can use
keep alive http connections from the MIDlet to fetch images from the server. I assume that by using keep-alive
connections to the server(servlet) I will face the delay only initially and not every time the user wishes to
refresh the image.
Inorder to use keep alive connections I set up the 'Connection: Keep-Alive' header in the request sent to the server from
the MIDLet. But the response that I get from the server(servlet) contains the header 'Connection: close' I assume that
the servlet is closing the connection.
Does any one have an implementation of keep alive conneciton using MIDLet and Servelets.

vivek

din = httpCon.openDataInputStream(); // Here is long delay


Vivek Viswanathan SCJP 1.2, SCJP 1.6,SCJD,SCEA,SCWCD,IBM-484,IBM-486,IBM-141,Ms.NET C# 70-316,SCMAD, LPIC-I
Paul Kelcey
Ranch Hand

Joined: Jan 26, 2003
Posts: 45
Our company has done some work with Nokia phones and HTTP. One of the things that we noticed is that the calls to the stream block until the entire HTTP response has been received by the device. Also we had to close the connection to send data in chunked mode (not sure if that is related).
After talking with one of the Nokia guys, we found out that the HTTP stack on all current Nokia handsets, is a virtual stack running on the handsets/carriers WAP stack. He therefore believes that the problem is in the gateway, not the handset HTTP implementation (which doesn't help us very much).
So this probably doesn't help you very much either but at least you're not alone
Cheers,
PK
Vivek Viswanathan
Ranch Hand

Joined: Mar 03, 2001
Posts: 350
Thanks a lot :-)
At least I got a reply.
Any ideas on where I get information about the HTTP Stack used at the gateways, the types of stacks etc. So that I can probally find a way around it.
regards
 
 
subject: Real world network delay problem