Thanks for this feedback. Much appreciated.
Richard
On Mar 9, 2005, at 6:05 AM, Alex Tweedly wrote:
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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution