[zeromq-dev] pub matcher again

[Matt Weinstein]

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  
>> checking
>> for readableness
>> xkill would get called which mutated the array.
>> I fixed this by ditching it and following xrep which seems to store  
>> it's
>> 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  
>> store
>> 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  
> causes
> new identity to be generated, new session_t and new pipes will be  
> created.
>
> 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  
>> here
>> 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  
>> measure.
>> The subscriptions are stored on the sub side, though there is a to-do
>> there.
>> 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...
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev