Suggestions?
Alex Tweedly
alex at tweedly.net
Mon Mar 7 19:02:31 EST 2005
Richard Miller wrote:
> Looking for suggestions on how to best handle the following scenario.
>
> Imagine a number of computers spread out across the country (some
> PC's, some Mac's) running a custom Rev application. On each computer,
> the application continually (every 30-60 seconds) sends a small file
> (just a few characters) into a central server. This file contains
> information about the availability of the user (available now, within
> 10 minutes, not available). Let's say there are 100 of these computers
> and applications running at any given time, all reporting in every 30
> seconds or so.
What's the relationship between the "user" and the computer ?
i.e. can the same user be on 2 of the machines at the same time ?
if so, what should be reported as the status for that user - the one
that happened to give the most recent status, or the most available? or
what ? Does the status say "User 1 is available now on machine
123.1.1.1" ?
if not, is there already a scheme to prevent it (or simply an assumption
that it shouldn't happen) ?
is there a finite set of users ? how big ?
or is "user" equivalent to "computer" ?
> I've also got another 100 computers (all Mac's) running a different
> Rev application. Each of these computers needs to know the combined
> status of the first 100 users, continually polling for this data every
> 30 seconds. So, for example, at any given moment it knows:
>
> User 1 is available now
> User 2 is not available
> User 3 is not available,
> User 4 will be available in 10 minutes
> etc..
>
> I've got a dedicated Mac server available, on which I want to place a
> Rev application to gather and disseminate the required information.
> The first 100 computers will continually inform that central
> application of their status, and the other 100 will continually ask
> this application for the status of the first 100 users.
>
> Suggestions on how to do this. I've quite a number of ideas, but I'm
> not sure of the fastest and most stable (and perhaps easiest) way. One
> concern is with multiple users (the ones supplying data) trying to
> check in at the same time.
Best way : (esp. if your user base might grow over time) - central app
using a database.
But for the current problem description this is probably overkill.
Depending on your answers to the above questions, you could probably do ....
Simplest way:
(NB Only if users are unique and not too numerous)
create a status file per user.
on the user client:
put myStatus into URL ("http://remote.machine.net/statuses/" &
myUserName)
on the server:
run a Rev script that every 10 seconds (or whatever level of currency
is required) does the equivalent of
cd /httpdocs/statuses
cat * > ../newstatus
cd ..
mv newstatus allstatus
(or just stick that shell script into a cron job)
on the other clients:
put URL "http://remote.machine.net/allstatus" into allStatus
No programming (or almost no programming) to do, very simple, easy to
monitor (just look at files and dates).
Interlocks are handed by the file system - the rename is an atomic
operation, so safe (on Unix - I'm assuming OS X operates the same way)
from read/write clashes.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 02/03/2005
More information about the use-livecode
mailing list