Suggestions?

[Richard Miller]

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