TCP-based RPC server (Erlang or something similar?) for iOS/Android app communication

Question

I\'m building native mobile applications in both iOS and Android. These apps require \"realtime\" updates from and to the server, same as any other network-based application

Answer 1

I work on a application that connects to a Microsoft http server with long lived http/https connections to mobile devices to allow for push type data to be sent to the mobile. It works but there are lots of little gotcha's on the mobile side.

• For the client to get 'packets' of data, we put the http connection into Chucked Encoding mode so that each packet is in one chucked packet.

• Not all native http API services on each mobile will support calling you back when a 'chuck' of data has arrived, on the ones that don't normally wait until all the data from the server has arrived before calling the application back with the data. Platforms that support callbacks with partial data are (that I have found):

  • Symbian
  • Windows Mobile

• Platforms that don't support partial data callbacks:

  • IOS
  • Blackberry

• For the platforms that don't support partial callbacks, we have written our own http connection code with chucked encoding support using the native sock support. It's actually not very hard.

• Don't rely on the fact that one chuck is one of your packets, http proxies or the native http api implementations may break that assumption.

• On IOS with this background multitasking rules, means you can't keep this connection going while your application is in the background. You really need to use Apples Push Notification service and live by it's limitations.

• Never trust mobile cellular networks, I have seen the weirdest stuff going on like the server side seeing the http connection drop and then reconnect (and replay of the original http request) while on the mobile end you don't see any drop in the connection. Basically treat the connection as unreliable where data can go missing. We ended up implementing a 'tcp' like sequence number scheme to ensure we didn't lose data.

• Using http/https makes it easier to get past firewall rules on customer sites.

I'm not sure using http/https long-lived connections was the wisest decision we ever made, but it was made long before I turned up so I have to live with the fall-out of it.

As a alterative, we are looking at web sockets as well, but with the web-socket spec in the state of flux atm and generally being not to good to follow, I don't know if it will work out or not.

So that is my experience with using http/https as a long-lived realtime connection.

Your milage may vary.