Rev, sockets, IP Multicast.

[Alex Tweedly]

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