Fixed push/pull binding/connection to support round-robin strategy #1

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants

rstuven commented May 29, 2012

See documentation of PUSH/PULL http://api.zeromq.org/2-2:zmq-socket

Owner

quackingduck commented May 30, 2012

Are you sure about this?

From the zmq docs:

ZMQ_PUSH ... The zmq_recv() function is not implemented for this socket type.

And

ZMQ_PULL ... The zmq_send() function is not implemented for this socket type.

I'm pretty sure the receive only socket is the one that should be listening

rstuven commented May 30, 2012

Yes, I'm sure. The docs also say that for one push socket (send only, as
you remarked) bound to an address you can have many pull sockets (receive
only) connected to the same address, so you can route messages in round
robin fashion. If you try to bind more than one pull socket to the same
address, you get an error ("Address is already in use"). See the test case
in my patch.

See also the producer.js/worker.js example in README.md here:
https://github.com/JustinTulloss/zeromq.node
Running many workers using bind on pull socket would not work.
On May 30, 2012 1:10 AM, "Myles Byrne" <
reply@reply.github.com>
wrote:

Are you sure about this?

From the zmq docs:

ZMQ_PUSH ... The zmq_recv() function is not implemented for this socket
type.

And

ZMQ_PULL ... The zmq_send() function is not implemented for this socket
type.

I'm pretty sure the receive only socket is the one that should be listening


Reply to this email directly or view it on GitHub:
#1 (comment)

Owner

quackingduck commented May 30, 2012

Okay, thinking about this a bit more it seems like zmq supports connect/bind
on either end of a pull/push relationship.

(in these diagrams the direction of the arrow represents the direction of the
tcp connections, not the semantics of the zmq connection which is the same in
both cases)

A) One pull socket bound and receiving, N push sockets connected and sending:

push ---
        |----> pull
push ---             

B) N push sockets bound and sending, one pull socket connected to both and
receiving:

push <--
        |---- pull
push <--

I'm pretty sure the pull socket round robins incoming messages in both cases.
So maybe the api needs to accommodate connect and bind for these zmq socket
types. Can I ask what's your specific use case for having the push sockets
doing the binding?

rstuven commented May 30, 2012

"I'm pretty sure the pull socket round robins incoming messages in both cases". No, it doesn't. Incoming strategy for pull sockets is "fair queued". Round-robin is the outcoming strategy for push sockets. My use case is unidirectional round-robin.

However, you are right. The api does need to accommodate to both scenarios, allowing to specify the binding side (therefore, you can ignore my pull request :-) ). This api change would also help to support a similar situation using req/rep sockets. See this and this examples. The latter is an example of bidirectional round-robin.

Owner

quackingduck commented May 31, 2012

You're right, I misused round robin to mean that the pull socket is fair in both cases, the underlying implementations of fairness are entirely different though.

You're also correct that this matters for req/rep as well.

I'll open a new issue for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment