[zeromq-dev] Thinking out loud ...

Artur Brugeman brugeman.artur at gmail.com
Tue Jun 28 05:57:20 CEST 2011

> Naive approach would be to allow for explicit acks so that there could
> be at most one request sent to a specific peer at any single moment.
> That would at least allow load-balancer to distinguish "busy" peers from
> "idle" peers and base the load-balancing on that.
> However, that doesn't seem to play well with intermediate devices. If
> there are multiple workers attached to a particular device, it doesn't
> make sense to send at most one request a time to that device -- that way
> at most one worker would be used at any given moment, which is clearly
> suboptimal.
> Alternative approach would to bubble up number of idle workers
> accessible via a particular peer to the load-balancer.
> Even more sophisticated approach would be to report "available
> resources" metric instead of idle workers count, ie. a big multi-core
> box can report more available resource than an embedded device. Etc.
> The whole thing gets complex pretty fast. There's definitely more
> thinking to be done here.
> Martin

What you are talking about looks preatty similar to system I'm working on:
1. A worker can take jobs from many servers.
2. Server can give jobs to many workers.
3. Workers can do many jobs at once.
4. Allows intermediate devices.
5. With custom load-balancing, based on idleness of workers (basic lb) and
their roles (extension).

It's based on XREP sockets now. I've given quite a lot thinking to it, and
can share my experience.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110628/79af7ff5/attachment.htm>

More information about the zeromq-dev mailing list