Rev, sockets, IP Multicast Part II

[Alex Tweedly]

In part one, I briefly explained one reason why it would be native to 
have support for IP multicast in Rev - it provides very clean, easy 
solutions for certain types of problems.

But how can we use IP Multicast when Rev doesn't support it ?

[Remember - we can send multicast packets - it's only receiving them 
that is unsupported.]

First obvious answer is to submit a Bugzilla request for multicast 
support - but quite honestly I don't see it as being a top priority for 
RR to do. Even as a multicast enthusiast and advocate, I can't see 
adding this feature as a high priority for RunRev.

Second obvious solution is to write an external - but that sounds hard; 
I've barely written my first trivial external, and this one would need 
to generate asynchronous callbacks, etc.  - so I decided it was the 
wrong thing to try for my first real external.

Then the recent discussion about the possibility of solving a problem 
using multiple tools, with sockets to communicate between them gave me 
the third obvious solution.

I've now written a "multicast bridge" - a program which can be run as a 
"server", accepts commands (on a UDP socket) to listen to a multicast 
group/port, and forwards everything each packet it receives to a 
specified UDP unicast port. You'd need only a single copy of this 
running on each machine - and any or all Rev apps which wanted to 
receive multicast packets could make use of it. I wrote this in Python - 
though it could easily be translated to C or C++ - but life really is 
too short for that; the Python version works just fine, and will handle 
reasonable packet rates.

The application (in Rev, or any other language without native multicast 
support) sends commands to the "bridge" requesting that any packets it 
(the bridge) receives on a particular IP multicast group / port 
combination should be forwarded to the (unicast) IP address / port 
specified by the app.  Normally, the app and bridge should be on the 
same machine - in fact, the default mode in the "bridge" is to only 
allow this case.

Caveats:
1. IP Multicast is not universally supported on networks - so check that 
it is available everywhere you need it before committing to using it in 
a project.

2. The multicast "bridge" is a potential security hole if used 
carelessly - keep to the default Secure mode or if you need the 
flexibility. implement some real security such as md5 shared secrets 
(this is pretty simple - if you want to do it, let me know and I'll post 
the extended version of the bridge code and client stack).

I'll try to post the sample client stack to RevOnline (as soon as I 
figure out how to do that without overwriting one of my existing 
stacks). I can't post the Python code for the multicast bridge there - 
so it is available from my web site, as is the Rev stack.

The bridge code is at www.tweedly.net/RunRev/mcast-bridge.pyt
A very simple python test program is at 
www.tweedly.net/RunRev/mcast-client.pyt
A similarly simple test stack is at www.tweedly.net/RunRev/mcastclient.rev

If you've never used Python - download a (free) copy (www.python.org), 
it's easy enough to use.

Feel free to email me (on- or off-list) if you run into any problems, or 
have any questions.

-- 
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.6 - Release Date: 30/03/2005