On Wed, Aug 18, 2010 at 2:35 AM, Pieter Hintjens <[email protected]> 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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
