[zeromq-dev] pub matcher again
matt_weinstein at yahoo.com
Mon Aug 23 23:52:02 CEST 2010
On Aug 23, 2010, at 1:18 AM, Martin Sustrik wrote:
> Hi Jon,
>> I've got subs messages going up to the publisher now, I just need to
>> plug in my multimatcher, but before that, a few issues.
>> 1) I had some problems with using the yarray_t to store the incoming
>> pipes on the publisher. namely as i began to iterate the array
>> for readableness
>> xkill would get called which mutated the array.
>> I fixed this by ditching it and following xrep which seems to store
>> own vector with active/inactive in an explicit boolean..
> Yea. yarray works that way it gives you O(1) operations on a vector as
> oposed to std::vector where some operations are O(n).
>> 2) this means for each reader pipe the publisher side will have to
>> an index to be used in the matcher to determine which writer pipes to
>> write too.
>> it is best to map to this index via the identity of the reader? I am
>> thinking the reader instance may change in the case of disconnect? Is
>> the identity preserved?
> The identity is always preserved. If there's a a reconnect which
> new identity to be generated, new session_t and new pipes will be
> However, it's not a good idea to map the pipes using names. Matching
> strings is slow. You should store either pointer of index that would
> allow you to access the pipe in O(1) time.
Wondering - Isn't memcmp unrolled on Linux? You could just define
uuid_t as a fixed array (or vector<unsigned char>) and define
operator==() using memcmp?
(Still two words and a smidgeon but...)
>> 3) should the subscription messages be subject to fair-queue type
>> behaviour? I currently check for subscriptions on every send call
>> on the
>> pub side.
> There's never fair queueing on the sender side. It doesn't even mean
> anything as fair queueing is tightly associated with receiving.
> On the receiving side the fair queueing should be observed, of course.
>> The code is very rough and ready and will probably need a refactor
>> and there once it's working. I havent addressed reconnect as yet.
>> The matching still occurs on the sub side as well as a safety
>> The subscriptions are stored on the sub side, though there is a to-do
>> on recognizing they are not needed.
> They are IMO.
>> oh and if anyone wants to start a template for a 0MQ Internals
>> Guide on
>> wikidot I think it would be a good additional resource
>> , more so if people could spend time fleshing it out. ;-)
> I thought of making little blog entries about the internals of 0MQ...
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev