[zeromq-dev] pub matcher again

[Jon Dyte]

Hi

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..

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?

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.
  
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.

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. ;-)

Thanks

Jon




Martin Sustrik wrote:
> Jon,
>
> Sorry for delay.
>
>> ok found that in both the pub and sub constructors so set them both to
>> true and removed some asserts.
>>
>> so i need to store the outpipe on the sub and the inpipe on the pub.
>
> Right.
>
>> presumably the send and recv methods on the respective sockets are still
>> no-ops right?
>
> Right.
>
>> now I assume that when setsocketopt for a sub is called then it has to
>> push a message down the writer pipe,
>> or is it to send a command and write down the pipe? Will the 'magic'
>> under the hoods route it to the other publisher(s)
>> automagically?
>
> Send it via the pipe. That way the recepient would be able to 
> correlate the pipe it got the subscription through with a pipe in the 
> opposite direction.
>
>> I have also wondered whether the prefix tree needs to remain on the sub
>> end to remove the race that
>> a subscription is changed/added removed and is in flight to the pub
>> whilst messages are sent...
>
> I would say so. The worst case scenario is when the incoming pipe 
> stores large amount of messages. The you unsubscribe. If there was no 
> filter on sub side, you would have to read them all even though you've 
> already unsubscribed.
>
>> In that case if it is still in the sub-side matcher, the app will behave
>> correctly?
>
> Yes. It's duplicate filtering, once on pub side, once on sub side. The 
> application logic won't change.
>
>> sorry for so many questions.... I only just found the zmq_init_t today
>> responsible for that 1 byte message on connect...
>> (and i still think the socket type should go in that....)
>
> It should.
>
> Btw, I'm cc'ing the list so that people have an idea of what's going on.
>
> Martin
>