idTCPClient ошибка ReadTimeOut

[Антон Ю.Б.]

Indy 10. TIdTCPClient + TIdSSLIOHandlerSocketOpenSSL;
Принимаю с сервера поток данных:
FIdTCPClient.IOHandler.ReadStream(F Stream);
Если размер принимаемого меньше, чем 1024, то все ок, если размер принимаемого больше, то через некоторое время на клиенте возникает ReadTimeOut . При этом на сервере логируется, что данные отправлены. Никто не подскажет направление решения этой проблемы?

P.S. Ну и совсем, наверное, детский вопрос - все сеансы запрос-прием данных оформлены в отдельных потоках с созданием своих TIdTCPClient, но при этом основной поток приложения серьезно подвисает при первом соединении и существенно менее серьезно - при повторных. Это как-то лечится?

[Антон Ю.Б.]

Основной вопрос немного разрешился: из-за различных значений параметра 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);

Хорошо, что хоть так пока работает, но нет ни понимания, ни уверенности на будущее. Если кто просветит хоть немного, то буду благодарен.

[Квэнди]

дело в том что когда пакет больше чем размер MTU, то пакеты начинают фрагментироваться, добавляется избыточная информация и т.д.

[Антон Ю.Б.]

Квэнди, да это я уже понял, неясно другое - почему инди не фрагментирует их так, чтобы сервер не рвал сообщение при получении таких пакетов (это происходит не на уровне инди-сервера, а на уровне драйвера сетевой карты или ОС - это уж точно сказать не могу) - сервер получает запрос (это я по пошаговому логу сужу), спокойно начинает формировать ответ, а перед его отпракой констатирует, что клиент отключился, при том, что клиент констатирует "Connection closed gracefully".

Ну да ладно, это вопрос почти отвлеченный, ибо решаемый. Не могли бы Вы прояснить про роль 1024 на стороне клиента и необходимость того финта, что я привел? Ну и насчет подвисания основного потока при соединениях в дополнительных (и особенность первого соединения)?

[Антон Ю.Б.]

Маленькое поянение. В ответ на запрос клиента я передаю с сервера сначала размер посылки, а затем саму посылку - поток, в который сохранен непустой (минимум - одна запись) TClientDataSet. При любом размере посылки любым из вариантов приема (ReadStream(FStream,Self.FSize, false) или ReadStream(FStream)) я получаю клиентом точно заявленное число байт. Но при попытке считать полученный поток в TClientDataSet на клиенте я часто получаю сообщение "Mismatch data packet". Справиться с этим сообщением получилось только так, как указано выше.

[Квэнди]

потому что если пакет укладывается в MTU то вы получаете вашу структуру полностью за раз, если не укладывается и получается несколькими пакетами, то в каждом из них все равно есть служебная информация. Очевидно Indy не отсеивает её и кидает все в одно,поэтому и Mismatch data packet

[Квэнди]

насчет зависания: это зависание вызвано не неправильной реализацией Indy а самим RowSocket и драйверами ОС, очевидно зависание вызвано некими очередями.

[Антон Ю.Б.]

потому что если пакет укладывается в MTU то вы получаете вашу cтруктуру полностью за раз, если не укладывается и получается несколькими пакетами, то в каждом из них все равно есть служебная информация. Очевидно Indy не отсеивает её и кидает все в одно,поэтому и Mismatch data packet

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

Про зависание - понял, спасибо. Но как-то это жестко - секунд 5-10 висеть при первом соединении. Неужели так со всем софтом, что пишется на инди?

[Квэнди]

нет, к примеру у меня ни в одном из проектов подобного не наблюдалось, оба хоста проверяли, не бывает потерь ?

[Антон Ю.Б.]

Квэнди, не совсем Вас понял, что не наблюдается и что надо проверить?