Java Development

[sam_mor]

Hi Guys,

I am developing an application for blackberry bold 9000 .

this application use TCP/IP Direct connections to connect, send data to a server application.

connnecting using a  thread:

connection = (StreamConnection)Connector.open(URL);
os = connection.openDataOutputStream();

Sending Data every 3 minutes:

try
            { 
                        os.write(tosend.getBytes());
            }
             catch(ConnectionClosedException dis)
            {
                new ConnectThread().start();
            }

 what is happening on the server is this:

connection established

send data for several times

connection abondaned

connection established

send data for several times

connection abondaned

this process hapens again and again..

what is strange,:

1. sometimes i have connectionclosedexception, sometimes not when reconnecting

2. the ip address remains the same even i use this application all the day long

Any explanations?

thanks

[klyubin]

NAT. I'm not 100% sure that's the reason, but I believe carriers' NAT rules have short expiration times. So, if you aren't sending and receiving often enough (typically every 80-120 seconds, but on some carrier+APN combinations the intervals may be much longer) via an established (NATed) TCP connection, the NAT rule gets removed and the connection no longer works.

P.S. Make sure you explicitly invoke OutputStream.flush() to let the TCP stack know you want the buffered data sent immediately.

[klyubin]

Another interesting theory is that it is the BlackBerry's network stack is responsible for timing out connections that have no traffic. At least one carrier claimed that it's not their firewall/NAT that's closing the connection, but rather that they receive an RST packets from BlackBerrys.

[sam_mor]

I am not sure what to say, I was investigating, i didnt reply back.

my device is always sending data every 3 minutes, so there is no idle time for sockets.

but still disconnection detected on the server side then a exception catched on the device 

the IP address when connecting and disconnecting is the same for the whole day => i think that mean it's not a problem of Telco

please advice

[peter_strange]

Can you change the 3 minutes to something less than 2 minutes and try. 

[sam_mor]

as you see, it's the same

Connection Established
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
[58.111.55.174] ..:. úø
Ň3<
Connection Abandonned
Connection Established
[58.111.55.174] ..:. úø
Ň3<

[peter_strange]

Odd, might try recreate.

We had some socket issues with old firmware on Bold, what OS level are you running?

[sam_mor]

v 4.6.0.247 ( patform 4.0.0.206)

crypt kernel v 3.8.5.5.50a

branding version 1.0.146.168

[Aviator168]

I had problem sending TCP data before the software in my Bold was updated, but didn't try to reproduce it after the update. It was different problem. The send command will stall after certain amount of data was transmited, but the server never saw the connection dropped. I know NAT is in play here, especially for UDP.  The gateway tend to drop the association after about 3 minutes and you will get a new address starting the next transmision. However, if you constantly transmiting and receiving data, the gateway will keep it open indefinitely.

[klyubin]

The fact that that source IP address (as seen from your server) doesn't change doesn't say much. You need to look at the combination of source IP address and TCP source port.

P.S. If you use WAP 2.0 TCP, then the gateway sometimes adds lots of "interesting" effects, such as disconnecting one side without disconnecting the other. I suggest you set your Event Log to Debug level, and then check whether the OS is issuing normal Direct TCP connections or WAP 2.0 TCP ones. You can tell if WAP 2.0 TCP is used by the following two signs: (1) WAP APN is used for the underlying tunnel instead of the "internet" APN, (2) the underlying "tcpsocket" protocol connection is opened to a WAP gateway IP instead of the host name that you pass into Connector.open().