4.2.3. Частные вопросы
4.2.3.1. Sorcerer's Apprentice Syndrome
В спецификации протокола содержится серьезна ошибка — Sorcerer-синдром (Sorcerer's Apprentice Syndrome), которая хоть и не приводит к некорректной передаче (файл всегда передается корректно, если передача завершена), но может привести к избыточным повторам и тайм-аутам.
Во всех реализациях эта ошибка должна быть исправлена — отправитель (т. е., сторона, передающая пакеты данных) никогда не должен заново передавать текущий пакет данных (DATA) при получении дубликата подтверждения (ACK).
- Обсуждение
Ошибка связана с правилом, по которому люба сторона, получив старый дубликат, может заново передать текущую дейтаграмму. Если пакет задержан в сети, но успешно доставлен после того, как истекло время ожидания и другая сторона повторила передачу, может быть сгенерирован дубликат отклика. Если в ответ на такой дубликат передача будет повторена еще раз, передача всех остальных дейтаграмм будет дублироваться (если не будет утери дейтаграммы, которая прервет повтор). В дополнение к этому, поскольку задержка зачастую связана с насыщением сети, передача дубликатов обычно усиливает насыщение, что ведет к новым задержкам и т. д.
Для понимания проблемы может быть полезна приведенная ниже иллюстрация.
TFTP A TFTP B (1) Receive ACK X-1 Send DATA X (2) Receive DATA X Send ACK X (ACK X is delayed in network, and A times out): (3) Retransmit DATA X (4) Receive DATA X again Send ACK X again (5) Receive (delayed) ACK X Send DATA X+1 (6) Receive DATA X+1 Send ACK X+1 (7) Receive ACK X again Send DATA X+1 again (8) Receive DATA X+1 again Send ACK X+1 again (9) Receive ACK X+1 Send DATA X+2 (10) Receive DATA X+2 Send ACK X+3 (11) Receive ACK X+1 again Send DATA X+2 again (12) Receive DATA X+2 again Send ACK X+3 againОтметим, что после доставки задержанного подтверждения ACK протокол начинает дублировать все последующие пакеты (пп. 5-8 и 9-12). Проблема вызывается не тайм-аутом на любой из сторон, а повторной передачей обеими сторонами при получении дубликатов.
Для решения проблемы нужно разорвать возникшую петлю, как показано выше. Это аналогично поведению TCP. Можно удалить таймер повторной передачи на приемной стороне, поскольку повторная передача подтверждения ACK не будет вызывать каких-либо действий; это упрощение TFTP особенно полезно при использовании протокола для стартовой загрузки. Сохранение таймера возможно и может оказаться полезным, если повторно переданное подтверждение ACK заменяет потерянное в сети. Для отправителя таймер повторной передачи остается необходимым.