Hi Erick,
> On Wed, Sep 22, 2010 at 5:05 AM, Kelly Brock <[email protected]> wrote:
> > Looks like a nice start.
>
> Thanks! I'm a zeromq and bonjour newbie, so I am happy for any and all
> suggestions. This code's basically just modifying the pybonjour
> tutorial, and I thought it could be another alternative to the
> bonjour/avahi/etc discussion.
>
> > Just a couple thoughts though:
> >
> > 1. With the auto resolution the messages are going to be massively
> > spammy in a large scale system. Just an example, for 40k our services
> were
> > each defined as: "_<service type>_<shard hash>._tcp". So, with 8-9
> > development branches going there were about 400-500 services running at
> any
> > time. Resolutions can be very time consuming.
>
> Yeah, my network admin recently re-subnetted our network to cut down
> on the bonjour spammyness. Do you know a better way to handle this?
> Perhaps zeromq should just broadcast out the browse message, and have
> a REP socket that can accept resolution requests?
For our purposes we didn't have any real problems, there was a minor
spike during the initial startup of services but Bonjour and Avahi have auto
rate limiting to keep the network load fairly low. So, if you are getting a
lot of spam, I would suggest looking at how things are being done first.
The way the initial implementation of the integration is done would likely
cause a significant spam hit due to the auto resolution.
> > 2. From what I can see this lacks any type of record query? Just
> > curious as that is one of my primary needs from zero conf.
>
> ... and likewise, a REP socket for record queries? Or should there
> just be one REP socket that handles all of these kinds of functions?
>
> > 3. This is likely to be very touchy to startup order is it not?
> I.e.
> > if the guy that wants to know about a service takes a little longer to
> start
> > than normal it will miss the registration message won't it?
>
> Yeah, that's true, mainly because I don't know a better way to do it :)
>
> > Anyway, good start for something if you just need to know where
> to
> > find things.
I think to be generally useful you are going to need to implement
this as basically nothing more than a 0mq networked service which basically
exports the same interface as zeroconf just via message passing on a req/rep
socket.
KB
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
