[zeromq-dev] Welcome to the "zeromq-dev" mailing list

Michel Pelletier pelletier.michel at gmail.com
Fri May 30 21:29:51 CEST 2014


On Fri, May 30, 2014 at 7:21 AM, Jeremy Richemont <jrichemont at gmail.com>
wrote:

>
> If I could just query PUB and get a list of clients plus a notification
> when one drops that'd solve the problem I think. But how to do that?
>
>
"when one drops" is a difficult concept to define.  The only way to know
that your message got to the recipient is to receive an acknowledgment.
 This is not a problem 0mq solves for you out of the box because there are
so many variations many of which are documented in the guide as patterns.

I agree with Charles, I think you want the clone pattern.  The "state" can
contain the history you want to preserve.  Or have your clients remember
their last update and at clone point you can have it pass a timestamp, and
have the first clone be a "big delta" from that point forward in your
history "state".

-Michel


> Jeremy
>
>
> On 30 May 2014 15:00, Charles Remes <lists at chuckremes.com> wrote:
>
>> Take a look at the Clone pattern in the zguide.
>>
>> http://zguide.zeromq.org/page:all#Reliable-Pub-Sub-Clone-Pattern
>>
>> This might be what you need.
>>
>> cr
>>
>> On May 29, 2014, at 11:20 AM, Jeremy Richemont <jrichemont at gmail.com>
>> wrote:
>>
>> >
>> > Hi. I am struggling to work out how to use zmq to implement the
>> architecture I need. I have a classic publish/subscribe situation except
>> that once client x has subscribed to a topic I need the topic data to be
>> sent to it to be cached if the client dies and resent on reconnect. The
>> data order is important and I can't miss messages should the client be
>> offline for a while.
>> >
>> > The PUB/SUB pattern doesn't seem to know about individual clients and
>> will just stop sending to client x if it dies. Plus I can't find out this
>> has happened and cache the messages, or know when it reconnects.
>> >
>> > To try to get around this I used the REQ/REP pattern so the clients can
>> announce themselves and have some persistence but this is not ideal for a
>> couple of reasons:
>> >
>> > 1) The clients must constantly ask "got any data for me?" which offends
>> my sensibilities
>> >
>> > 2) What happens if there's no data to send to client x but there is to
>> client y? Without zmq I'd have had a thread per client and simply block the
>> one with no data but I can't block client x without also blocking client y
>> in a single thread.
>> >
>> > Am I trying to shove a round peg in a square hole, here? Is there some
>> way I can get feedback from PUB saying 'failed to send to client x'? so I
>> can cache the messages instead? Or is there some other pattern I should be
>> using?
>> >
>> > Otherwise it's back to low level tcp for me...
>> >
>> > Many thanks;
>> >
>> > Jeremy
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140530/1af1d7e9/attachment.htm>


More information about the zeromq-dev mailing list