Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Contributor
Posts: 18
Registered: ‎10-11-2010
My Device: Not Specified

BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

[ Edited ]

My application opens a TCP socket connection to a server. The connection is keep-alived and remains open until the client disconnects. I've attached the relevant code. The code works perfectly for OS 5/6/7 but doesn't work as expected for OS 7.1 (I tested it with Bold 9900 but I suspect happens on all OS 7.1 devices).

 

When running on OS 7.1, the blocking read() returns with -1 (end of the stream has been reached) after very short time (10-45 seconds). As I already said, for OS 5/6/7 the read() remains blocking until the next data arrives since the connection is never closed by the server.

 

Connection connection = Connector.open(connectionString);
connInputStream = connection.openInputStream();
while (true) {
    try {
        retVal = connInputStream.read();
        if (-1 == retVal) {
            break;   // end of stream has been reached
        }

    } catch (Exception e ) {
        // do error handling
    }

    // data read from stream is handled here
}

  

I am lost here. Why the call to read() that supposed to blocking returns with -1 for OS 7.1 only?

 

UPDATE 1:
Apparently, the problem appears only when I use secured tls connection (either using mobile network or WiFi). Everything works as expected when opening a non secured connection OS 7.1.

For tls on mobile networks I use the following:

 

connectionString = "tls://someipaddress:443;deviceside=false;ConnectionType=mds-**secret**;EndToEndDesired";

 For tls on Wifi I use the following:

connectionString = "tls://someipaddress:443;deviceside=true;interface=wifi;EndToEndRequired"

 

UPDATE 2:
It is worth noting that the connection is not "idle". I am constantly receiving and sending data on it until it closes. The issue appears both when using mobile connection and WiFi. Also happens on real OS 7.1 devices and on OS 7.1 simulators (checked on Torch 9860 and Bold 9900). I am starting to suspect that it is somehow related either to the connection string I am using (which works perfectly on OS 5/6/7) or to the tls handshake.

 

I appreciate your help.

BlackBerry Development Advisor
Posts: 15,753
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

What behaviour do you see when using deviceside=true?  What is happening on the server side?  Is there any error or exception there or does it simply see the client dropping the connection?

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Contributor
Posts: 18
Registered: ‎10-11-2010
My Device: Not Specified

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

I am using decideside=true for WiFi connections - same result. The connection is closed after very short period.

I don't know exactly what happens on the server side, but from the Wireshark's captures I made, I see that the server sends FIN (which makes sennce since the call to read() returns with -1).

Contributor
Posts: 18
Registered: ‎10-11-2010
My Device: Not Specified

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

The secured tls connection drop appears when RSA 2048 AES 256 cipher suite is negotiated on OS 7.1 only. Same cipher suite works perfectly well on OS 7.0. On the other hand, when using DHE/DSS 768 AES 128 cipher suite everything works as expected on OS 7.1 and the connection remains stable. 

 

Therefore, I deduce that the secured tls connection drop is somehow related to RSA 2048 AES 256 cipher suite. Any ideas?

 

 

 

BlackBerry Development Advisor
Posts: 15,753
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

Note that you should use either deviceside=true or interface=WiFi, not both.  The first is for a direct/carrier TCP connection, the second for a WiFi connection.  Using them both could result in either type of connection.

 

Do you have an example URL or application that can be used to reproduce this?  Can you submit a sample in Issue Tracker?

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker
Contributor
Posts: 18
Registered: ‎10-11-2010
My Device: Not Specified

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

[ Edited ]

I wasn't aware of that. We have been using both deviceside=true and interface=wifi for WiFi connections for two years by now and we didn't experience any problems. However, it is not the root cause of the problem. The problem is also reproducible when using BIS-B connection (and when using  direct/carrier TCP connection on OS 7.1 simulators).

 

I will try write a sample client/server setup where the problem is reproducible.

Contributor
Posts: 18
Registered: ‎10-11-2010
My Device: Not Specified

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

[ Edited ]

Unfortunately it is impossible try write a sample client/server setup where the problem is reproducible because of the system complexity.

 

I've submitted an issue to the Issue Tracker, https://www.blackberry.com/jira/browse/JAVAAPI-2306.

Highlighted
BlackBerry Development Advisor
Posts: 15,753
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: BlackBerry OS 7.1 InputStream.read() returns -1 after very short time

Thanks for submitting to Issue Tracker.  We'll have a look.

Mark Sohm
BlackBerry Development Advisor

Please refrain from posting new questions in solved threads.
Problem solved? Click the Accept As Solution button.
Found a bug? Report it using Issue Tracker