On Wed, Aug 2, 2017 at 9:25 AM, Bill Torpey <wallstp...@gmail.com> 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 zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
