Thanks Justin. I was kind of hoping that someone would come back with “Of course, 0mq can already do that — just do such and such” — in other words, a mechanism that is already built-in to 0mq and working “in the wild”.
Your project looks more like a tool I could use to build topic discovery myself, and I will certainly check it out if I get to that point. For now, I’m holding out hope for an “off the shelf” solution. Regards, Bill > On Aug 2, 2017, at 12:06 PM, Justin Azoff <[email protected]> wrote: > > On Wed, Aug 2, 2017 at 9:25 AM, Bill Torpey <[email protected]> wrote: >> The problem of topic discovery keeps coming up, and one of the first >> approaches recommended is to use a broker. That makes sense from the point >> of view of simplicity, but it has several disadvantages in the areas of >> scalability and availabilty. >> >> An obvious (?) solution would be to use a “topic broker" to connect >> publishers and subscribers, but to have the actual messages flow directly >> from publisher to subscriber. There are several commercial solutions that >> use this approach (e.g., Wombat, LBM) and it seems to work reasonably well. >> >> I’m new to ZeroMQ and am curious if anyone in the community has taken this >> approach? Is there a simple way of “wiring up” ZeroMQ to make this work? >> Or would this require some custom development on top of core ZeroMQ >> functionality? >> >> To be clear, I’m not interested in solutions that are built on top of >> multicast — for a number of reasons that is simply not a practical approach >> in my environment. And while there are projects associated with ZeroMQ that >> seem to address topic discovery (i.e., Zyre, zbeacon), as far as I can tell >> they all (a) depend on multicast, and (b) deliver subscribe/unsubscribe >> requests over the same stream as actual data messages. >> >> I have a general idea how to build this, but it’s a fair bit of work, esp. >> when edge cases are taken into account. Plus, I don’t want to look like an >> idiot when someone says “Why didn’t you just …?”. >> >> Any tips, hints or suggestions would be much appreciated! Thanks! >> > > You may be interested in a project I've been working on for simple > service discovery: > > https://github.com/JustinAzoff/simpledisco > > I wrote it as an alternative to gossip to use with zyre for > discovering peers over the internet. The api is simple, just like > with gossip you do a > > zsimpledisco_publish(disco, key, value); > > Once a minute(currently hardcoded) the actor will request every active > key and value. There's no 'un publish' api on the server side, keys > just timeout after a minute if no one is publishing them anymore. > Though I suppose the client side could use a DELETE command... my zyre > use case didn't need that so I haven't added it. > > Redundancy is implemented by having clients connect to multiple > servers and merge the responses. The servers do not connect to each > other and are completely self contained. > > The design is extremely simple because there is almost no state that > can get out of sync. Network timeouts and server failures are a non > issue, the client will just ignore the down server and try to > reconnect. I think it's an expanded case of the "Lazy Pirate pattern" > from the guide. > > -- > - Justin > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
