Socket vs HTTP based communication for a mobile client/server application

Question

I've recently decided to take on a pretty big software engineering project that will involve developing a client-server based application. My plan is to develop as many clients as possible: including native iPhone, Android and Blackberry Apps as well as a web-based app.

For my server I'm planning on using a VPS (possibly from slicehost.com) running a flavor of Linux with a MySQL database. My first question is what should be my strategy for clients to interface with the server. My ideas are:

1. HTTP-POST or GET based communication with a PHP script.
   This is something I'm very familiar with - passing information to a PHP script from a form, working with it and returning output. I'm assuming I'd want to return output to clients as some sort of XML or JSON based string. I'm also assuming I'd want to create a well defined API for clients that want to interface with my server.

2. Socket based communication with either a PHP script, Java program, or C++ program
   This I'm less familiar with. I've worked with basic tutorials on creating a script or simple application that creates a socket, listens for a connection and returns data. I'm assuming there is far less communication data-overhead with this method than an HTTP based method. My dream is for there to be A LOT of concurrent clients in use, all working with the server/database. I'm not sure if a simple HTTP/PHP script based communication design can scale effectively to meet the needs of many clients. Also, I may eventually want the capability of a Server-Push to clients triggered by various server events. I'm also unsure of what programming language is best suited for this. If efficiency is a big concern I'd imagine a PHP script might not be efficient enough?

Is there a commonly accepted way of doing this? For me this is an attempt to bridge a gap between some of my current skills. I have a lot of experience with PHP and interfacing with a MySQl database to serve dynamic web pages. I also have a lot of experience developing native iPhone applications (however none that have had any significant server-based communication). Also I've worked with Java/C++, and I've developed applications in both languages that have interfaced with MySQL.

I don't anticipate my clients sending/receiving a tremendous amount of data to/from a server. Something on par with a set of strings per a given client-side event.

Another question: Using a VPS - good idea? I obviously don't want to pay for a full-dedicated server (slicehost offers a VPS starting at ~ $20/month), and I'm assuming a VPS will be capable of meeting the requirements of a few initial clients. As more and more users begin to interface with my server, I'm assuming it will be possible to migrate to larger and larger 'slices' and possibly eventually moving to a full-dedicated server if necessary.

Thanks for the advice! :)

Rist

Hi Casey. Which method did you ultimately choose? I have the exact same requirements you had and I'm also wondering about which of these methods to implement. – Martel

Hi @Johan, I don't know the specifics of your requirements - but I'm definitely an advocate of using HTTP POST/GET requests for client/server communication. If you're developing a mobile app to run on different clients, consider using a web based mobile-app framework such as sencha-touch or jquery mobile w/ phonegap. As phones and tablets get more and more powerful, the discernable differences between native and mobile apps get smaller and smaller. If you need any realtime-communication try 'pusher' And lastly use a PAAS. I recommend APPFOG or CloudFoundry. They're open source :) – Rist

Thanks @Casey. My speific requirements are simple, but there's so many options available. I have a hardware device that sends data to a server. The server must then send notifications to mobile devices (android/iphone/bb) as required. The devices will also send commands to the server which will be relayed to the hardware device. The system can potentially have thousands of connections and it must be very responsive. For the server, do you suggest I use php to handle the http requests? Or stated otherwise, given my requirements, what do you think is the best method to implement the server? – Martel

For what language to implement the server in, depending on your available developers and resources, PHP may make sense. Ruby can also get the job done. If you're truly worried about handling a large number of concurrent connections nodeJS is a relatively new technology that's known for being 'non-blocking' meaning it specializes in handling concurrent requests. Depending on how complex the communication between your mobile apps are and your server, you might be able to use two-way text messaging to communicate, I recommend "twilio" – Rist

Answer 1

I'd say go with the simplicity of HTTP, at least until your needs outgrow its capabilities. (The more stateful your application needs to be, the less HTTP fits).

For low cost and scalability, you probably can't go wrong with a cloud like Rackspace's or Amazon's. But I'm just getting started with those, my servers have been VPSs from tektonic until now.

Victorvictoria

Could you elaborate a bit about what you mean by 'stateful?' Thanks! – Rist

en.wikipedia.org/wiki/Stateful. HTTP is a stateless protocol, although there are numerous tricks that are used to make it hold state. – Victorvictoria

and as for language, I'm not fond of PHP for various reasons and prefer Python myself, but if you're good at PHP I see no overwhelming reason not to keep using it. – Victorvictoria

Hmm, rackspace looks pretty interesting. Thanks for the tip. I'm assuming a HTTP-POST based communication setup would prevent me from executing a server-event based server-push to the application? The application would have to query the server to get updates? – Rist

let's just say I know of no way to push from server to client using HTTP. I hate to say it's impossible because, almost inevitably, someone eventually proves such assertions wrong. I made quite a career of doing "impossible" things in my day. – Victorvictoria