Suggestions?

[Alex Tweedly]

Richard Miller wrote:

> 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).

I should probably confess that if it was me who was doing it, I'd 
probably do some TCP sockets programming, as suggested by Richard Herz. 
But I stand by the URL / file solution as being the simplest and easiest.

One warning though - beware of synchronization problems. Networked 
problems like this always tend to fall into synchronization patterns, 
that can cause problems.

I did the simple calculation :
each update is maybe 30 characters of data (200 chars including TCP 
overhead)
each retrieve is maybe 3000 character of data (3200 including overhead)
100 clients each 30 seconds = 3 updates per second plus 3 retrieves per 
second - no big deal.
Of course they'll be randomly spread, not evenly, so there will be some 
1-second periods with as many as 6-10 of each
10 per second is a total of 34K bytes per second = 280kbs -starting to 
be a problem if the server is behind a basic DSL or similar
(You may want to consider ways to compress or encode the status for a 
retrieve.)

However, all kinds of small events can lead to synchronization. If the 
server's network connection is down briefly - say for 5 seconds, then 
all attempts to update and retrieve will stall. They won't fail in such 
a short time, but they'll stall. When the network recovers, they'll all 
succeed at more or less the same time.

So if you code this the simple way, as in

on sendMyStatus
   put gMyStatus into URL ("http://www.remote.net/statuses/" & gMyUserName)
   send "sendMyStatus" to me in 30 seconds
end sendMyStatus

then all 15-20 machines that were within that 5 seconds interval are now 
(more or less) synchronized at the "end" of the interval.

So you now have a one second interval with 20 or more updates and 
retrieves - you're now up to a network demand of almost 1 Mbps. And 
these small glitches tend to accumulate - server power cycles, or 
network losses, or network congestion, or ... many other problems can 
contribute - and they tend to build together.

So - simplest answer is to use the counter-intuitive coding method

on sendMyStatus
   send "sendMyStatus" to me in 30 seconds
   put gMyStatus into URL ("http://www.remote.net/statuses/" & gMyUserName)
end sendMyStatus

This keeps this client on its "every 30 second" frequency, regardless of 
any delays. Intuition (at least mine) makes me avoid doing this normally 
(e.g. for screen updates) - but for network sync it can be an easy way.

Better might be
on sendMyStatus
   send "sendMyStatus" to me in (25+random(10)) seconds
   put gMyStatus into URL ("http://www.remote.net/statuses/" & gMyUserName)
end sendMyStatus

which will spread this client's requests out over a period in time, and 
hence minimize sync issues.

Sorry - this turned into a longer email than I had expected - but it is 
an important issue. I've seen too many solutions work for a while in 
testing, and then grind to a halt in extended production use.

-- 
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.7.0 - Release Date: 08/03/2005