[lug] OT: UDP multicast question

[Brad Doctor]

Actually, multicast works very well and is quite easy to use w/linux.  As for
it's applicability to this problem, I won't comment.  But if you need lots
of clients to be able to simultaneously receive the same message, I have found
much luck with multicast, and in fact am watching it work right now :)  

Perl has a very easy interface via IO::Socket::Multicast.

-brad

> 
> "Scott A. Herod" wrote:
> > 
> > In his _Network Programming, Vol. 2_ , Stevens has an example of
> > a one-to-many fifo based broadcaster.  That's what I'll probably
> > use.  However, all I really want to do is send a note to many
> > processes that table T, row R changed so that if they care they
> > should go look to see what happened.  I want to make the message
> > route as simple as possible and avoid polling ( other than internal
> > select() calls ).
> 
> The publish/subscribe is still good for that, you can however limit it
> to publishing metadata about what row and column changed, rather than
> actual data. The one-to-many broadcaster I suspect is basically that,
> the real meaning behind publish/subscribe being that random processes
> can register their interest (as subscribers), or deregister
> (unsubscribe).
> 
> D. Stimits, stimits at idcomm.com
> 
> > 
> > Scott
> > 
> > "D. Stimits" wrote:
> > >
> > > "Scott A. Herod" wrote:
> > > >
> > > > Hello,
> > > >
> > > >   I'm not much of a network programmer so this may be an
> > > > obvious question.  Can I have multiple processes on a single
> > > > machine listening to a local udp multicast?  This is with IPv4,
> > > > but would IPv6 make a difference?  (MySQL doesn't implement
> > > > triggers and I need to tell several processes when a table
> > > > changes.)
> > >
> > > I wouldn't try it with IPv4, don't know if IPv6 is different. As soon as
> > > a process reads the buffer you can expect the data to go away, or else
> > > for it to be marked as empty. I'd guess the same is true for IPv6 but
> > > don't know. You would probably be better off creating a surrogate daemon
> > > that does the listening, has either an update buffer or a notification
> > > of change, and allows multiple subscribers; it would publish to anything
> > > subscribed. You could go as far as to offer an ability to subscribe to
> > > particular sql servers, databases within servers, tables within
> > > databases, so on. Then you are totally isolated from the type of sql
> > > server. Lots of fun things you can do with it, depending on what you
> > > want as the end goal, but I doubt you'll get anything other than
> > > surprises if you have multiple processes trying to listen to the same
> > > UDP socket and expecting them to get the same information.
> > >
> > > D. Stimits, stimits at idcomm.com
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 


-- 
Brad Doctor, CISSP