I need some help in a startup project. Imagine an interactive webpage observed by a small group of users simultaneously. Each user not only observes the same page … but each others selections within the page. I guess the closest example I can muster is online poker. I don’t know if that’s about as fluid as it can get these days or not.

I am not in the web development field and suppose will be taking the matter to a consultant shortly. The immediate goal is to educate myself with differing programming/hardware/architecture structures available in completing such a project. I haven’t found any tutorials yet (probably don’t know the correct terminology) and want to interview a consultant “putting my best foot forward”.

For those willing to offer their opinion … a brief description of the project:
Startup NPO e-learning site with corporate funding
Content (static & dynamic): tutorial repository, RNG problems, testing toolbars, individual and group testing responses (write), curriculum results (read), educators blackboard for traditional e-learning

Thanks.

Sounds like the site will need to use Ajax for the kind of interactions you describe...

A bit of background info:

The basic premise behind HTTP is that it is stateless; meaning in layman terms that between any two requests, there is no information stored; which makes the development of any kind of system that needs to track usage difficult.

The first thing to solve this problem was cookies -- a small text file that was used to store state information to try and get around the stateless nature of HTTP.

Modern day tech uses a variation of client side (cookies) and server side (sessions) tricks to store state between requests. Some even pass the entire state information (ie, variables that are required) as part of the request by append it automatically to the request header.

HTTP is a request/response system. Meaning that it is asynchronous -- information flows one way, then the other. Think of it like a train track. You can only have a car moving in one direction, once its done (reached the end point), then the track becomes free and you can move in the other direction.

This is similar to how HTTP requests work. You send a request over a connection, it reaches the server, the request is terminated. The server then sends a response to your client, the response is received, and then the connection is terminated.

HTTP does not allow for synchronous information (you cannot have two cars going towards each other on the same track).

Your Problem:

Your problem boils down to the fact that you need to push information to the client from the server. Since the nature of HTTP (as described above), makes this task difficult by not allowing synchronous transfer of data -- you need to get around this problem by providing "near" synchronous experience.

One way to do this is to constantly make requests to the server to fetch new updated information. This is fine for a single client (a single user request). This would be like you want to know the status of a process that is being run on the server. You make a request, the server responds with the current status. The faster you make the requests -- the faster you will be updated.

However, in your case you need to update multiple clients with similar state information. This could be the state of a game (ie, poker). To solve this problem, you need to manage the state and the synchronization of the information on the server end. This is to ensure that information has the same currency across all clients, and also ensures the integrity of information being sent across; since your application controls it on the server.

So what you will need to do is write a process that sends for all users on the same application instance a unique identifier for that instance to the server application. This application then takes this instance id and then responds back to the current state of the application.

For example -- ApplicationA (or PageA, or SectionA, really it could be anything), is started by 5 users (User1 ... User5). This combination (users + applicationA) is called the application state, and this is given a unique id. This is done so that if at the same time a different set of users (say User6 .. User10) want to access the same app (ApplicationA), then their session is kept separate.

Once you can solve this logic out, then the rest becomes trivial. What information to send across depends on the application -- what will change between requests. How often you need to request the information, will then be dictated by the nature of the app -- for example, you wouldn't need to update the app every minute if it is tracking the football score, but if its tracking stock information then you need to change the frequency. Also, if your application is one that is user triggers (also called "turn based") then your update trigger is determined by the user. An example of this is your poker game -- the only time you need to update the other players is when someone does something, plays a hand, etc. So that determines your update frequency.

Hopefully that will give you the bigger picture. The rest of it is not a challenge as its not a unique problem set to be solved :)

The above -- is free information. :D

A bit of background info:

The basic premise behind HTTP is that it is stateless; meaning in layman terms that between any two requests, there is no information stored; which makes the development of any kind of system that needs to track usage difficult.

The first thing to solve this problem was cookies -- a small text file that was used to store state information to try and get around the stateless nature of HTTP.

Modern day tech uses a variation of client side (cookies) and server side (sessions) tricks to store state between requests. Some even pass the entire state information (ie, variables that are required) as part of the request by append it automatically to the request header.

HTTP is a request/response system. Meaning that it is asynchronous -- information flows one way, then the other. Think of it like a train track. You can only have a car moving in one direction, once its done (reached the end point), then the track becomes free and you can move in the other direction.

This is similar to how HTTP requests work. You send a request over a connection, it reaches the server, the request is terminated. The server then sends a response to your client, the response is received, and then the connection is terminated.

HTTP does not allow for synchronous information (you cannot have two cars going towards each other on the same track).

Your Problem:

Your problem boils down to the fact that you need to push information to the client from the server. Since the nature of HTTP (as described above), makes this task difficult by not allowing synchronous transfer of data -- you need to get around this problem by providing "near" synchronous experience.

One way to do this is to constantly make requests to the server to fetch new updated information. This is fine for a single client (a single user request). This would be like you want to know the status of a process that is being run on the server. You make a request, the server responds with the current status. The faster you make the requests -- the faster you will be updated.

However, in your case you need to update multiple clients with similar state information. This could be the state of a game (ie, poker). To solve this problem, you need to manage the state and the synchronization of the information on the server end. This is to ensure that information has the same currency across all clients, and also ensures the integrity of information being sent across; since your application controls it on the server.

So what you will need to do is write a process that sends for all users on the same application instance a unique identifier for that instance to the server application. This application then takes this instance id and then responds back to the current state of the application.

For example -- ApplicationA (or PageA, or SectionA, really it could be anything), is started by 5 users (User1 ... User5). This combination (users + applicationA) is called the application state, and this is given a unique id. This is done so that if at the same time a different set of users (say User6 .. User10) want to access the same app (ApplicationA), then their session is kept separate.

Once you can solve this logic out, then the rest becomes trivial. What information to send across depends on the application -- what will change between requests. How often you need to request the information, will then be dictated by the nature of the app -- for example, you wouldn't need to update the app every minute if it is tracking the football score, but if its tracking stock information then you need to change the frequency. Also, if your application is one that is user triggers (also called "turn based") then your update trigger is determined by the user. An example of this is your poker game -- the only time you need to update the other players is when someone does something, plays a hand, etc. So that determines your update frequency.

Hopefully that will give you the bigger picture. The rest of it is not a challenge as its not a unique problem set to be solved :)

The above -- is free information. :D
Thanks for helping us out Burhan. After my initial post, I stumbled across a website called Virtual Whiteboard (sorry no url provided as I am under 5 posts). It’s a bit too freeform for system generated problems (no solution authorization) but is still a useful module for informal teacher to students group interaction on our site. I tested the response time between multiple terminals, within our group, and it was very impressive (under 1 second).

I don’t know what limitations such programming (AJAX) would carry for us. Are there user end technology considerations at stake (browser, connection speed, etc.)? It is our vision for all youth to engage others within the site … regardless of their global location and current setup.

Also, is it possible that too many users participating in the same group (or too many groups) will slow our site down? Referencing your insightful tutorial, the group module will be turned based. I’m a bit fuzzy on the whole mathematical relationship between bandwidth and site speed (functionality) … and how this feeds into “scalability”. I’ve heard about managed dedicated servers and, as our NPO will not have a large IT staff for oversight, wanted to get your opinion about this and open source CMS like Joomla.

Hope you don’t mind all the questions. I thought, as you are in the IT consulting industry, that you could prove a useful resource. Thanks again.

Most relatively modern browsers will have no problem with AJAX provided that your code accounts for brain-deadness (IE for example). There are some very good AJAX tool kits that already account for this, all you have to do is ensure that the pages are crafted in standards compliant XHTML/HTML.

As far as scaling, sessions and SQLite are your friend. Consider storing temporary stuff for 'groups' such as the turn token in disposable SQLite databases vs temporary MySQL tables. As long as the user's session relates them to a group, and the group db relates the turn token to a session ID ... you'll avoid a 'racey' application without much overhead.

I'm soon to be confronted with a similar scenario while writing a web UI to control virtual servers on a grid. At any given time, 3 or 5 admins might be logged in and doing stuff.. the UI will have to account for this so that each admin knows what the other is currently doing.

First -- some common concepts.

Bandwidth - This is literally the "width" of the "band" that you are using. This is how much theoretical output you can have. Bandwidth speaks in total volumes of information in relation to time. So a bandwidth of 10 megabits per second means the maximum sustainable output from this channel, is 10 megabits per second. In other words, if you turn the tap full open, you will get a maximum of 10 megabits per second out of the pipe. Nothing more.

When you say "speed of a site", I'm sure you mean the perceived speed by the end user. This has many factors that come together to get you the end result (the page you see). A few that you can think of:

1. Disk speed
2. Size of the database
3. Optimization of the database (some people often call this normalization, but they are two different things)
4. View/template rendering system or engine
5. Caching
6. Physical distance between your server and various components (is the database server and the web server in two different physical areas?)
7. The logical distance between your server and various components (how many network points are in the middle of your database and your web server)
8. The computing capacity of the server itself. It is underpowered? Is it meeting only the "recommended specifications"?
9. The bandwidth to the Internet

All the above are things you can control, there are other factors that contribute which are to a lot of extent, out of your control:

10. Distance between your user and your server (logical)
11. The user agent or client program at the end user
12. The system specification of the end user
13. Any browser addons that the end user may be running (popup blockers, firewalls, plugins, etc.)
14. Language of the system

All those combined to create the "speed" of your site. So, keep in mind that the majority of the above you can control, so spend your efforts there. The 4 things you cannot control, try to minimize the time you spend on them; however note that the last four are the only criteria your site is judged on. In other words, no one is going to care if you have the fastest server with the most optimized database -- if the site doesn't work in IE.

AJAX carries its own set of issues:

1. It relies heavily on the user agent. This means that small fluctuations in point 10 - 14 above, can have a heavy impact on your ajax application.

2. Since it runs on the user agent, it is limited by the rules of javascript -- its sandboxing model. It cannot do things (like read local files, access other servers) due to the sandboxing and security frameworks in place. Keep this in mind when you develop.

3. Standardize. Use any of the ajax libraries out there, but use one that provides commercial support, and use it exclusively. You don't want to be in a situation where your business app is hanging because your developer cannot figure out something, and then there is no support from the "company behind it" because there isn't any "company" behind it.

Regarding servers and server setup. "Managed dedicated" servers have the following properties:

1. It is one physical box, that you are renting from your provider.

2. "Managed" means that your provider will take care of things (varies from management contract) such as security updates, configuration of server systems ("Install version 1.2.3 of software xyz"), monitoring, and general administration services, which vary from provider to provider. The idea behind managed dedicated servers is that you (the customer) worry about your business application; the provider worries about the server that is running it. Things to consider when going with managed dedicated:

1. Does your provider own their datacenter or are they simply renting space from another provider?

2. What are the qualifications of their on hand technical support? Can they deal with the technology that you will be using for your project? Example: if you are going to be running Oracle and Java, you really don't need a provider that has tons of "LAMP" fixers.

3. What is the financial status of your provider? Are they in risk of going bankrupt? In this day and age of fly-by-hour Internet "providers" this is very paramount. Consider what would happen if your provider simply shut down? Which brings me to..

4. Backup and retention. What are their policies? How are they implementing it? What is the delay in retrieving backups? When are backups taken "offline"?

5. Business Continuity - do they have a "warm" site in case their main site is down? You don't want to be in a situation where all their servers are in one DC, and when there is a disaster (natural or other) you want to have a contingency in place.

6. Most providers will offer you a SLA. Find out what are the penalties if they fail to meet it, and get a third party to monitor it for you.

Finally -- on open source CMS systems:

I like some OS systems, but most are generally not "content" management, they are "website plugins and modules management with a rich text editor" systems. The difference? Its the "C" in CMS. Content. What do you want to manage? If its just your website and related media, then any of the OS scripts will do you fine....however, once you start talking about ... what I like to call "adult" CMS features such as workflow, revisions, rollback, audits, object level ACLs, content repositories -- the field gets pretty thin.

So, before you look at any open source system; know what you need your system to do and know what would be nice to have. Generally we get so enamored by the "ooh ahh" features, that we forget the need part.

From what I have seen so far, you would need a separate engine to run the core application; you need a system to extrapolate information from this core system to make it available for various output channels; you need one system that will be responsible for rendering the front end -- and finally you need a system the so-called "middleware" to tie them all together.

From what I gather the only output channel you have so far in mind is the browser; so your front end will need to run on one of the technologies that browsers support (flash, javascript, html, java applets).

If you are targeting all youth "regardless of their global location"; I assume you are also concerned with localization; which has its own set of check lists :)

Hope that helps :D