|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
03.01.2009, 11:53 | #1 |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
idTCPClient ошибка ReadTimeOut
Indy 10. TIdTCPClient + TIdSSLIOHandlerSocketOpenSSL;
Принимаю с сервера поток данных: FIdTCPClient.IOHandler.ReadStream(F Stream); Если размер принимаемого меньше, чем 1024, то все ок, если размер принимаемого больше, то через некоторое время на клиенте возникает ReadTimeOut . При этом на сервере логируется, что данные отправлены. Никто не подскажет направление решения этой проблемы? P.S. Ну и совсем, наверное, детский вопрос - все сеансы запрос-прием данных оформлены в отдельных потоках с созданием своих TIdTCPClient, но при этом основной поток приложения серьезно подвисает при первом соединении и существенно менее серьезно - при повторных. Это как-то лечится? |
04.01.2009, 23:13 | #2 |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
Основной вопрос немного разрешился: из-за различных значений параметра MTU на сетевой карте разных машин, где пробовали запускать сервер, пришлось использовать IdTCPClient.IOHandler.SendBufferSiz e. Параллельно я поэкспериментировал с RecvBufferSize, что и определило проблемы с получением ответа сервера и ReadTimeOut. Но что мне неясно и теперь - это продолжающаяся роль размера ответа с сервера. Я получаю его клиентом перед отправкой-приемом самого ответа и пока работает только такой (эмпирически полученный вариант):
if Self.FSize<=1024 then FIdTCPClient.Socket.ReadStream(FStr eam,Self.FSize,false) else FIdTCPClient.Socket.ReadStream(FStr eam); Хорошо, что хоть так пока работает, но нет ни понимания, ни уверенности на будущее. Если кто просветит хоть немного, то буду благодарен. |
06.01.2009, 00:08 | #3 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
дело в том что когда пакет больше чем размер MTU, то пакеты начинают фрагментироваться, добавляется избыточная информация и т.д.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
06.01.2009, 10:48 | #4 |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
Квэнди, да это я уже понял, неясно другое - почему инди не фрагментирует их так, чтобы сервер не рвал сообщение при получении таких пакетов (это происходит не на уровне инди-сервера, а на уровне драйвера сетевой карты или ОС - это уж точно сказать не могу) - сервер получает запрос (это я по пошаговому логу сужу), спокойно начинает формировать ответ, а перед его отпракой констатирует, что клиент отключился, при том, что клиент констатирует "Connection closed gracefully".
Ну да ладно, это вопрос почти отвлеченный, ибо решаемый. Не могли бы Вы прояснить про роль 1024 на стороне клиента и необходимость того финта, что я привел? Ну и насчет подвисания основного потока при соединениях в дополнительных (и особенность первого соединения)? |
06.01.2009, 11:48 | #5 |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
Маленькое поянение. В ответ на запрос клиента я передаю с сервера сначала размер посылки, а затем саму посылку - поток, в который сохранен непустой (минимум - одна запись) TClientDataSet. При любом размере посылки любым из вариантов приема (ReadStream(FStream,Self.FSize, false) или ReadStream(FStream)) я получаю клиентом точно заявленное число байт. Но при попытке считать полученный поток в TClientDataSet на клиенте я часто получаю сообщение "Mismatch data packet". Справиться с этим сообщением получилось только так, как указано выше.
|
06.01.2009, 12:16 | #6 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
потому что если пакет укладывается в MTU то вы получаете вашу структуру полностью за раз, если не укладывается и получается несколькими пакетами, то в каждом из них все равно есть служебная информация. Очевидно Indy не отсеивает её и кидает все в одно,поэтому и Mismatch data packet
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
06.01.2009, 12:17 | #7 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
насчет зависания: это зависание вызвано не неправильной реализацией Indy а самим RowSocket и драйверами ОС, очевидно зависание вызвано некими очередями.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
06.01.2009, 12:26 | #8 | |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
Цитата:
Про зависание - понял, спасибо. Но как-то это жестко - секунд 5-10 висеть при первом соединении. Неужели так со всем софтом, что пишется на инди? |
|
06.01.2009, 18:29 | #9 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
нет, к примеру у меня ни в одном из проектов подобного не наблюдалось, оба хоста проверяли, не бывает потерь ?
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
06.01.2009, 18:35 | #10 |
Форумчанин
Регистрация: 03.01.2009
Сообщений: 116
|
Квэнди, не совсем Вас понял, что не наблюдается и что надо проверить?
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
IdTCPClient, прием сообщений. | gusluk | Работа с сетью в Delphi | 1 | 26.12.2008 09:48 |
IdTcpClient и idTcpServer | xTANATOSx | Работа с сетью в Delphi | 9 | 17.05.2008 23:11 |
Реакция IdTCPClient | OrdJONY | Работа с сетью в Delphi | 3 | 30.08.2007 10:16 |
передача данных через idtcpclient | BioS | Работа с сетью в Delphi | 0 | 20.02.2007 11:04 |