Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

особенности tcp/ip при PPP соединении [D7, WinXP]

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

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

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

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

Сергей М. (2008-11-07 19:27:00) [1]

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

Не-а ..

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

Поросенок Винни-Пух (2008-11-07 17:08:00) [2]
Нагель - это из этой оперы?

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

Anatoly Podgoretsky (2008-11-07 16:51:00) [3]
> Сергей М. (07.11.2008 16:27:07) [7]

То же дело.

Anatoly Podgoretsky (2008-11-07 16:50:00) [4]
> Поросенок Винни-Пух (07.11.2008 14:48:03) [3]

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

Сергей М. (2008-11-07 16:27:00) [5]

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

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

Поросенок Винни-Пух (2008-11-07 15:33:00) [6]
в общем пока добился улучшения таким путем:
сервер, сформировав ответ, не делает writeln writeln writeln writebuff,
а формирует в памяти весь блок ответа целиком (заголовок + данные) после чего делает единственный writebuff клиенту.

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

Поросенок Винни-Пух (2008-11-07 15:19:00) [7]
проверялось на одной и той же операции, а там в результате запроса примерно одинаковый контент генерится.
прикол вот еще в чем.
на той же машине стоит другой клиент работающий с другим сервером (моя же разработка, но в прошлом и у другого работодателя).
там тоже тсп/ип но протокол собственный, двоичный.
все отличие только в том, что заголовок представляет собой блок фиксированной длины, который считывается через readbuff.
а дальше, если есть дополнительный блок данных, то его длина извлекается из заголовка и делается еще один readbuff.
так вот. этот "старый" клиент работает как швейцарский ролекс. В тех же условиях на том же модеме с тем же провайдером.

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

clickmaker (2008-11-07 15:04:00) [8]
а от значения content-length не было замечено зависимости?

Поросенок Винни-Пух (2008-11-07 14:48:00) [9]
это понятно что клиент не может найти CRLF.
непонятно почему crlf пропадает только на диалапе и только в одном населенном пункте.

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

clickmaker (2008-11-07 14:46:00) [10]
> Тем не менее клиент не выходит из readln

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

tesseract (2008-11-07 14:45:00) [11]
Обновить систему ? Настройить брандмауэр ?

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »