ServerSocket обрыв соединения?

← →
Valerik (2004-04-20 23:03) [0]

Каким событием отловить в данном компоненте обрыв соединения
(например физический)?

← →
Rouse_ © (2004-04-21 00:09) [1]

Каково соедиение? Режим гнезда? ...

← →
Digitman © (2004-04-21 08:55) [2]

> например физический

физический - никаким

← →
Valerik (2004-04-21 09:09) [3]

Вообщем на одном компе стоит ServerSocket, на другом ClientSocket
при выдергивании шнура из сетевой карты по событиям ServerSocket1ClientError и ServerSocket1ClientDisconnect ничего не отлавливается. (????) В то же время на клиенте срабатывает событие ClientSocket1Error.
Если на сервере отключить программно сетевую карту то работает событие ServerSocket1ClientError.

← →
Digitman © (2004-04-21 10:03) [4]

> по событиям ServerSocket1ClientError и ServerSocket1ClientDisconnect
> ничего не отлавливается. (????)

не должно и не будет "отлавливаться"

> В то же время на клиенте срабатывает событие ClientSocket1Error

если клиент полключился и "молчит", то и этого события ты не получишь

> Если на сервере отключить программно сетевую карту то работает
> событие ServerSocket1ClientError

но если сервер "молчит", у клиента никакие события не возникунут

суть проста - события на той или иной стороне соединения возникают не сами по себе, они есть реакция на получение TCP/IP-пакетов ... если же произошел физ.отказ транспортного канала, ожидающая транспортных событий сторона не получит никаких пакетов (а откуда они, спрашивается, возьмутся, если "шнурок выдернут" ?) и, соответственно, не возбудит никакие события

для таких целей в самом простом случае следует реализовать т.н. программный KeepAlive-механизм.. каждая из сторон соединения ведет таймер, подсчитывающий время прошедшее с момента последнего произошедшего события On[Client]Read.. если это время превышает некий порог ожидания, партнеру посылается некое контрольное сообщение, мол, "ты жив или мертв ?" ... партнер, в принципе, может и не отвечать на это сообщение ... но при вызове любого Send-метода, если в трансп.канале произошел некий отказ, будет либо немедленно возбуждено исключение ESocketConnectionError либо через некот.время возникнет событие On[Client]Error .. обе ситуации следует рассматривать как критические (очевидная невозможность дальнейшего инф.обмена по установленному с партнером соединению) и тут же вызывается Close-метод для отказавшего гнезда

← →
Valerik (2004-04-21 12:15) [5]

Спасибо

← →
Григорьев Антон (2004-04-21 12:21) [6]

Про TServerSocket не скажу, не работал с ним, но программировал сокеты на уровне API. И могу точно сказать, что серверный сокет, не совершающий никаких активных действий, очень долго не получает никакой информации о потере связи. Иногда - минут 10, иногда - до получаса. Надо просто подождать.

← →
Digitman © (2004-04-21 12:38) [7]

> Надо просто подождать

ну да, конечно... ждать до морковкиного заговения, до второго пришествия)

чего ждать-то, скажи на милость ? канал-то физически разорван уже, ничего с "того конца" уже не пооступит и ждать пока "пробъет" где-то что-то - попросту бессмысленно .. если есть подозрения, что за прошедшие, к примеру, 10 миним от партнера должно было что-то прийти (имеется ввиду - по ЕГО, партнера, инициативе), а партнер молчит, то нечего ждать, следует проявить инициативу самому, послав хоть что-нибудь партнеру ... и нештатный разрыв трансп.канала, если он действительно имел место быть, обязательно "просигналит" либо исключением либо событием On[Client]Error

← →
Verg © (2004-04-21 13:15) [8]

Сокету можно установить опцию SO_KEEPALIVE, тогда после некоторого времени молчания в этом соединении, ядро будет проверять целостность соединения отправками специальных сегментов TCP (keepalive probe).
Интервал этот достаточно большой (около двух часов), но все же он конечен.

В winsock2 появилась, кстати, новая "фишка":

SIO_KEEPALIVE_VALS
Enables the per-connection setting of keep-alive option, keepalive time, and keepalive interval. The argument structure for SIO_KEEPALIVE_VALS is as follows:
/* Argument structure for SIO_KEEPALIVE_VALS */
struct tcp_keepalive {
u_long onoff;
u_long keepalivetime;
u_long keepaliveinterval;
};

Это было в rsdn #1 2004 про определение разрыва ip соединения.
Меня только удивили слова автора (Андрей Елсуков) - "в MSDN очень скупо это все описано ... если кто-то лучше осведомлен, буду раз выслушать пояснения".

← →
Григорьев Антон (2004-04-21 13:52) [10]

> Digitman © (21.04.04 12:38) [7]
>
> > Надо просто подождать
>
>
> ну да, конечно... ждать до морковкиного заговения, до второго
> пришествия)
>
> чего ждать-то, скажи на милость ? канал-то физически разорван
> уже, ничего с "того конца" уже не пооступит и ждать пока
> "пробъет" где-то что-то - попросту бессмысленно .. если
> есть подозрения, что за прошедшие, к примеру, 10 миним от
> партнера должно было что-то прийти (имеется ввиду - по ЕГО,
> партнера, инициативе), а партнер молчит, то нечего ждать,
> следует проявить инициативу самому, послав хоть что-нибудь
> партнеру ... и нештатный разрыв трансп.канала, если он действительно
> имел место быть, обязательно "просигналит" либо исключением
> либо событием On[Client]Error

Это, конечно, хорошо, когда что-то можно послать партнёру, но не все протоколы допускают это. Мне приходилось реализовывать протоколы, в которых сервер не имел права отправлять клиенту что-либо по собственной инициативе. Так что приходилось сидеть и ждать. А что ещё делать-то?

> Мне приходилось реализовывать протоколы, в которых сервер
> не имел права отправлять клиенту что-либо по собственной
> инициативе

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

> А что ещё делать-то?

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

все ! какие сложности-то ?

ServerSocket обрыв соединения? Найти похожие ветки