#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">&lt;<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>&gt;</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&#39;шный буфер на отправку, ушёл дожидаться пока<br>
клиенту из буфера что-нибудь уйдёт.  Клиенту так ничего и не<br>
отправилось, соединение было закрыто по таймауту.<br>
<br>
Для полноты картины неплохо бы ещё поймать tcpdump подобной сессии<br>
(достаточно просто заголовков, без содержимого пакетов), и<br>
рассматривать вместе с debug log&#39;ом.<br>
<div class="im"><br>
&gt; Фича? Конфликт двух настроек? Но вылазит только на &quot;Download Master&quot;? Истина<br>
&gt; где-то рядом.... :)<br>
<br>
</div>У вас случайно никаких файрволов сопровождающихся блокировками не<br>
настроено?  Очень похоже что где-то по дороге стали просто дропать<br>
пакеты.  Я сомневаюсь что вышеописанное поведение свойственно<br>
самому Download Master&#39;у, но вот его неумеренная настойчивость<br>
вполне может вызывать реакцию всяких скриптов следящих за<br>
логами...<br>
<br></blockquote></div>-- <br>Best regards,<br>Anton Kuznetsov.       <br>