#pfctl -d <br>No ALTQ support in kernel<br>ALTQ related functions disabled<br>pfctl: pf not enabled<br><br>#ipfw l<br>65535 allow ip from any to any<br><br>Вроде все чисто.<br><br>Что-то борьба за дисциплину и чистоту логов выходит боком. :)<br>
Можешь подсказать с какими ключами tcpdump дампить заголовки?<br><br>А я все больше склоняюсь к nodelay и 503. Хотя один образцовый сервер не дает покоя - как-то на нем завелось же все как мне хочется. И limit_req работает и в логи всякие обрезки не падают..<br>
<br>Антон.<br><br><br><br><div class="gmail_quote">2009/7/16 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="h5">
</div></div><br>Ушёл, дождался окончания задержки, начал отправлять данные<br>
клиенту, забил tcp'шный буфер на отправку, ушёл дожидаться пока<br>
клиенту из буфера что-нибудь уйдёт. Клиенту так ничего и не<br>
отправилось, соединение было закрыто по таймауту.<br>
<br>
Для полноты картины неплохо бы ещё поймать tcpdump подобной сессии<br>
(достаточно просто заголовков, без содержимого пакетов), и<br>
рассматривать вместе с debug log'ом.<br>
<div class="im"><br>
> Фича? Конфликт двух настроек? Но вылазит только на "Download Master"? Истина<br>
> где-то рядом.... :)<br>
<br>
</div>У вас случайно никаких файрволов сопровождающихся блокировками не<br>
настроено? Очень похоже что где-то по дороге стали просто дропать<br>
пакеты. Я сомневаюсь что вышеописанное поведение свойственно<br>
самому Download Master'у, но вот его неумеренная настойчивость<br>
вполне может вызывать реакцию всяких скриптов следящих за<br>
логами...<br>
<br></blockquote></div>-- <br>Best regards,<br>Anton Kuznetsov. <br>