[zeromq-dev] Disconnecting from permanently dead endpoints

[Andrew Hume]

pieter is of course correct in what he says, but to me,
your issue is more about murkiness about the goal.

if the goal is to move data from source to several sinks,
each of which can come and go, then normally the model
is a known publisher and an unspecified set of clients getting that data.
if data should go to exactly one client, then use PUSH-PULL.
if data can or should go to each client, then use PUB-SUB.
in both cases, 0mq handles what you want; you needn't worry about teardown etc.

life gets harder if the publisher needs to know the client's name.

On Jan 25, 2012, at 9:29 AM, Pieter Hintjens wrote:

> On Wed, Jan 25, 2012 at 9:25 AM, Pierre Ynard <linkfanel at yahoo.fr> wrote:
> 
>> I want to set up a messaging system where a zeromq socket connects to
>> several endpoints (with TCP). Some of these endpoints may go permanently
>> down, and the corresponding transport addresses could even be reused
>> by a totally unrelated service. So I need to a way to "disconnect" the
>> zeromq socket from this endpoint, as keeping around zombie endpoints to
>> periodically try to reconnect to them is unnecessary, undesirable and
>> does not scale. The only way I see to do this is to close the socket,
>> create a new one, and reconnect it to all the remaining endpoints, but
>> that's quite suboptimal. Did I overlook something?
> 
> Mainly, it depends on the type of messaging pattern.
> 
> For pub-sub, subscribers can come and go, 0MQ handles this automatically.
> 
> For request-reply, you need to use a load-balancing pattern such as
> least-recently used.
> 
> For other pattterns it gets harder and some people resort to creating
> one socket per connection.
> 
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120125/ed0eb476/attachment.htm>