setTimeout is essentially a periodic function above as long as the perverse conditions remain since each call to balance schedules the next call. So, even if the connection with the RDY count of 1 is lost, it will balance 1.5 seconds later.

In general, I've shied away from using the periodic function for calling balance because I felt I was hiding potential bugs which was the case for a while and in fact right now! I also wanted to de-couple flow control from the distribution of the maxInFlight across connections.

Here's the explanation that is lacking from the source that I will add shortly.

  In normal circumstances, balance ensures that based on the number of connections, the maxInFlight is evenly  distributed across the connections. Once the max RDY per connection has been set, each ConnectionRdy is responsible for maintaining message flow by resetting RDY as messages are finished or re-queued. 

  The non-normal conditions are when there is a low RDY count (maxInFlight < # nsqd connection) and when we're trying a single connection after a back-off event. The two situations are actually identical in that they both need to have a RDY count on a subset of connections with a timeout to prevent deadlock. Since the distribution of the RDY count needs to be coordinated across the connections, balance keeps track of who last had a chance at the RDY count then passes that on to the remainder of the connections.

There is the issue of ConnectionRdy upping the RDY count too aggressively (ie. on each Message `FINISH`). However, I could employ the same technique of upping a connection's RDY count based on a threshold and a timeout. Thoughts?

@mreiferson Do you think there are cases that this will not catch?