How should I implement bi-directional networking between an iPhone application and an Objective-C server-side application?

Question

I'm looking for advice on the best way to implement some kind of bi-directional communication between a "server-side" application, written in Objective-C and running on a mac, and a client application running on an iPhone.

To cut a long story short, I'm adapting an existing library for use in a client-server environment. The library (which runs on the server) is basically a search engine which provides periodic results, and additionally can provide updates for any of those results at a later date. In an ideal world therefore I would be able to achieve the following with my hypothetical networking solution:

• Start queries on the server.
• Have the server "push" results to the client as they arrive.
• Have the server "push" updates to individual results to the client as they arrive.

If I was writing this client to run on another Mac, I might well look at using Distributed Objects to mask the fact that the server was actually running remotely, but DO is not available on an iPhone.

If I was writing a more generic client-server application I would probably look at using HTTP to provide some kind of RESTful interface to searches, but this solution does not lend itself well to asynchronous updates and additionally what I am proposing does not fit well with the "stateless" tennet of REST: I would have to model my protocol so I "created" a search resource that I could subsequently query the state of and I would have to poll for updates to it.

One suggestion someone made was to make use of something like BLIP to provide me with a two-way pipe between the client and the server and implement my own "proxy" type objects for the server-side resources that knew how to fetch data from the server and additionally were addressable so that the server could push updates to them. Whilst BLIP provides the low-level messaging framework needed to communicate bi-directionally it still leaves me with a few questions:

• How will I manage the lifetime of the objects on the server? I can have a message type that "creates" a search object, but when should that object be destroyed?
• How well with this perform on an iPhone: if I have a persistent connection to the server will this drain the batteries too fast? This question is also pertinent in the HTTP world: most async updates are done using a COMET type hack which again requires a persistent connection.

So right now I'm still completely unsure what the best way to go is: I've done a lot of searching and reading but have not settled on any solution. I'm asking here on SO because I'm sure that there are many of you out there who have already solved this problem.

How have you gone about achieving real-time bidirectional networking between the iPhone and an Objective-C server-side app?

Answer 1

Starting point could be answering the following (or similar) questions:

• How much information you want to transfer?
• How quickly the server receives updates?
• How real time the communication has to be?
• Is there interaction from the client?

In case there isn't much to send just every once in a while (seconds) long polling could work. The client sends request and waits. The server send back dummy keep alive to restart a NSURLConnection session or data. The data can be serialized into xml/json.

If there is really just a small amount data over a longer period of time, the client could polling the server on a regular basis without the hassle of long polling it. In between the server can collect the new information and send diff or do the whole query for the client.

The case could be no interaction and lots of updates then this could result in a streaming like application. The server could push out it's data over a socket. Client can send data over this socket too. Ie.: acks or changing its request. As your server is ready, putting it behind a http server might be not the best option even in the case of few data. Just fund this http://code.google.com/p/cocoaasyncsocket/

Using distributed objects in client-server architecture is probably adding more complexity than helping.