[zeromq-dev] pub matcher again

[Martin Sustrik]

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.

> 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