[lug] OT: UDP multicast question

[D. Stimits]

"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