[zeromq-dev] [PATCH] ZMQ_PEER_EXISTS option

Artur Brugeman brugeman.artur at gmail.com
Thu Jun 9 07:30:58 CEST 2011

Hi, Pieter.

>> Yes, thats right, If you've got a better idea how to solve my problem, I'll
>> be happy to try it.

> A few things come to mind. As Lucas says, this seems close to the
> Freelance pattern so I'd definitely try to use that. There are are
> number of aspects that could be helpful:
> * knowing the peer's identity without hard-coding it.
> * using ping-pong heartbeats to know when a peer is online.
> * splitting peers into clients and servers.

Splitting peers into clients and servers would help if I didn't want
to make it p2p :)

> Even if you want every node to be both a client and a server,
> splitting the flow would be better IMO than trying to both connect and
> bind on the same socket.

Please explain, why? If by "splitting the flow" you meant "have a
bound socket and a connected socket", than well, I've started with two
sockets at each peer. I polled both sockets and read from the one that
was ready. When I made the patch and removed one of sockets, the code
didn't actually change, just got a bit simpler. So to me it is - why
should I have two TCP connections instead of one, if having one is not
only more "economical", but also makes code simpler?

> You should not need to patch 0MQ to make this work.

I've made things work w/o patching. It just came to my mind that
issues I've been working around at application level are much easier
eliminated by a simple patch. I admit the patch is not as elegant as
one wishes. At least, I'm trying to point out that there are some
things lacking for certain scenarios, which are probably worth
considering for zmq 3.0 ...

> -Pieter

Brugeman Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110609/ac04e0a7/attachment.htm>

More information about the zeromq-dev mailing list