особенности tcp/ip при PPP соединении

← →
Поросенок Винни-Пух © (2008-11-07 13:52) [0]

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

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

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

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

← →
tesseract © (2008-11-07 14:45) [1]

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

← →
clickmaker © (2008-11-07 14:46) [2]

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

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

← →
Поросенок Винни-Пух © (2008-11-07 14:48) [3]

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

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

← →
clickmaker © (2008-11-07 15:04) [4]

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

← →
Поросенок Винни-Пух © (2008-11-07 15:19) [5]

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

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

← →
Поросенок Винни-Пух © (2008-11-07 15:33) [6]

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

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

← →
Сергей М. © (2008-11-07 16:27) [7]

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

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

← →
Anatoly Podgoretsky © (2008-11-07 16:50) [8]

> Поросенок Винни-Пух (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);

особенности tcp/ip при PPP соединении Найти похожие ветки