Suggestions?

[Richard Miller]

This is most similar to the way I was imagining doing it. It does 
appear to be simple. And yes, the users are not very numerous (no more 
than 100 for the next six months) and they are all unique (one user per 
computer reporting their availability).

Thanks.
Richard


On Mar 7, 2005, at 7:02 PM, Alex Tweedly wrote:

> 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
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>