[zeromq-dev] sha2017?

2017-08-02 Thread Benjamin Henrion
Hi, Anyone going to sha2017? I will be there, so if you are interested, we could have a beer or hack some zmq stuff. Best, ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] topic discovery using broker

2017-08-02 Thread Bill Torpey
Thanks Luca. As mentioned in my reply to Justin, I’m kind of hoping for an “off the shelf” solution that is already integrated with 0mq pub/sub mechanism. And, while zgossip looks like something I could build on, it doesn’t quite solve the whole problem (*I think*). Will definitely look

Re: [zeromq-dev] topic discovery using broker

2017-08-02 Thread Bill Torpey
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

Re: [zeromq-dev] topic discovery using broker

2017-08-02 Thread Justin Azoff
On Wed, Aug 2, 2017 at 9:25 AM, Bill Torpey 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

Re: [zeromq-dev] topic discovery using broker

2017-08-02 Thread Luca Boccassi
On Wed, 2017-08-02 at 09:25 -0400, Bill Torpey 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

[zeromq-dev] topic discovery using broker

2017-08-02 Thread Bill Torpey
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

Re: [zeromq-dev] cleaning up TCP sockets

2017-08-02 Thread Luca Boccassi
On Wed, 2017-08-02 at 14:45 +0500, Parkash Kumar wrote: > Hi Jeol Lauener, > > Based on your comment: > > For us (at CERN) we mostly need this for the case where the client is > so > broken that he is not going to try to reconnect. However its TCP > stack is > still alive and he is keeping the

Re: [zeromq-dev] cleaning up TCP sockets

2017-08-02 Thread Parkash Kumar
Hi Jeol Lauener, Based on your comment: For us (at CERN) we mostly need this for the case where the client is so broken that he is not going to try to reconnect. However its TCP stack is still alive and he is keeping the socket open. In such case we want to have a mean to clean the socket