When a --dc-ip address's cooldown runs out, a background probe now checks whether the address is
back, instead of the next client.
Why (#148)
A --dc-ip address whose TCP connect times out is skipped for --ip-fail-cooldown seconds (one hour
by default). Until now the cooldown just expired. The next client to arrive dialled the address again
and waited the full --ws-connect-timeout, 10 seconds by default, before the fallback chain got a turn.
On a box whose address stays blocked, this happened once an hour, on the dot. The reporter's four-day
log shows it as a regular spike of client timeouts every ~60 minutes. Telegram's own proxy check gives up
after a few seconds, so each spike could get the proxy switched off with "the proxy server uses incorrect
settings".
Changed
- When an address is cooled, a background probe is scheduled for the end of the window. Clients keep
skipping the address until the probe has an answer. - If the address answers in any way (it connects, refuses, redirects, or stalls the handshake), the
cooldown is cleared. This is the same rule a client connection uses: only a TCP connect that times out
counts as the address being gone. - If the probe times out again, a new window starts, and the next probe runs at the end of it.
- There is one probe per address, however many DCs share it or clients hit it. A client's own successful
direct connect still clears the cooldown, and the probe then stops. --ip-fail-cooldown 0still turns the skipping off entirely, and no probe runs.
What it costs
One background connection attempt per blocked address per window, at most two --ws-connect-timeouts
long. The cooldown entry is held up to that long past the window, so clients can't hit the address
while a probe is still running.
The probe is not a pool connection: it closes as soon as it succeeds, and the pool starts refilling on
the next client connection.