столкнулся с неожиданной проблемой.
есть клиент и сервер, взаимодействующие по http.
(indy 9018)
на сервере tidtcpserver на клиенте tidhttp (или если нет прокси то tidtcpclient).
Обмен идет post запросами и все как бы хорошо.
Кроме двух случаев в одном городе.
У клиентов диалап к провайдеру через обычный модем.
Линия аналоговая, набор пульсом.
Обмен данными идет неустойчиво.
Детальная трассировка показала:
клиент послав пост запрос серверу вошел в цикл readln для чтения заголовка ответа.
считал две первые строки заголовка и замер в ожидании третьей в которой указан content-length.
Эту строку у него получается считать через раз на третий.

Сервер тоже был оттрассирован.
И на нем все выглядит замечательно.
Сначала цикл readln и получение заголовка клиента, затем считывание блока данных пост запроса, затем обработка запроса (декрипто/проверка эцп/запросы к субд/формирование ответа/эцп/шифрование и посылка самого ответа клиенту)
На все про все уходит одна-две секунды.
Тем не менее клиент не выходит из readln.

Глюк стабильный, но проявляется только в одном городе и только на диалапе.

Подскажите плиз, куда рыть и где закапывать собаку.

Обновить систему ? Настройить брандмауэр ?

> Тем не менее клиент не выходит из readln

тут только одно приходит в голову: readln не может найти конец строки

это понятно что клиент не может найти CRLF.
непонятно почему crlf пропадает только на диалапе и только в одном населенном пункте.

брандмауэра там незамечено. тем более такого интеллектуального, который две строки шттп заголовка пропускает, а третью нет.

а от значения content-length не было замечено зависимости?

проверялось на одной и той же операции, а там в результате запроса примерно одинаковый контент генерится.
прикол вот еще в чем.
на той же машине стоит другой клиент работающий с другим сервером (моя же разработка, но в прошлом и у другого работодателя).
там тоже тсп/ип но протокол собственный, двоичный.
все отличие только в том, что заголовок представляет собой блок фиксированной длины, который считывается через readbuff.
а дальше, если есть дополнительный блок данных, то его длина извлекается из заголовка и делается еще один readbuff.
так вот. этот "старый" клиент работает как швейцарский ролекс. В тех же условиях на том же модеме с тем же провайдером.

все отличие в том, что там нет readln.

в общем пока добился улучшения таким путем:
сервер, сформировав ответ, не делает writeln writeln writeln writebuff,
а формирует в памяти весь блок ответа целиком (заголовок + данные) после чего делает единственный writebuff клиенту.

но все равно хотелось бы понять "химию и физику" проблемы.

> Поросенок Винни-Пух ©   (07.11.08 15:33) [6]


Попробуй выключить на своем IdTCPServer'е алгоритм Нагеля

> Поросенок Винни-Пух  (07.11.2008 14:48:03)  [3]

В этом одном населенном пункте надо озаботиться об смене модема, на другую фирму.

> Сергей М.  (07.11.2008 16:27:07)  [7]

То же дело.

Нагель - это из этой оперы?

procedure TIdTCPConnection.WriteBuffer(const ABuffer; AByteCount: Integer;
 const AWriteNow: boolean = false);

> Поросенок Винни-Пух ©   (07.11.08 17:08) [10]


Не-а ..

Нагель - это Get/SetSockOpt(..TCP_NODELAY..)