[zeromq-dev] Fwd: Exact matching on subscription topics

john skaller skaller at users.sourceforge.net
Thu Jan 19 01:36:37 CET 2012


On 19/01/2012, at 3:57 AM, Chuck Remes wrote:

> 
> This would provide some room to grow if the library were to ever get a more complex matching mechanism like regular expressions.
> 
> #define ZMQ_SUBSCRIBE_REGEX_MATCH <int>

No. The way you do this is with a callback. So it becomes more like:

ZMQ_SUBSCRIBE (user_filter_fun, client_data)

this allows the client to write any kind of matcher they like and 
decouples anything but a trivial matching algorithm from ZMQ.

It's not ZMQ's job to perform complex filtering. 
People write massive applications to do this kind of thing!
Huge huge complex systems! Er .. like Googles search engine .. :)

See below: .....


> Alternative #2
> 
> We deprecate the use of zmq_setsockopt() for setting subscription filters and create a dedicated mechanism for accomplishing this task.
> 
> e.g.
> zmq_setsockfilter(void * socket, int operation, void * operation_value, size_t operation_len);

I think I prefer this. "socket options" sound more like a low level tuning thing,
subscriptions are a very high level abstract thing.

In fact, I would consider the correct interface to be

* construct a subscription manager object

* configure it with filtering details

* create a socket  of type

	ZMQ_SUB (manager)

Now, ZMQ delegates the filtering entirely to an independent object.

In C++, that object would be defined by:

	(a)  abstract class with say a virtual "filter(...)" method
	(b) A couple of derived classes in libzmq supporting a couple of simple options

For the C interface, you provide as standard a fixed wrapper function which calls
filter method on the client data cast to the class. The C user can then either

(a) use that, or any other callback function they want to write
(b) switch to C++, use the fixed wrapper, and derive new classes
    objects of which become the client_data pointer

So in fact .. I'd deprecate even the existing "fixed prefix matching"
and switch to a model where the filtering is delegated entirely outside
of zmqlib.
 
--
john skaller
skaller at users.sourceforge.net







More information about the zeromq-dev mailing list