IdTCPClient

← →
Manulo © (2004-02-09 18:47) [0]

Что можно сделать, что бы он не вешал приложение при коннекте, если удалённый хост долго (или совсем) не отвечает?

← →
Rouse_ © (2004-02-09 19:46) [1]

Работать в неблокирующем режиме либо в другом потоке...

← →
Manulo © (2004-02-09 20:01) [2]

Запихнул в другой поток, не помогло... тем более, что IdTCPClient по BeginWork по моему тоже создаёт поток... хотя с английским у меня слабовато, мог и неправильно прочитать.

А насчёт неблокирующих сокетов... Это идея!!!

← →
Manulo © (2004-02-09 20:03) [3]

Кстати, а как IdTCPClient заставить работать в неблокирующем режиме?

← →
h0use © (2004-02-10 11:27) [4]

Присоединяюсь к пред. оратору [3]. Как Indy заставить в неблокируемом режиме работать?

← →
Reindeer Moss Eater © (2004-02-10 11:36) [5]

переписать его исходные тексты

← →
Verg © (2004-02-10 11:37) [6]

> h0use © (10.02.04 11:27) [4]
> Присоединяюсь к пред. оратору [3]. Как Indy заставить в
> неблокируемом режиме работать?

По-моему никак.
Indy по-определению работает с сокетами в блок. режиме.
Если кто разбирался подробно, пусть меня поправит.

Вот в TTCPClient предусмотрен этот режим.

← →
h0use © (2004-02-10 11:53) [7]

Интересно, а кто-нибудь пробовал к TidTCPServer присоединить TTCPClient?

← →
Erik © (2004-02-10 11:55) [8]

Есть такая проблема и частично решается она через установку TimeOut. Для избежания ее ненадо создовать конектов!

P.S.
Нет человека, нет проблемы. :)
P.S.S.
Еще UDP можно воспользоватся.

← →
Verg © (2004-02-10 12:00) [9]

> h0use © (10.02.04 11:53) [7]
> Интересно, а кто-нибудь пробовал к TidTCPServer присоединить
> TTCPClient?

:)))

А в чем сомнения? Протокол-то один и тот же - TCP/IP.

Это ж всего лиш разные "обертки" одной и той же сущности - Socket Api.

← →
Verg © (2004-02-10 12:06) [10]

> Erik © (10.02.04 11:55) [8]
> Есть такая проблема и частично решается она через установку
> TimeOut. Для избежания ее ненадо создовать конектов!
>
> P.S.
> Нет человека, нет проблемы. :)
> P.S.S.
> Еще UDP можно воспользоватся.

На самом деле, для избежания этих проблем ДДБ навернул на неблок. режим сокетов еще один - асинхронный, ДДБ "завернул" это в T(Client/Server)Socket. Правда остались невопощенными в компоненты возможности Winsock2....
Но, насколько я понял, всем полюбились именно Indy. Видимо всем надо переносимость под Kylix....

PS
ДДБ - Добрый Дядя Билл
ДДБ - Добрый Дядя Борланд

← →
h0use © (2004-02-10 12:12) [11]

Кстати, как задействовать Winsock2?

← →
Digitman © (2004-02-10 12:20) [12]

> h0use © (10.02.04 12:12) [11]
> Кстати, как задействовать Winsock2?

uses Winsock2

← →
Verg © (2004-02-10 12:22) [13]

> h0use © (10.02.04 12:12) [11]
> Кстати, как задействовать Winsock2?

Что значит "как"?
Брать, да пользоваться расширенными функциями Winsock2.
Или я не понял вопроса.

← →
Verg © (2004-02-10 12:28) [14]

http://delphimaster.net/view/6-1075625924/

Там найдешь ссылку где взять Winsock2.pas

← →
Reindeer Moss Eater © (2004-02-10 12:33) [15]

Интересно, а кто-нибудь пробовал к TidTCPServer присоединить TTCPClient?

Если включить телепатию и перевести твой вопрос на русский, то :
попробовали сами авторы библиотеки, создав класс TidTCPConnection

← →
Manulo © (2004-02-10 14:07) [16]

> Но, насколько я понял, всем полюбились именно Indy.

С TClient(Server)Socket была тоже не вполне понятная проблема, когда коннект вроду бы и есть, а данные вроде бы и не идут :( Поэтому использую Indy... И если бы не тормоза.....

← →
h0use © (2004-02-10 14:10) [17]

> Manulo © (10.02.04 14:07) [16

Именно по той же самой причине перелез на Инди, но вот уже смотря 9-ю и 10-ю версию с сожалением вижу, что асинхронности там нет и судя по всему не будет, как и поддержки Winsock2 :(

← →
Verg © (2004-02-10 14:23) [18]

> Manulo © (10.02.04 14:07) [16]
>
> > Но, насколько я понял, всем полюбились именно Indy.
>
>
> С TClient(Server)Socket была тоже не вполне понятная проблема,
> когда коннект вроду бы и есть, а данные вроде бы и не идут
> :( Поэтому использую Indy... И если бы не тормоза.....

Да, видимо, Indy и подкупает своей "очевидностью" так сказать "drop and play".
DOS конечно не WinXP, но зато как все просто и понятно...

> h0use © (10.02.04 14:10) [17]
>
> > Manulo © (10.02.04 14:07) [16
>
> Именно по той же самой причине перелез на Инди, но вот уже
> смотря 9-ю и 10-ю версию с сожалением вижу, что асинхронности
> там нет и судя по всему не будет, как и поддержки Winsock2
> :(

Дык я ж говорю - видимо целью проекта Indy и была как раз кроссплатформенность, т.е. им нельзя было расчитывать на такие возможности/особенности сокетного ядра Windows, которые нельзя бы было воспроизвести под Линуксом.

← →
Manulo © (2004-02-10 14:23) [19]

> h0use © (10.02.04 14:10) [17]

Асинхронности точно не будет...

Но всё равно, неужто ни у кого не получилось решить проблему "тормозов"?

← →
Verg © (2004-02-10 14:34) [20]

> Manulo © (10.02.04 14:23) [19]
> Но всё равно, неужто ни у кого не получилось решить проблему
> "тормозов"?

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

← →
Vogus (2004-02-10 14:37) [21]

Может я чего-то не понимаю: А IdAntiFreeze не помогает?

← →
Manulo © (2004-02-10 14:49) [22]

type TTransportThread = class(TThread) private FRemoteHost : String; FRemotePort : Integer; FClient : TidTCPClient; protected procedure Execute; override; public constructor Create(CreateSuspended: Boolean = false); procedure set_rem_host(host:string); end;

var TransportThread : TTransportThread;

constructor TTransportThread.Create(CreateSuspended: Boolean); begin inherited Create(CreateSuspended); end; procedure TTransportThread.set_rem_host(host:string); begin FRemoteHost:=host; FRemotePort:= 1500; end; procedure TTransportThread.Execute; var s : string; i : integer; begin try FClient := TidTCPClient.Create(nil); try try EndWorkFlag:=false; FClient.Host := FRemoteHost; FClient.Port := FRemotePort; FClient.Connect; if FClient.Connected then FClient.WriteLn("ping"); if FClient.Connected then s:=FClient.ReadLn; FClient.Disconnect; form1.PingAnalis(s); except form1.Memo1.Text:=form1.Memo1.Text+"ERROR!"; end; finally FClient.Free; end; except //..лог исключений end; end;

procedure TForm1.FormCreate(Sender: TObject); begin TransportThread:=TTransportThread.Create(true); // :=new(TTransportThread); //выдаёт ошибку // New(TTransportThread,create(true)); //выдаёт ошибку end;

procedure TForm1.ping_timerTimer(Sender: TObject); begin TransportThread.set_rem_host(get_ip); TransportThread.Execute; end;

> А IdAntiFreeze не помогает?

Нет, хотя может быть я не совсем разобрался, как им пользоваться

← →
Verg © (2004-02-10 15:17) [23]

> Manulo © (10.02.04 14:49) [22]

Стоп, стоп... Дык в какой-то из 9-х версий Indy connect и так уже выделен в отдельный поток.
Или я ошибаюсь?

Т.е. В той, которая идет с D6 connect блокирующая операция и никакой антифриз там не поможет.
А вот в девятке, по-моему уже они припаяли тут Thread. На коннекте запускают его, он делает блокирующий connect, а в это время главный потоку кружится в цикле с антифризом, ожидая, пока этот поток не завершится.

← →
h0use © (2004-02-10 15:22) [24]

> Verg © (10.02.04 15:17) [23]

Так-так, отсюда да поподробней...

← →
Verg © (2004-02-10 15:38) [25]

> h0use © (10.02.04 15:22) [24]
>
> > Verg © (10.02.04 15:17) [23]
>
> Так-так, отсюда да поподробней...

Не, я знатоком по инди и не бывал. Ну не нужны они мне.

Однако иногда поглядываю туда...

Ну короче, в девятке, когда ты вызываешь IdTCPClient.Connect запускается поток, управлять которым ты не можешь, т.е. он скрытый от тебя полностью. Этот поток и производит попытку соединения, вызывая connect (блокирующий) из winsock. Пока этот поток выполняется ClientConnect кружит цикл, вызывая антифриз, который по их словам в свою очередь вызывает в том числе Applciation.ProcessMessages и котролируя таймайт. Если этот тайм-аут кончится раньше, чем поток закончит работу (вне зависимости от результата) Winsock.connect, то (!! :)) этот цикл говорит тому потоку Terminate (т.е. ставит флажок типа, только зачем?, если в этом потоке нет ни единого цикла) и потом WaitFor (надо же, так он и прервал им WinSock.connect раньше, чем тот сам захочет :))). Вот придется циклу поодождать таки, пока WinSock.Connect не закончит свое дело. Ну да ладно - это уже нюансы...
Т.е. все равно, получается, что пока соединение происходит, IDTCPClient.Connect НЕ вернет управления. Хотя и будет происходить диспетчерезация сообщений главным потоком.

Если интересно, возьми исходники на http://www.indyproject.org и приглядис к файлу IdIOHandlerSocket.pas там это все, о чем я писал.
Ну уж как понял - так понял....

← →
Manulo © (2004-02-10 15:41) [26]

> Verg © (10.02.04 15:17) [23]

то есть, по твоему установка 9-х индей решит проблему? Поэксперементируем

← →
Verg © (2004-02-10 15:51) [27]

> Manulo © (10.02.04 15:41) [26]
>
> > Verg © (10.02.04 15:17) [23]
>
> то есть, по твоему установка 9-х индей решит проблему? Поэксперементируем

> Т.е. все равно, получается, что пока соединение происходит,
> IDTCPClient.Connect НЕ вернет управления. Хотя и будет происходить
> диспетчерезация сообщений главным потоком.

Если тебя вот это устроит, то "решит", наверно :)
Экспериментируй, конечно: одна маленькая практика стоит большой теории...
Не забудь сюда сообщить результаты, ОК ?

Кроме того, на вот, почитай (только не обчитайся :)))

http://www.atozedsoftware.com/indy/Articles.iwp

← →
h0use © (2004-02-10 15:52) [28]

Отлично...а что сделать, чтоб приложение не вешалось при ожидании сообщения от сервера?

> h0use © (10.02.04 15:52) [28]
> Отлично...а что сделать, чтоб приложение не вешалось при
> ожидании сообщения от сервера?

Ну тут-то должен помочь антифриз.

И опять же с той оговоркой, что индевый ReadBuf (или как там у них) НЕ вернется до тех пор, пока не получит таки заказанное тобою количество байт.

Ну или сам вызывай этот, как его там..... ReadFromStack по таймеру или еще как-нибудь, пока не соберется нужного количества байтов.

Ну аналогии-то очевидны. Indy - это как ввод информации опросом готовности порта,
а Winsock асинхронный режим (TClientSocket) - это как ввод по прерываниям.

> Verg © (10.02.04 15:51) [27]

Не знал, что установка 9-й версии поверх 8-й такой трудоёмкий и опасный процесс...

Поставил девятые, перекомпилил (ни кода, ни property) не трогал. При запуске сначала разницы не увидел (у меня по таймеру пропинговаваются серваки по заданному списку), то есть было лёгкое подтормаживание если удалённый сервер включён, но порт закрыт, потом попустило :)
самый волнующий моментю когда физически выдернул сетевой шнурок из розетки... тайм аут выжыдался чесно, но приложение НЕ ВИСЕЛО! :) Чего и требовалось достичь
Исходники приведены выше, на форме ещё валялся АнтиФриз.

> Winsock асинхронный режим (TClientSocket) - это как ввод
> по прерываниям.

Если бы он коннекта не терял по неопознанным причинам, то цены бы ему не было, а так приходится Indy с антифризом юзать как псевлоасинхронку :(

> Manulo © (10.02.04 16:22) [30]

Отлично. Теперь попробуй вот что:
Попробуй соединится на какой-нибудь ip-шник в сети (но не в локальной, конечно), но на котором, точно никого нет (пропингуй там или как).
Но тайм-аут соединения поставь заведомо меньше, чем требуется для того, чтобы connect-ту "обнаружить, что нет живых" на этом IP.
Сколько будет выполнятся ф-ция IdTCPClient.Connect в таком случае?

Я делаю ставку на то, что она будет выполнятся дольше, чем ты указал в таймауте :)))

> h0use © (10.02.04 16:29) [31]
>
> > Winsock асинхронный режим (TClientSocket) - это как ввод
>
> > по прерываниям.
>
> Если бы он коннекта не терял по неопознанным причинам, то
> цены бы ему не было, а так приходится Indy с антифризом
> юзать как псевлоасинхронку :(

Нет, работает TClientSocket как часы, поверь мне. Где-то ты в коде "намудрил".

Как часы он может и работает.
Только ничего кроме соединения точка-точка не умеет.

А клиенту подавай работу через целый список типов прокси и прочие фичи.

> Reindeer Moss Eater © (10.02.04 16:45) [34]
> Как часы он может и работает.
> Только ничего кроме соединения точка-точка не умеет.
>
> А клиенту подавай работу через целый список типов прокси
> и прочие фичи.

Что есть, то есть.
Я разве возражаю?

Главное отдавать себе отчет при использовании черных ящиков в том, на "каком бензине они ездят", чтобы изначально правильно построить проект, на них ориентированный.

Да, кстати, как это "где"?
Вот смотрю на исходник, вижу:

procedure TIdTCPClient.Connect(const ATimeout: Integer = IdTimeoutDefault);

Там еще глобальный таймаут есть у всей компоненты ;)

> Verg © (10.02.04 17:02) [38]

мдя... дня три ускал когда то, где можно тайм-аут перехватить... А всё оказалось до обидного просто :(

IdTCPClient Найти похожие ветки