Syncing data across clients with a limited set of tools (no websockets, limited number of threads)

Goal I'd like to achieve

I need to implement some kind of subscribing to events method. To be exact, people can lock cells in tables (more users can look at the same table simultaneously) and the tables need to be updated when someone else locks a cell. (So users don't try locking the same cell multiple times.) I count with 45-50 users at least. (There are multiple tables (on a limited number of separate webpages, loaded with AJAX - transferred using JSON which I encode server-side.)

Limitations, resources and ideas

• I have no bandwidth and disk space limitations. The available server's Disk IO is 2MB/s, Memory is 768MB (this is all available).
• I must support an old version of Chromium (I believe 3) that does not support websockets. I must fall back to Long-Polling or any other technique.
• The webpage runs on a shared hosting with the limitation of 15 PHP Processes. This means that using the standard long-polling technique could only support maximum 7-8 people on the page, which is not enough for this project.
• Node.js is not available with this hosting provider.

I had the following idea:

Using a frequent running CRON Job I can generate and write the json strings to files - clients can download the json files periodically and update the table if there is a change.

I know that does not sound very elegant, so I decided to ask around before I implement the plan above.

With that set of server-side limitations, you probably want to just use polling in the client. The client will issue an ajax call asking for updates on a timer. The server will provide the latest state to the client each time it receives the ajax call. You will have to manually adjust the frequency of the client polling according to the scale you want to support (higher scale means longer between polling intervals) and the impact the scale has on your server-side limitations.

Client polling will be bad for bandwidth usage so you will have to quantify what you can live with there (measure the bandwidth used by N clients polling at a certain interval and adjust the frequency of polling accordingly).

Obviously more modern technologies such as continually connected webSockets or even long polling will give you better responsiveness and lower bandwidth usage, but you seem to have ruled those out because of your server-side limitations. The preferred solution would be to fix the server-side limitations. If you use socket.io, it will automatically fall back to long polling for the client that doesn't support webSockets.