Do we need an I/O system between Broflake and its controlling process?

There's an inefficiency created by the decoupling of Broflake from balancer, and at some point we'll have to implement a solution:

Your Broflake client can maintain connections to N upstream peers, but it has no interest or understanding of the data being passed in either direction. Since balancer is the endpoint, it's the process that understands when a given request has failed.

So your Broflake client might have 5 redundant upstream peer connections and is currently attempting to route traffic through Peer 0.

Well, if Peer 0 is an adversary who's trying to DOS the network (or if he's just broken or sucks), balancer has no way to tell Broflake that it's failing -- which, in this circumstance, would let Broflake know that it should eject Peer 0 from its routing table and failover to Peer 1.

Conversely, Broflake has no way to tell balancer when it's dialed a new end-to-end connection with the egress server and that it would like to be nominated in the dialers list again.

This may be solvable with Turbo Tunnel or one of our multipath concepts, depending on what layer in the stack we implement it?

Start by reading the Broflake and balancer components to understand how upstream peers, routing, and end-to-end connections are currently managed. Review the references to Turbo Tunnel and multipath concepts, then define the required process communication, peer ejection, failover, and dialer-list re-nomination behavior before implementation.