Rev, sockets, IP Multicast.

Thu Mar 31 06:02:27 EST 2005

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

100, rue de Paris
F - 77140 Nemours

psahores+ at +easynet.fr
sc+ at +sahores-conseil.com

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é"