[zeromq-dev] PUB doesn't discard msg when no SUB

[Martin Sustrik]

Hi Pieter,

> 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 
different requirements:

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.

Martin