[zeromq-dev] High water mark notification for publisher
Edwin Amsler
edwinamsler at thinkboxsoftware.com
Sun Sep 23 20:48:52 CEST 2012
Thanks for the ideas Paul.
My out of band work is just to let late joiners and those clients whose
disks couldn't write fast enough (they abandon messages destined for
disk and mark that down). They notify the server of what parts they
missed, and the server broadcasts again. It's a bit like the Clones
example in the guide, but the recovery is handled in large batches and
broadcast out instead of going over a router socket.
So, because of that, I'm less interested in clients not keeping up. If a
client can't write to disk fast enough, I'm happy to retransmit for them
once the initial stream is over (this avoids choking the super speedy
ones). The primary problem here is the interplay between my disks (which
are unusually fast when cached) and the outgoing network card.
The problem I'm hitting now is that if all clients were infinitely fast,
I'd still have issues with the network card on the server not being able
to satisfy the data I'm creating.
On 23/09/2012 7:08 AM, Paul Colomiets wrote:
> Hi Edwin,
>
> On Sun, Sep 23, 2012 at 6:23 AM, Edwin Amsler
> <edwinamsler at thinkboxsoftware.com> wrote:
>> I have a mechanism out of band over TCP that re-requests pieces once the
>> transfer is done, but I'm never actually sure when it's done sending so I
>> just wait 1 minute before re-requesting.
>>
>> If I had some indicator of whether or not the message goes missing, I could
>> re-transmit or throttle back the 500MB/s to what the network is actually
>> able to provide.
>>
> I think you can also have an out of band pub-sub over TCP to send acks
> from clients to server. You need some way to count acks (e.g. clients
> may send presence notification before start of a transfer). But it may
> give you a way to limit bandwidth in more automatic way.
>
> You may also look at ZMQ_RATE and ZMQ_RECOVER_IVL options, they should
> (theoretically) give you reliability without out of band socket to
> request data, however I don't know how well that works in practice.
>
More information about the zeromq-dev
mailing list