Woooaw ! What an usefull post, you share with all of us ! Many thanks
for that, Alex. I'm waiting for reading your next posts with great
interest :-)
All the best,
Le 31 mars 05, à 03:16, Alex Tweedly a écrit :
A while ago (around 2nd March), in a thread about UDP sockets, I
bemoaned the fact that Rev didn't allow for receiving IP multicast
packets.
About the same time (around 9th March), Richard Miller asked for
suggestions on how to tackle his problem for client status reporting
and monitoring. Various solutions were suggested - but at the time, I
thought how much easier the problem would be if multicast was
supported; and it kept bothering me. This is the result.
In a subsequent email, I'll describe what I've been doing to make it
possible to use IP Multicast from Rev. But first, a quick reminder of
Richard's problem description, and then the simplest multicast
solution (to show just how simple this problem would be if we did have
multicast available).
Problem Statement.
There are a number (on the order of 100) clients, which need to report
their status (status being things like - online, offline, back
shortly, ....).They will update their status relatively frequently
(say every 30 seconds). We have available a dedicated server to
collect these status reports, and to send the collected status report
to the "monitor"s. There are a similar number of monitors (~100), and
each monitor wants to get the status info for all clients, again
roughly every 30 seconds.
IP Multicast solution.
Use UDP sockets over IP multicast; each client sends its status report
to the multicast group every 30 seconds, each monitor listens to the
multicast group and so receives all the status reports.
(All variable beginning with "g" are assumed to be global, and to have
the values we need in them ....)
CLIENT CODE
initialization:
open datagram socket to "225.1.1.1:5678" -- no need for a callback
handler
send "every30secs" to me
timed event:
on every30secs
write gMyName & comma & gMystatus to "socket "225.1.1.1:5678"
send "every30secs" to me in 30 seconds
end every30secs
SERVER: There is no server needed.
MONITOR
Each monitor listens to the multicast group.
MONITOR CODE:
initialization
"listen to multicast group 225.1.1.1" -- if only we could do this
in Rev !!!
accept datagram connections on port 5678 with message gotStatusReport
on gotStatusReport p, pData
put item 1 of pData into tName
put seconds() & comma & pData into gStatus[tName]
end gotStatusReport
to get status of a user / machine
function getStatus pName
if item 1 of gStatus[pName] - seconds() > 75 then return "timed
out" return item 3 to -1 of gStatus[tName]
end getStatus
There now, couldn't be much easier - could it ?
Note that before using this for real, we would want to add a little
bit of security to protect against impostor clients - but that's only
the same protection as we'd want in any other solution.
FAQ:
1. What is this IP multicast ?
A mechanism where a single transmitted packet can be received by any
number of machines that want to hear it. There are a number of
introductions to IP multicast around, better than I would write here.
One example is http://www.tldp.org/HOWTO/Multicast-HOWTO-1.html
but many others can be found via Google ...
2. Isn't UDP unreliable ? What if packets get lost ? Or are delivered
out of order ?
Yes. It will be OK - from the problem definition, it is clear that the
monitor does not require to have the absolutely current status of the
client - it can lag behind by up to 30+30 seconds. In this solution,
the client repeats its status report frequently, so if a packet gets
lost on the way to one (or more) monitors, that monitor's view of the
client's status will lag behind for one additional time period. It's
possible we'd want to change the client reporting period from 30 secs
to maybe 20. We might also want to adjust the "75" seconds - the time
at which we decide that it's been so long since we heard from a
particular client that we wish to assume it is dead or disconnected -
down to maybe 50 secs.
Since every transaction in our protocol is a single packet being sent
one way, we will not get out of order packets unless the network is
delaying some packets by 30 (or 20) seconds, while allowing others
through. If your network delivers packets out of order by tens of
seconds, you will have so many other problems, you won't notice this
one :-)
3. Sounds good - but how can we use IP multicast from Rev ?
This is only the teaser - I'll give my (current) solution to that in
tomorrow's email - this is just to whet your appetite.
(And also to provide me with a deadline so I will complete the other
email :-)
--
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.8.4 - Release Date: 27/03/2005
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
--
Bien cordialement, Pierre Sahores
100, rue de Paris
F - 77140 Nemours
[EMAIL PROTECTED]
[EMAIL PROTECTED]
GSM: +33 6 03 95 77 70
Pro: +33 1 64 45 05 33
Fax: +33 1 64 45 05 33
<http://www.sahores-conseil.com/>
WEB/VoD/ACID-DB services over IP
"Mutualiser les deltas de productivité"
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
