[zeromq-dev] Design advise

[Nishant Mittal]

Yes, and that is what I have implemented.. however, I am pointed out a
different scenario


On Fri, Dec 28, 2012 at 3:55 PM, Harsh Doshi <hardos at gmail.com> wrote:

> The guide has an example for doing load balancing using a router-dealer
> sockets
>
> Harsh
>
> Sent from IPhone
> Pardon the typos
>
> On Dec 28, 2012, at 11:25 AM, Nishant Mittal <nmittal at rblt.com> wrote:
>
> Router does fair-queuing but i think whats happening is that all msgs from
> the 1st client are received and stored in the router's internal queue thats
> why the 2nd client has to wait.
>
> and for that reason, "i think", your idea wouldnt work as well as the
> messages are already in router's internal queue.
>
> thanks
>
>
> On Fri, Dec 28, 2012 at 2:21 PM, Claudio Carbone <erupter at libero.it>wrote:
>
>> My stupid idea is a "man-in-the-middle":
>> Put a loop in your queue doing a round-robin on the request pool.
>> Like forwarding 5 reqs for each client each turn: if a client sends a lot
>> of requests, it just has to wait until the next loop.
>>
>> By the way shouldn't the router already be doing some loadbalancing ?
>> I'm really not a super zmq expert.
>>
>> Claudio
>> -- Sent from my ParanoidAndroid Galaxy Nexus with K-9 Mail.
>>
>> Nishant Mittal <nmittal at rblt.com> wrote:
>>>
>>>  In my use case,
>>> - I have a queue (a proxy with ROUTER in the front and DEALER in the
>>> back).
>>> - Client has a DEALER socket that connects to the ROUTER in the proxy
>>> above. not using as I want the client to be able to send multiple jobs
>>> without waiting for a response
>>> - Worker has a REP socket that connects to the DEALER in the proxy above
>>> - this is working great, however, a design goal is to not let 1 client
>>> block other clients from sending and receiving responses which is what is
>>> happening at the moment. If the first client sends a lot of requests BEFORE
>>> the second client started sending its requests then first all the requests
>>> of the first client are served and then the second.
>>>
>>> How can I improve this design so if 1st client sent 10000 requests and
>>> then 2nd came along and sent 1 request, it doesn't have to wait for the
>>> 10000 requests to finish?
>>>
>>> I guess one solution would be to lower the high watermark so the 1st
>>> client would be blocked from sending more but feel that would hurt
>>> performance/scalability.
>>>
>>> thanks
>>> Nishant
>>>
>>> ------------------------------
>>>
>>> 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
>>
>>
>
>
> --
> *Nishant Mittal*
> Director, Product Development
> *Rosenblatt Securities Inc*.
> 20 Broad Street
> New York, NY 10005
>
> Direct: 212-607-3159
> Mobile: 646-504-2629
>
> _______________________________________________
> 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
>
>


-- 
*Nishant Mittal*
Director, Product Development
*Rosenblatt Securities Inc*.
20 Broad Street
New York, NY 10005

Direct: 212-607-3159
Mobile: 646-504-2629
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121228/4d255f1b/attachment.htm>