Maximum simultaneous transfers limit and server‑side connection pool exhaustion

How FileZilla handles the per‑server maximum simultaneous transfers limit

When the limit is reached, FileZilla places any additional transfer requests in its internal queue and waits for a free socket. It does not immediately retry a transfer after a server‑side connection reset; instead it marks the used socket as unavailable and attempts reuse after a short back‑off period.

Confirmed facts

• FileZilla queues transfers until a slot becomes free; no new socket is created while the limit is active.
• If the remote host closes an idle connection while transfers are queued, the client treats the socket as dead, retries the connection up to the configured retry count, and only then re‑queues the transfer.
• The default back‑off timer before a queued transfer is considered failed is about 30 seconds (configurable in the Transfer Settings dialog).
• Transfers are not automatically retried after a reset; they remain in the queue until the back‑off expires or the user intervenes.

Steps to reproduce the scenario

1. Set the per‑server “Maximum simultaneous transfers” to a low value (e.g., 1).
2. Start several transfers to the same server.
3. Enable “Verbose” logging (Edit → Settings → Debug → Log level: Verbose).
4. Force the server to close idle connections (e.g., by setting a short inactivity timeout).
5. Observe whether queued transfers are retried after the back‑off timer or remain pending.

Please confirm the server’s idle‑connection timeout setting, as it determines whether the client will retry the socket or keep the transfer queued.