Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
08-01-2008 08:41 PM
My application has a need to sit on an open TCP socket, and wait for data to come down from the server. Is there any way to be asynchronously notified of new data on a socket (StreamConnection), or do I have to just have a thread constantly polling the socket for available data?
Also, does anyone know what the overhead is (i.e. in terms of battery life, device load, etc.) of keeping a mostly idle TCP socket open for an extended period of time? (the alternative being closing and reopening it every 5-10 minutes or so)
08-01-2008 09:50 PM
Nope, there's no async reads. You'll have to have a thread that just blocks on read().
As for the keeping the socket alive, you might find that it works out alright. I believe it's possible for the air link to shutdown but still maintain your open socket. If you write to it from the client side, the link will automatically come up. If the server side writes to it, it'll automatically come up. The gateway is supposed to handle all of this. Give it a shot. I'm sure there is some limit on the lifetime of a socket, but I don't know what it is.
08-02-2008 08:43 PM
Rather than keeping a connection open for a long time... how about making the blackberry application a "mini-server"?
Use a thread waiting on a ServerSocket() in your application.
Your main server would no longer be juggling open connections and not knowing which ones have dropped, etc...
1) User turns on phone
2) autostartup of your application begins
3) your "mini-server" finds the blackberry's IP address and contacts the main server
4) the main server "registers" the "mini-server" IP address and places it in a list of known clients to push to...
5) the "mini-server" opens a ServerSocket in a thread and awaits connections and info
6) the main server has something to send...
7) it opens a connection to the mini-server ip address
8) the mini-server receives info
9) the connection is closed and the mini-server returns to awaiting new connections....
10) the mini-server detects that it's IP address has changed due to roaming...
11) the mini-server contacts the main server and updates it's registered IP address...
12) The main server can tell who has received information and who has not by tracking which connections succeeded
13) The logic for detecting a connection failed is very time intensive on the server waiting for time-outs
14) the logic of opening a connection and failing is fairly simplistic...
Ease of Logic:
15) writing code for "one-time connections" is simpler than keeping the connection open and hoping for the best in terms of the carrier, signal strength, firewalls in-between, etc...
Check these out:
Really, I think you can't depend on a keep-alive to work... remember your server has a finite number of connections available to it and may even be pooling those connections.
How many blackberry clients are you expecting to be deployed?
08-03-2008 02:51 AM
On reflection, I admit the above example may be a bit over the top...
The existing "push" interface may be what you are looking for:
I personally don't like it because it taxes the server's available connections...
08-03-2008 08:13 AM
In most of these forums, there seems to be an unwritten assumption that we are always developing specific-deployment mobile applications that interact with a server-side application we are also developing. In that situation, I'd probably agree with your suggestion.
However, I am working on a generally-available application that interacts with a server using standard protocols I have no control over. Those protocols specifically support this connection-idling capability, and many other clients also take advantage of it. There really is no other way of asynchronously notifying users of new data besides reconnecting every 10-20 minutes.
08-03-2008 09:52 AM
Your right about the unwritten assumption....
It's interesting to me that an architecture was designed to use connection idling on a large scale... (long connection time/multiple clients)
The issues that I pointed out, especially the change of client side IP address, just make it infeasible to me to use.
Good luck on your project.