[zeromq-dev] Design advise

[Harsh Doshi]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121228/ca45cfda/attachment.htm>