[zeromq-dev] PUB doesn't discard msg when no SUB
sustrik at 250bpm.com
Fri May 27 08:31:54 CEST 2011
> Isn't the real issue here that connect is asynchronous?
> I've thought often that making connect synchronous (at the API level)
> would solve a lot of 'surprising' aspects, without doing any harm. Of
> course there needs to be the option of doing non-blocking connects,
> since we sometimes want that. But it's a minority use case. This is
> also how the normal TCP socket API works. Synchronous connects unless
> you do extra work to make them non-blocking.
My understanding of the problem is that there are two types of
applications with very different semantics.
There are "core nodes" of the topology which, I believe, are addressed
OK by current design:
1. Core nodes can be connected to more than one peer.
2. Core nodes can both bind and connect.
3. There are no connect/disconnect notifications.
4. All operations are fully async.
On the other hand there are "leg" applications. What's special about
them is they are endpoints on the edge of the topology. They have pretty
1. Leg app can have only one peer.
2. It can't bind. It can only connect.
3. Disconnection is explicitly reported to the user.
4. All operations are fully sync.
There are other requirements that differ, but you get the idea. It's
what you would call server vs. client stack in traditional messaging.
The "leg" implementations were theoretically discussed already very long
time ago and are starting to pop-up now. We already have the "minimal
0MQ stack in bash" and "ZmqSocket.as" Hopefully, we'll have more of them
in the future.
More information about the zeromq-dev