Java Development

[dkonigs]

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)

-Derek

[fpotter]

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.

Good luck!

[dchapiesky]

Rather than keeping a connection open for a long time... how about making the blackberry application a  "mini-server"?

Meaning:

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...

Example:

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....

Roaming:

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...

Synchronization:

12) The main server can tell who has received information and who has not by tracking which connections succeeded

Error Detection:

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:

http://journals.ecs.soton.ac.uk/java/tutorial/networking/sockets/clientServer.html

http://blog.taragana.com/index.php/archive/understanding-java-simplified-hello-world-for-socket-prog...

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?

Daniel

[dchapiesky]

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:

http://www.blackberry.com/developers/developerlabs/listeningfordata.shtml

I personally don't like it because it taxes the server's available connections...

Daniel

[dkonigs]

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.

[dchapiesky]

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.