Lately I’ve been busy trying to implement a SMS interface for a small community radio station.
The way it works is this: we’ve got a provider who recieves the SMSes on our behalf through a geographical telephone number (i.e. it starts 01227). Once they recieve the SMS, they will use HTTP POST to send it to our servers. It gives us the message, a unique ID for the message, timestamp and other such things. Once we’ve got the SMS, we have to do something with it.
Problem: How do you handle incoming SMSes in a live broadcast situation?
When in the middle of a live broadcast, every second counts. If a presenter asks the audience a question at the end of a link, and then there is a 3-5 minute song until the next link at which point they will want to read the answers out on air. The faster we respond to listeners, the more likely they are to interact with us again. So the aim of the game is to get the SMS from the phone to the presenter as promptly as possible.
Approach 1: Pull PHP/HTML interface
Lets say we have a script which takes the HTTP headers and stores them all into a table in a database. We then have another script which p0lls the database, and generates a HTML web page with all of the latest SMSes to be entered into the DB. This is fine, but we’d need to refresh the page frequently. We could do this with AJAX or similar. But, unless you are refreshing the feed very often (say, once every second), you’re going to induce an amount of latency. Also the constant polling of the XML file will generate load on the client, and the server, and cause lots of data to flow over the network even when there are no new messages arriving.
This method I would call “pull”. Whilst the message is being “pushed” to us by our gateway provide, we are then buffering it and waiting for the client to pull it back out of storage. Let’s not get all starry eyed about it – HTTP XML feeds are pull. Pull methods will always have a timliness vs. resource utilisation tradeoff.
However, this approach will work OK on any standard web server with no special requirements.
Approach 2: Ajax Push
So perhaps a better way to go would be to push the message all the way from the SMS gateway to the end user. We change our script that it will not only store the message in a database, but also notify the clients that a new message has arrived such that they can display it to the end user immediately.
After much googling around, I came across the APE Project (Ajax Push Engine).
APE is a full-featured OpenSource solution designed for Ajax Push. It includes a comet server and a Javascript Framework. APE allows to implement any kind of real-time data streaming to a web browser, without having to install anything on the client-side.
The interesting thing to note here is that whilst HTTP feeds are normally pull, the APE server is a custom HTTP server which is written to allow the HTTP server to push data to the clients using some clever method (what I’m guessing is the Ajax with long polling method going by what I’m seeing in Firebug).
I spent about 20 minutes setting up the APE server on a Ubuntu Server VM. Took a little tweaking (the docs aren’t so clear here), but works excellently.
Then I found EsenAPE, on Paul’s Blog, which is almost exactly what I need. The only trouble is that he’s using Esendex, who is not who I’m using. So I’ll have to rewrite the inbound part. Also, there’s currently no way of having the historic messages shown when you first log in, which is a must for our problem. I’ll have to do some modifications to get that working. Apparently you can write SSJS modules to interface with MySQL databases, so that is likely the route I’m going to be taking.
How exactly we end up implementing this is yet to be seen, but I’d like to try out the APE server and see what it can do for us. The ability to push data around out network, and from outside of our network, in real-time is quite exciting.