Take me HOME
Crazed(Sanity)
The TTORP Comet
Monday, January 02, 2012 11:21 PM

Introduction

I'm trying to build a very responsive web application.  Something that can handle "real time" chatting and so forth, but at the same time something that won't require a massive infrastructure to handle.  I've used Ajax, and it works to a point, but doesn't really scale very well. 

I did a very simple test to see if a standard Ajax-based system would work.  I created a "ping" test, where each client (browser) that connected would do a very simple request to the server, one right after the other, to see how quickly clients could get updates.  I saw the server's load was immediately affected.  When I scaled it up to 5 clients, there was a very significant increase in the server's load... which made me realize that it simply would not scale well at all.

Trying to Scale

So I've looked into some alternatives that will resolve this scalability issue.

The "Comet Programming" technique seemed to be a way to overcome this obstacle, so I started looking for pre-built solutions.  The "APE" project (Ajax Push Engine) seemed to be the answer, especially after reading the documentation and the easy-to-understand comic explaining standard Ajax versus Comet (or APE, which is a form of Comet).

The Reason...

Now, the reason for all of this is mostly for a web application I've built that has been nicknamed "TTORP" (Table Top Online Role Playing; a.k.a. "Battle Tracker" or "cs-battletrack").  It's a system where people that like to play the old pencil-and-paper table top RPG games can use to make things faster.  Storing character sheets, and (eventually) chatting & having a screen that shows what's happening in a battle in real time.

Comet

So... back to the Comet thing.

I tried working with APE and a few other systems.  They were very complicated, to the point that I didn't really know how they worked at all.  I've worked with Darkman (long-time friend and associate) to figure this out, but it just never worked for me.

Then, one day when I wasn't even thinking about it, a light suddenly turned on (like in the cartoons).  I read a bunch of things online about others trying to implement a Comet system (specifically with PHP), but there wasn't a pre-built framework available... and I realized that I already had 99% of the necessary libraries for PHP already done! With a little planning, I realized that I could built this framework into one of my existing libraries, "CS Web App Libs."

Building My Own Solution

So... the way I plan on implementing my own Comet framework is simple (where "simple" is used pretty loosely).  The premise behind the system is that everything will log important events to the server's log using the "webdblogger" system built into "CS Web App Libs."  The backend system will have a "long poll" script that will scan for changes: it'll start into a loop, looking for new changes every second; it'll go for 60 seconds, and will either return results immediately when some are found or once that number of seconds has elapsed.

On the front end (browser), there will be two different request types: "LP" for Long Polling, and PITR for Point In Time Requests.  The LP "thread" will be dispatched right away, and will be running for the duration that the page is open.  The server will hold on to this request, only returning when the allotted time (60 seconds) has expired or new information is available.  The PITR will fire whenever the user does something (e.g. clicking a button).

How It works...

The idea is basically that the "LP" will be listening for changes.  The page that is requested by the LP is built to wait for scan for events, so it can be ultra-responsive without requiring the browser to send a flood of requests (see the APE comic on this). There would be just two requests if an event happens in a minute (at 30 seconds, it returns, then another request is fired off to watch for more), whereas no polling means there would be 60 requests (one per second).  Without polling, there would be 60 requests, and probably still a delay: if the event happens right after a request is returned, there could be a full second delay, whereas LP would catch it right away.

So here's a chart that basically explains this "conversation" over a 5-minute period using LP:

 Conversation using LP (click for larger)