As a user of slapd-ldap I've bumped into few corner cases related to handling
retries and timeouts . I think it demonstrates how non-trivial
problem proxying really is, even if it might seem quite simple for casual user
at first. While working with a patch for  I was wondering following:
My use case:
I have many proxies in the network: one per Kubernetes cluster, but large
number of clusters in the network. I'd like to reduce the number of long-
running connections to centralized server to the absolute minimum. The number
of concurrent TCP connections handled by the remote LDAP server is the
bottleneck. Optimally, all connections should be dropped as soon as client
is done with the LDAP query.
Would it be possible to disable all (or only some) caching and retry logic and
instead have the proxy mirror the behavior of the clients and remote server:
(1) Disconnect the client connection when corresponding remote connection got
(2) Disconnect the connection to the remote server when the client disconnects
from the proxy (or if remote connection is shared between many clients:
disconnect when last client disconnects)
In other words, delegate the complications back to the remote server and
clients, instead of trying to solve them at the proxy.
Could this simplify the proxy?
What would be the performance implications? In my use case the concurrent TCP
connections towards remote server would reduce, but the number of individual
connections could increase due to (2).
 Idle and connection timeout implementation
 crash if rebinding after retry fails
 retry fails after remote server disconnected
 rebind-as-user credentials lost after retrying remote connection