Java Development

[YohannBB]

I have some strange problems regarding establishing a connection.

I'm using a consummer Blackberry 9000 with OS 4.6.0.247 other a 3G network with carrier SFR

Most of the time, between the call to Connector.open, the sending of the request and the receiving of the response, there is usally 3-6 seconds (btw, this seems a bit slow ?).

But when i'm launching a second connection just after finishing the first one (less than 1 second between the two), the whole connection process (open,write,read, close) is really fast (<2 seconds).

However, when i'm waiting for opening the second connection 2 or 3 seconds after the first, the Connector.open call stall 3-4 seconds before opening, and then takes the regular 3-6 seconds to finish.

I have done my tests using BIBS, directtcp with my carrier apn and WAP2, with all applications on my phones (the one i'm developping, gmail, ...). I've try to reset my phone. I'm always getting the same behaviour since i've buyed this phone (two weeks ago).

It's seems to me that :

- when a connection is already established (when the arrows in the top-right of the screen are blinking), a new connection is very fast to establish and apply.

- when a connection is getting closed, a new connection will take a lot of time to start(the arrows in the top-right of the screen will start blinking after 3-4 seconds) and then respond normally.

- when no other connections are opened, a new  connection will take a normal time to start and respond.

Is someone have faced similar behaviours?

Thanks 

[YohannBB]

Here is the event log for the 3 behaviour I've got :

A single connection :

Duration: 3 seconds

a net.rim.ippp - RXCd 2324   10:34:09
a net.rim.ippp - TXst 410    10:34:06

A first connection and a second one just after :

Duration: 3 seconds then 1 second

a net.rim.ippp - RXCd 10590   10:30:31
a net.rim.ippp - RXCd 11      10:30:31
a net.rim.ippp - TXst 399     10:30:30
a net.rim.ippp - RXCd 4977    10:30:28
a net.rim.ippp - TXst 399     10:30:25

A first connection and a second one 2-3 seconds after :

Duration: 4 seconds then 9 second

a net.rim.ippp - RXCd 1022     10:36:40
a net.rim.ippp - TXst 402      10:36:31
a net.rim.ippp - RXCd 2373     10:36:27
a net.rim.ippp - RXCd 8203     10:36:27
a net.rim.ippp - TXst 383      10:36:23

[klyubin]

That's how UMTS works. It takes a while to accomplish a switch from camping on a paging channel (where the mobile terminal can only receive notifications) to a shared/dedicated channel (where the mobile station can send/receive user-plane data). Once the mobile terminal is on a shared/dedicated channel, it can send/receive (and thus establish new TCP connections) virtually without delay. After a certain time of inactivity (governed by the network, I've seen values between 10 and 45 seconds), the mobile terminal is told to switch back to a paging channel.

P.S. You'll see the 3 second delay even when you have an already established stream/TCP connection. If the BlackBerry isn't sending and receiving for a while, sending something over the connection takes around 3-4 seconds (time it takes for the data to reach the server).

[YohannBB]

Thanks for the information 

As my application needs to do frequent transmission (it's basically a webdav explorer, a connection will be established when you want to browse a subfolder, view a file, ...), the typical delay between two user interaction is 3-4 seconds and it's seems is almost the very time my network switch back from paging channel to sharing channel.

So the user will have to wait for the channel to finish switching to paging, then return to sharing and finally send my request which some times tooks more than 10 seconds 

Is their is a way to maintain the dedicated channel to speed up the connections? (maybe if I create a parallel connection to a server and transmit data every 2-3 seconds like a ping).

Does that make sense  regarding battery consumption and network policies ?

[YohannBB]

Just to confirm your informations I switch from 3G (UMTS) to 2G (GSM) and connections are much more responsive (faster delay between opening the connection and start reading response) off course data transfer are slower but the whole "user experience" is almost better which is a bit absurd (as it thought 3G was better in every way, battery consumption aside)