[zeromq-dev] Limitations of patterns?

[Kelly Brock]

Hi Martin,

> > 	I forgot about the multicast case in this.  Hmm, seems like maybe a
> > generic wrapper for 'only' tcp/inproc/ipc types would be in order to
> handle
> 
> An option to sequence number would be for publisher to post a tag
> message into the PUB/SUB feed that would correlate with a tag attached
> to the snapshot.

	Yeah, I came up with that just a bit after writing the e-mail,
thanks for not calling me an idiot though. :)  The usage patterns take a bit
of getting used to.  But it does bring up a question about the guarantee's
made by zmq, assume the following:

Server side:
Bind req/rep socket to port 1234
Bind pub/sub socket to port 1234

Client side:
Connect to pub/sub to port 1234
Subscribe some stuff...
Connect to req/rep to port 1234

	I "believe" this is valid, the docs are a bit non-clear on this.
Are there any guarantees that when I send the "initme" message on the req
that I'm fully connected to the pub/sub and won't miss anything?  (I.e. both
tcp on the same port, I assume sockets are shared by default?)  If not, I
can just use a poll timeout and repost the "announce" message till I get the
reply correctly.

	As with the "feng shui" thread, Zmq is different.  Personally I just
say my Kung Fu is weak, I'm getting better though. :)  Very different than
traditional sockets.
 
> >> Yes. The problem here is that there's no way to control number of
> >> requests on the fly. The existing pushback mechanism is based on TCP
> >> pushback, so it allows you to write messages until TCP buffers are full
> >
> > 	I'm definitely going to want to look at this in the next couple
> > weeks.  Currently at work I'm using Zmq to organize an asset dependency
> 
> You don't want to go that way unless you are IBM. Been there, seen it.
> It's a way that leads to transacted messages, later on distributed
> transactions, then redundant distributed message store clusters etc.

	Ok, I'm all ears as to what you suggest then.  In thinking about
things and trying to make it zmq "feng shui". :) I think this is what I
would suggest:

Push (Downstream) thread:
Make the push/downstream socket with a "non blocking" flag.
Send messages as normal.  This blocks until some client connects "AND" says
it is willing to accept work.

Pull (Upstream) client:
Make the pull socket as normal.
Call "zmq_msg_accept( int x )" with the number of worker slots it will
accept at this time.
As things complete "zmq_pull_accept" the number of further work items you
want to accept.

	This keeps the behavior of both sides consistent with most other zmq
concepts, I believe.  The "accept" would simply say I'm both connected "and"
willing to receive x number of messages before push should stop sending to
me.  This seems like the least intrusive and most appropriate solution from
my current understanding of things.  The int number of acceptable messages
is simply to fit this into a zmq styled way to connect up single threaded
workers on a separate machine with inproc worker threads.  I.e. main thread
connects, makes x number of workers each with an inproc pull connection,
accepts x work items to feed to it's x number of inproc workers, likely one
per CPU core and as workers finish, issues more "accept"'s.

	If this is still not proper for zmq please explain why, currently it
is as close as I can come up with as to the proper usage patterns of zmq at
this time. :)

KB