[zeromq-dev] Newbie Bait Request: Debug "Warning" mechanism.

[Alexey Ermakov]

On Wed, Aug 18, 2010 at 2:35 AM, Pieter Hintjens <ph at imatix.com> wrote:
> Anyhow, this is in no way a formal proposal, it's just an idea for
> discussion since people seem always to trip up on this aspect of SUB
> sockets.
>
> There's no question of breaking existing code, throwing any babies out
> with the water, etc. except in a major version and after really
> careful thought.

I'm sorry if my previous message looked like an overreaction. I
understand that this is not a final spec and was just trying to add my
two cents.

> For market data use cases nothing would change except some API terminology.
> In fact the proposition only changes one use case (no subscriptions).
> What it does is turn the language around to fit common experience. People used to market data and messaging frameworks will have no trouble either way, they have been experts at this for years.

What I've been trying to argue in my previous messages is that even
changing one use case (poll()/recv() on a ZMQ_SUB socket with no
subscriptions) from its current behavior to “receive everything” would
make these sockets impossible to use for stuff like market data.
Consider this rather typical use case: I create a socket for getting
market data and an inproc API socket for handling subscriptions.
With the current behavior, this socket works nicely: if I call poll()
on the two sockets, I'll only get subscription commands at first. Once
I set up some subscriptions, I'll start receiving data. If I remove
all my subscriptions, I'll once again stop receiving any sort of
market data. If publisher-based prefix matching gets done, it all
transparently becomes very efficient network-wise.
If you change the default to “receive from all”, suddenly everything
becomes very ugly. Yes, developers that blindly call recv() on a
freshly made SUB socket will get their data, but the use case I
described above becomes impossible to implement without all sorts of
dirty hacks (delay SUB socket connection/binding until the first
subscription, close and recreate the socket instead of calling the
last unsubscribe, as there's currently no disconnect/unbind call).

Also, this proposed API change doesn't look very logical to me
semantically. The socket's called ZMQ_SUB for a reason — it deals with
subscriptions. Returning no data if I haven't subscribed to anything
seems perfectly fine, they're called “subscriptions” for a reason.
Yes, there's a potential case where it locks a thread forever, but
that shouldn't be solved by transparently subscribing to everything.
Perhaps it would be better to make recv() return EAGAIN after a
predefined timeout (to prevent high CPU usage)?

I liked the filtering idea (especially the negative filters), but they
don't make sense as a primary means of “configuring” a
_subscription_-based socket. As an additional filter they would be
very nice to have, but as the only “recommended” (as in not
deprecated) configuration option they only make sense for a PULL
socket.