[zeromq-dev] pub matcher again
jon at totient.co.uk
Mon Aug 23 12:07:21 CEST 2010
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
>> 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
More information about the zeromq-dev