[zeromq-dev] Limitations of patterns?

[Kelly Brock]

Howdy,

> > Server side:
> > Bind req/rep socket to port 1234
> > Bind pub/sub socket to port 1234
> 
> You cannot bind two sockets to the same port.

	Don't know where I got the idea you could in this case.  It surely
didn't work in my quick little test, last night.  :/  Oh well, I'll do it
the other way.

> > 	Ok, I'm all ears as to what you suggest then.
<snip>
> That's basically the user-level ack. The problem with it is that once
> you introduce that kind of API, people will immediately start to use it
> to implement reliability -- while your intention was only to provide
> flow control. Reliability is hard (actually it's impossible to solve) so
> people would end up just being confused and unhappy about the whole
> product.
> 
> What should be done IMO is to implement acks inside 0MQ so that they are
> invisible to user. The user would set the max number of message on-fly
> using HWM socket option and that's it.

	Ok, so hmm.  Would the following make sense then:

// Server works as normal except the PUSH side has:
zmq_setsockopt( s, ZMQ_PUSH_ACK, NULL, 0 );


// Clients add:
zmq_setsockopt( s, ZMQ_PULL_ACK, NULL, 0 );

	The "zmq_recv" will check the option and send an ack to tell the the
push side to send me a message.  This does not allow me to say I'll receive
more than one message since that would still require some sort of manual ack
but it solves the single worker case without any new user size calls.

	Thoughts?

KB