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

[Pieter Hintjens]

Alexey,

OK, so we can solve this using the principle of least surprise.

We have a large class of simple pubsub scenarios where the best
metaphor is (arguably) "start broad, narrow it down".

We have a smaller subset of sophisticated pubsub scenarios where the
best metaphor is "start with nothing, then add/remove subscriptions".

One way to solve this is with two socket types, each offering a
specific metaphor, through naming and default behaviour.  But that
adds complexity.

A simpler solution is to offer a setsockopt that asks for the more
sophisticated behaviour.  Then what we get is that for common, simple
cases SUB works as people expect and for rarer MD cases, SUB can be
configured to work as people need.

That seems to be least surprising.

-Pieter



On Wed, Aug 18, 2010 at 1:00 AM, Alexey Ermakov <zee at technocore.ru> wrote:
> 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.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
-
Pieter Hintjens
iMatix - www.imatix.com