title: ZeroMQ pattern for load balancing work across workers based on idleness
body: <p>I have a single producer and <em>n</em> workers that I only want to give work to when they're not already processing a unit of work and I'm struggling to find a good zeroMQ pattern.</p>
  
  <p><strong>1) REQ/REP</strong></p>
  
  <p>The producer is the requestor and creates a connection to each worker. It tracks which worker is busy and round-robins to idle workers</p>
  
  <p>Problem:</p>
  
  <ul>
  <li>How to be notified of responses and still able to send new work to idle workers without dedicating a thread in the producer to each worker?</li>
  </ul>
  
  <p><strong>2) PUSH/PULL</strong></p>
  
  <p>Producer pushes into one socket that all workers feed off, and workers push into another socket that the producer listens to.</p>
  
  <p>Problem:</p>
  
  <ul>
  <li>Has no concept of worker idleness, i.e. work gets stuck behind long units of work</li>
  </ul>
  
  <p><strong>3) PUB/SUB</strong></p>
  
  <p>Non-starter, since there is no way to make sure work doesn't get lost</p>
  
  <p><strong>4) Reverse REQ/REP</strong></p>
  
  <p>Each worker is the <code>REQ</code> end and <em>requests</em> work from the producer and then sends another <em>request</em> when it completes the work</p>
  
  <p>Problem:</p>
  
  <ul>
  <li>Producer has to block on a request for work  until there is work (since each <code>recv</code> has to be paired with a <code>send</code> ). This prevents workers to respond with work completion</li>
  <li>Could be fixed with a separate completion channel, but the producer still needs some polling mechanism to detect new work and stay on the same thread.</li>
  </ul>
  
  <p><strong>5) PAIR per worker</strong></p>
  
  <p>Each worker has its own <code>PAIR</code> connection allowing independent sending of work and receipt of results</p>
  
  <p>Problem:</p>
  
  <ul>
  <li>Same problem as <code>REQ</code>/<code>REP</code> with requiring a thread per worker</li>
  </ul>
  
  <p>As much as zeroMQ is non-blocking/async under the hood, I cannot find a pattern that allows my code to be asynchronous as well, rather than blocking in many many dedicated threads or polling spin-loops in fewer. Is this just not a good use case for zeroMQ?</p>