Indy. TidTCPClient - где ошибка?

← →
Jao (2003-07-02 14:58) [0]

Сервер:
st:=ReadLn;
fs:=Tfilestream.create(filename,fmcreate);
ReadStream(fs,-1,true);
fs.Free;
WriteLn("1");

Клиент:
WriteLn("0");
fs:=Tfilestream.create(filename,fmopenread);
WriteStream(fs,true,false,0);
fs.free;
st:=ReadLn;

----
- убираю последнюю строку *st:=ReadLn* и всё работает, иначе виснет

← →
Digitman © (2003-07-02 15:17) [1]

ты в курсе , чем занимается ReadLn() ?
ты в курсе "новостей", которые привнес в мир программирования механизм сообщений Windows ?

← →
Jao (2003-07-02 15:27) [2]

в TidTCPClient ReadLn занимается принятием строки, причем в демопримере по Indy он этим занимается замечательно :)

← →
Digitman © (2003-07-02 15:42) [3]

> Jao

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

← →
Jao (2003-07-02 17:03) [4]

>Digitman

это всё так, но проблема в том что в TidTCPClient нет сообытия на приход сообщения, в отличии от TTCPClient *во всяком случае я не нашел*

← →
Digitman © (2003-07-02 17:12) [5]

причем здесь событие ? я - о сообщениях Windows

← →
Jao (2003-07-02 17:21) [6]

откуда я знаю какое сообщение отвечает за приход данных на сокет, хоть бы кусочек кода скинул :o) да и не хотелось бы так глубоко копать, когда это, по идее, должно быть предусмотрено в компоненте

← →
Digitman © (2003-07-02 17:29) [7]

> по идее, должно быть предусмотрено в компоненте

по твоей идее, заметь.
но не по идее MS.

совет прост - выноси работу с TidTCPClient в доп.код.поток, организовав там цикл выборки/диспетчеризации win-сообщений. В основном же код.потоке выполняй на здоровье свои ReadLn() - "виснуть" ничего не будет.

← →
Jao (2003-07-02 17:38) [8]

> Digitman

всё уже давно в доп.код.потоке, а насчет "выборки/диспетчеризации win-сообщений" - для меня это темный лес - тупая я сволочь, хех :)))

to Jao:
Сомнение вызывает установка в true параметра ReadUntilDisconnected на сервере. Я бы на Вашем месте сначала передал длину потока и тогда можно было бы точно знать сколько байт ожидать при передаче.

to Digitman:
>совет прост - выноси работу с TidTCPClient в доп.код.поток,
>организовав там цикл выборки/диспетчеризации win-сообщений.
У него же Indy... Там все работает в блокирующем режиме и сообщения Windows не используются.

>vuk
>установка в true параметра ReadUntilDisconnected на сервере

да Оно - теперь работает.

Спасибо всем!!!

> vuk

может быть.
в подробности не вникал.

а вот по поводу префикса размера сообщения - ценный совет автору

Indy. TidTCPClient - где ошибка? Найти похожие ветки