Трекер указывает клиенту пира интервал обновления (время до следующего обновления) и, соответственно, ждёт его анонса по прошествии этого времени. Он (трекер) также может устанавливать минимальный интервал времени, до истечения которого нормальный клиент не должен посылать анонс, а трекер не обязан принимать пришедший анонс (кроме сообщения об остановке торрента).
Если в ожидаемое время трекер анонс не получил, он ждёт какое-то время, а потом - "хорошо, тогда я Вас вычёркиваю" (с).
Ещё раз хотел бы отметить, что конкретности могут быть свои на каждом конкретном трекере. Например, один трекер может принимать пришедший "не вовремя" анонс, другой - игнорировать; интервал обновления может быть фиксированным, а может изменяться в зависимости от загруженности трекера; время ожидания не пришедшего "вовремя" анонса тоже может быть разным, так что ссылаться здесь (или на любом другом трекере) на соответствующую цитату с рутрекера, мягко говоря, вряд ли имеет смысл, как и строить на ней дальнейшие рассуждения.
1. Под тайм-аутом обычно понимают не запланированный интервал времени
до начала какого-то события/действия (по Вашей версии - до очередного анонса), а запланированный интервал времени ожидания последствий или событий
после выполнения какого-то действия (или после конкретного момента времени) на случай, если эти последствия/события не случатся (или само событие окончания ожидания, когда сработал таймер, а ожидаемые события ещё не произошли, и пора принимать меры или просто идти дальше). Так что "отсчёт времени до 0, начиная с 1 часа" здесь ни при чём. Мы (клиент) отправляем данные (когда досчитали от 1 часа до 0), запускаем таймер и ждём ответа. Если раньше пришёл ответ - анализируем его и действуем по плану (А или Б, в зависимости от ответа). Если раньше сработал таймер - действуем по плану, который, по сути, тот же план Б.
2. Я описывал план Б, который выполняется, если от трекера пришёл неудовлетворительный ответ или сработал таймер, а ответ от трекера не получен. Пауза - это пауза. Клиент "считает до десяти, чтобы успокоиться" (только обратным отсчётом, аналогично отсчёту от 1 часа до 0) и делает новую попытку передать данные. Если опять неудачно, то в следующий раз клиент будет считать "до 20", потом "до 50" и т.д., пока не дойдёт до макс. значения (какого именно и зависит ли от трекера - не помню, у меня сейчас на единственной "красной" раздаче на другом трекере это 42 мин. 40 сек.), после чего будет повторять отсчёт с максимального значения, и повторять может до бесконечности.
3. Ну, мы то и дело сталкиваемся с проблемами недостаточно чёткой терминологии. Так, анонсом называют и весь сеанс общения клиента с трекером, и его часть со стороны клиента (причём и сам отправляемый блок данных, и процесс отправки). Иногда я (по привычке или для большей ясности) называю что-то неправильно или не так, как принято. Но "нормальная длительность анонса (1 час)" - для меня совсем непонятно. 1 час - это не длительность анонса, это интервал между анонсами (на этом трекере, в случае, если всё нормально). И я не понимаю, что такое "обновление анонса".
И, как мне кажется, "медленный подхват анонсера" у
вагонного вряд ли имеет отношение к длительному пребыванию торрентов в состоянии "обновление...".
P.S. Пока приходит в голову только отличие между ожиданием установления связи с трекером и ожиданием ответа от трекера после передачи данных.