IdTCPClient - не могу понять...

← →
Behemoth © (2004-02-06 12:54) [0]

Когда сервер(IdTCPServer) к которому подключен IdTCPClient умирает, то клиент не получает дисконекта, и думает что он до сих пор подключен (IdTCPClient.Connected=true). Как мне в клиенте узнать что сервер сдох?

← →
Reindeer Moss Eater © (2004-02-06 12:55) [1]

скажи что нибудь серверу, или послушай его

← →
Digitman © (2004-02-06 12:59) [2]

> к которому подключен

заметь - виртуально ... а не физически

← →
Behemoth © (2004-02-06 13:12) [3]

А другого пути нет?
Ибо придется мне раз в секунду кидать строку серверу, только чтоб узнать сдох ли он. Это нехорошо.
Да. И почему сервер при Active:=false не посылает своим клиентам дисконест?

← →
Digitman © (2004-02-06 13:26) [4]

> Ибо придется мне раз в секунду кидать строку серверу, только
> чтоб узнать сдох ли он. Это нехорошо.

иного способа нет. KeepAlive-механизм используют многие известные прогр.продукты известных же производителей. Неспроста, наверно, как думаешь ?

> почему сервер при Active:=false не посылает своим клиентам
> дисконест

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

← →
Reindeer Moss Eater © (2004-02-06 14:08) [5]

Ибо придется мне раз в секунду кидать строку серверу, только чтоб узнать сдох ли он.

А какой интерес клиенту знать "сдох ли сервер" если клиент не ведет обмен с сервером? Из праздного любопытства?

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

Хм. Насколько я знаю, Indy использует самый обычный блокирующий режим сокета. Поэтому узнать о его состоянии можно только самому вызвав операции ввода-вывода и/или select. Если ты периодически проверяешь на наличие принятых данных (обертка для этой операции вроде ReadFromStack называется), то этого будет достаточно, чтобы определить не закрылось ли соединение. Не закрылось ли так сказать "штатно", т.е. как ты пишешь Active:=false на другой стороне соединения.
Другое дело, что эта "другая сторона" может просто "умереть" (тривиально - выключили питание, например; выдернули сетевой шнурок из карточки и т.п.). Вот тут, простым ожиданием данных такую ситуацию обнаружить невозможно. По крайней мере за приемлимое время (SO_KEEPALIVE имеет интервал проверок по-умолчанию что-то типа 2-х часов, по-моему и регулируется только целиком для всего TCP ядра ОС, а не для конкретного сокета). Тут придется время от времени посылать тестовые данные, которые протоколом обмена воспринимаются как NOP (нет операции). Периодически обмениваясь такими зондами во время отсутствия полезных данных, стороны соединения могут достаточно быстро, а главное надежно обнаружить факт "смерти" оппонента.

Verg совершенно прав. Я съел собаку на Indy TCP, поэтому дам сразу кардинальный совет, как я раз и навсегда "вылечил" его от подобного рода запоров. Не поленитесь, создайте потомков от его компонент (потребуются потомки от TIdBaseServer, TIdTCPServer, TIdPeerThread и, если правильно помню, TIdTCPConnection (они в одном файле, смело копируете, переименовываете и меняете названия), а также TIdTCPClient), и все это ради того, чтобы у потомков TIdPeerThread и TIdTCPClient скрыть прежние и создать свои методы на чтение/запись. Я переписал нужные мне запись/чтение buffer, integer, string, boolean. А суть их переделки в том, чтобы обрамить старые методы блоками try...except, свойством обработчика ошибок и/или состояния и timeout"ами. И все соединения ведите по принципу "послал блок/строку/целое - дождался ответа", а не "пишу, пока есть что писать, а потом читаю, пока есть, что читать".
Я мучился долго, неделю переписывал, потом почти месяц тестировал, особенно с последним (своя специфика передачи файлов), но с тех пор уже два года, как проблем не знаю - использую в десятке программ (специфика работы такая - удаленные соединения). А до того тоже год страдал от неизвестных зависов и ошибок в прогах. Только того не пойму, почему сами разработчики оставили все таким необработанным.

именно поэтому способные думать люди используют простейший (прозрачнейший в реализации !) транспорт на базе TClient/ServerSocket ... т.е. компонент-классы без идиотских наворотов а-ля Инди для ничегонепонимающих "батонобросателей", возомнивших себя сетевыми "гуру" лишь на основании опробованной когда-то работоспособности какого-то там демо-примера от Борланда для ЛВС

IdTCPClient - не могу понять... Найти похожие ветки