Push vs. Pull and the Twitter Client

Posted on | June 25, 2009

Not long ago I exchanged a couple of twits with @makonja about the possibility of having push notifications in an iPhone twitter client. Since I saw that there is a bit of confusion around push and pull/poll techniques of providing server data to the client I decided explain this first. I think it is possible to create a Twitter client that will leverage Apple’s push tecnology for the iPhone, but in a different architecture than is used for current clients - a more complicated one.

The Basics

Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. It is contrasted with pull technology, where the request for the transmission of information is initiated by the receiver or client.

source: Wikipedia

To make it even clearer - in a server-client setup the client can get data in two ways. The first way is by issuing a request each time a set of data is required. The second way is by sitting back with an open door in order to recieve the data when the server feels like sending it.

The Twitter API

Twitter’s API is a REST based API which is meant to respond to specific API calls.  This means that your application (in this case a client) needs to make requests (poll each X minutes) to the Twitter uber-servers and wait for the response which contains some data. Twitter does not push any data (never), it just responds to your requests. So in order to see changes in your twitter stream you need to wait for the next request. I hope this is clear :)

The Usual Twitter Client

Most twitter clients (Tweetie, Twhirl, TweetDeck, Twitulater…) work directly with Twitter and its API. Their only way to get fresh data is to make a new request and wait for the response. Since the guys at Twitter understand that too many requests may lead to more Fail Whales they usually limit the number of API calls per account/hour. I think the limit is currently set to 100 requests per hour for each account, meaning that you can have fresh twitts fetched to your client every 0.6 minute (36 seconds). Not quite real time, but close enough.

The second important point (which should actually be the first) is user authentication. In this “usual client” scenario users’ credentials are posted from the client directly to Twitter - there are no proxies or middle-mans involved, so there are fewer chances of reusing/stealing your credentials.

The Usual Twitter Client Meets the iPhone

Twitter clients on the iPhone can not run in the background because of the sandbox approach Apple decided to use. This means that the clients can only make requests to the server when they are active in the foreground. The logic described above does not apply and the client can not make a request every 36 seconds, but it needs to wait for the user to turn it on.

iPhone (Apple’s) Push Technique

Since Apple does not allow background applications on the iPhone (mainly because of battery life issues) they promised to enable push notification via an Apple controlled push server. I did not know the details of Apple’s magic server but there are two main approaches that can be taken. One is to have an active connection between the client and the server, the other is a background application listening to specific events that can be sent to this application imagine a small server that is waiting to be contacted by a client - so the roles are inverted. Since Wikipedia has an answer for (almost) every possible question there is no need for my guessing :)

The Apple Push Notification Service is a mobile service created by Apple Inc. that was released with iPhone OS 3.0 on the 17 June 2009. It uses push technology through a constantly-open IP connection to forward notifications from the servers of third party applications to the iPhone or iPod Touch; such notifications may include badges, sounds or custom text alerts. (source)

Now what are the implications of such an architecture. If Apple would sell 50 million devices and all those devices would have “push notification enabled” Apple should handle 50 million constant connections. Not a trivial problem and that might be the reason why they are delaying the push notifications so much. Secondly this connection requires some exchange of data between the mobile device and the notification servers (the so called keep alive messages) which will be billed to the user if she does not have a flat rate data plan.

In my humble oppinion Apple could have opted for a different approach, but who am I to question them and why should you care, the important thing is that now we both understand the architecture behind :)

The (Magic) Push Enabled Twitter Client

So far I have described all the components in the architecture and how each of this components works. A push enabled Twitter client should have a server that would fetch your twits each 36 seconds and inform Apple’s push notification service about the potential update. Apple’s notification service would forward this notification (via the constantly-open IP connection) to the iPhone which would display a message containing the new twits or just update the counter of unread twits on the badge or/and play a specific sound alert.

Compared to a “usual” Twitter client you would need an additional server (or many of them if you plan to have more than 5 users). In addition to that all your users will have to give you their credentials so your server would have access to their Twitter profile and their new twits.

A Quick Final Note

I know you must be tired if you read the whole post but there are still some final notes I would like to make. I think a push enabled Twitter client is easily feasible as a proof of concept but I think the costs of maintainance for an implementation of this kind of service would be to high compared to the benefits. I might have got some things very wrong, so please correct me if you see a mistake or a wrong understanding, I will be happy to correct the post.

Comments

Search