i've only done a couple of these, but the filtering/routing/guiding function
seems very problem-specific.

in my case, i use PUSH-PULL underneath. the app code sends everything
via a guide function which is more or less data-type specific; it takes
a data blob to be sent and a guiding value and a guide type.

the types i use are
        modulo  (at each layer of the guiding, i hash the value and
                send it to the i'th entity at that level, where i = hash MOD 
n-entities)
        segment (at each level, i search for the value in a table and send it 
to the
                corresponding entry)

currently i use modulo for values that are IMSI's (== 64 bit int), and segment 
to do geographic
routing for values that correspond to radio-identifiers.

i only do two levels right now: level 1 gets you to a server, level 2 gets you 
to a process.
but the scheme extends trivially to more levels, such as cluster or thread.

and teh hash isn't a normal hash because i only need to get a reproducible
uniform distribution out of it. so i simply break the value into bytes,
index some tables of (truly) random numbers and xor them together.

        andrew

On Jan 19, 2012, at 10:46 AM, Staffan Gimåker wrote:

> On Thu, 2012-01-19 at 09:55 -0700, Andrew Hume wrote:
>> it is really a level or two of complexity
>> more than you would (or should) expect the library to do.
>> 
>> 
>> to my mind, we should do this sort of subscription stuff at user level
>> and use the zmq stuff to do routing. but what do i know?
> 
> I don't disagree. I'm not asking for zmq to solve all our special needs.
> However, functionality that enables you to implement stuff that's
> outside of the typical use case would be nice. If the user could be put
> in charge of filtering altogether that'd be great (but probably tricky).
> Another way to go forward for us is having exact matching semantics,
> which I also think would be useful for other people as well.
> 
> (I don't care much for regexp filtering and all that jazz, though.)
> 
> /S
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
[email protected]  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to