Client-server communication for mobile devices

I have at least a couple of ideas for a mobile application which would require to exchange data with a server constantly. Here are some of examples:

• intelligent home controller

  • sends commands
  • receives notifications and devices state updates

• real-time tracing of mobile devices

  • sends own location (on observed device)
  • receives location of other devices (on observer device)

The data being exchanged are quite simple. The quick and dirty solution is trivial. The application sends commands as simple HTTP requests and also gets updates and notifications by polling the server in a defined periods of time.
On the client side we could use HttpClient (which is already present on Android platform). On the server side a simple servlet anwers with a plain text data. Not a big deal.
However there are lots of issues when considering mobile applications and platforms.

1. In many cases we’d like to encrypt the communication with SSL – (think about home controlling application talking plain-text over WiFi network) – that consumes more resources and network bandwidth
2. I don’t want to buy a server certificate but instead I want to use a self-signed one. That makes it a little bit more difficult to implement a client-side code. The application has to trust the certificate unless it won’t talk with the server.
3. If we want the application to react immediately on updates we want to poll the server very often (for example every two seconds) and for HTTP requests over SSL we can easily end up with over 100MB at the end of the month which may significantly increase your bills if you don’t have a good rate for data transfer.
   Of course modern phones have WiFi. But a phone may be out of range of the WiFi network. Active WiFi connection drains a battery a lot. I configured my Samsung Galaxy to disable WiFi when going standby but it takes 10 seconds to re-enable it again after unlocking the keyboard.
4. Mobile network introduces substantial latency to the communication.
5. Requests to the server should be running in a separate thread not to block a user interface

To avoid opening HTTP connection each time the application wants to ask for updates it can take advantage of persistent connections introduced in HTTP 1.1. Going further it is possible to use a chunked transfer. It is another feature introduced in HTTP 1.1 which allows to split request or response data into portions and send them one after another within the same request/response without exchanging HTTP headers each time. Each chunk have to prefaced with hex-encoded size.
So the complete process would look as follows:

1. the application opens an HTTP connection (possibly over SSL) and sends HTTP headers
2. the server responds and sends its HTTP headers
3. application sends data without closing the connection
4. server responds without closing the connection
5. steps 3-4 are repeated as often as the application need
6. the connection is being closed when user closes the application