[zeromq-dev] pub matcher again

[Jon Dyte]

Martin Sustrik wrote:
>
>
> 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.
>   
so I can store the pointer to the writer against the reader vector. the 
reader vector is essentially a tuple of (reader*,writer*, active_flag).
the index of the item into the vector is what is passed to the multi 
matcher to set up the subscription.
>> 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.
>
I will fix this then. it's fair queueing but still has to check every 
readable read pipe on every send call.
just start at next index each time til it cycles.

>> 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.
>
what i meant is I currently store every subscribe/unsubscribe operation. 
If a subscription is cancelled (ie refcount dropped to zero)
then i need to remove the subscription request operation. At the moment 
I simply store every sub/unsub regardless.

this mail seemed to have dropped off the list again so I'm adding it 
back in,
cheers

jon