ServerSocket проверка на физический разрыв сети

← →
Вячеслав Чернов (2002-07-04 13:48) [0]

Может кто сталкивался с периодической проверкой подключения клиента на предмет доступности. Стрессовая ситуация - выдернут сетевой шнурок и Socket.Connected возвращает true.
Это глюк или нормальная работа ServerSocket.

← →
Digitman (2002-07-04 17:53) [1]

Это - нормальная работа. Но не ServerSocket, а самого протокола TCP/IP.
Разрыв TCP/IP-соединения - понятие логическое, не физическо и в общем случае представляет собой факт получения приемником (и, как правило, отправки передатчиком) TCP-пакета с флагом-признаком RST (reset, сброс). Если "выдернут сетевой шнурок" хотя бы на одной из сторон, ни о каком логическом взаимодействии между удаленными партнерами не может быть и речи.

← →
ChernoVVV (2002-07-04 18:18) [2]

Тогда почему факт обрыва связи отслеживает ClientSocket, ServerSocket молчит ?

← →
Digitman (2002-07-04 18:26) [3]

>ChernoVVV

С чего ты взял, про ClientSocket ? Чем он принципиально отличается с т.з. единого используемого протокола от ServerSocket ?

Приведи, пожалуйста, аргументы в пользу такого утверждения.

← →
ChernoVVV (2002-07-04 18:55) [4]

Аргумент " OnError -> OnDisconnect" срабатывает в 99.99% случаях, во всяком случае у меня, может это как раз глюк :)

← →
Digitman (2002-07-05 08:06) [5]

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

← →
ChernoVVV (2002-07-05 08:47) [6]

Клиент периодически делаю проверку [9сек] на (Active=true)and(ClientSocket.Socket.Connected)and(ClientSocket.Socket.RemoteAddress<>"") - это чистый эксперимент? Если на серверной части я буду проверять тоже самое для ServerSocket всегда будет true вне зависимости от подключения.

← →
Digitman (2002-07-05 10:43) [7]

Нет, это не чистый эксперимент.

Как минимум потому, что в контексте метода GetRemoteAddress() вызывается WinsockAPI-ф-ция :

CheckSocketResult(getpeername(FSocket, SockAddrIn, Size), "getpeername");

← →
ChernoVVV (2002-07-05 11:53) [8]

Почему же тогда на стороне сервера аналогичный GetRemoteAddress() не вызывает исключения ?

← →
Digitman (2002-07-05 12:05) [9]

Ага ! Таки поймал ты исключение ?) Собственно, это вот и ответ на твой вопрос по клиентской стороне : "молчит" клиент - ни черта он не получит никаких извещений о том, что "шнурок" у сервера "оторвали" ...

А вот чтобы ответить на аналог.вопрос по серверной стороне, необходимо знать режим инициализации ServerSocket (thread-blocking/non-blocking), программное окружение созданного серверного объекта класса TServerSocket и конкретноею место в коде, где происходит обращение к методам/св-вам объекта класса TClientServerWinSocket, установившего соединение с "оборвавшимся" клиентом

Приводи код - разберем его

← →
ChernoVVV (2002-07-05 12:42) [10]

Инициализация -> ServerSocket.ServerType := stNonBlocking;
OnConnect(Server) -> User( TUser(TObject+Socket)).Socket( TCustomWinSocket) := Socket( OnConnect(Socket));(add in list)
Проверка подключения -> (User[i].Socket=nil)or(not User[i].Socket.Connected)or(User[i].Socket.RemoteAddress) then User[i].Free(del in list);<- это как раз и не срабатывает !

← →
Digitman (2002-07-05 16:10) [11]

1. Ну а где же у тебя обработчик OnClientError() ? Как же ты собираешься перехватывать исключительные ситуации при обращении к уже несуществующему физически транспортному каналу с клиентом ?

2. Что значит "срабатывает" или "не срабатывает" ?
Ты программист или где ? Поставь брейкпойнт на строчке "проверки подключения", поймай брейкпойнт в момент, когда клиент заведомо "оборван" и почитай средствами отладчика свойство User[i].Socket.RemoteAddress ! Чему оно равно ? Возбуждает ли дебагер исключение при этом ?

3. Все, что делает свойство TCustomWinSocket.Connected - возвращает значение приватного поля TCustomWinSocket.FConnected.
Которое ,в свою очередь, становится True при установлении успешного коннекта с партнером, и сбрасывается в False при вызове метода TCustomWinSocket.Disconnect().

TCustomWinSocket.Disconnect() вызывается автоматически :
- в деструкторе объекта TCustomWinSocket (ты его вызывал, деструктор ?);
- перед вызовом обработчика OnDisconnect() (когда соединение корректно закрывается по инициативе партнера);
- при возбуждении классом TCustomWinSocket исключения, связанного с отказом одной из гнездовых API-ф-ций (связанных, кроме всего прочего, и с обращением по чтению/записи к проблемному транспортному каналу)

В этом есть какие-то сомнения ? Можешь проверить всю эту логику (да и давно надо было бы !) в модуле scktcomp.pas.

Ну что ? Дальше ? Или таки убедил я тебя в некорректности твоего варианта проверки активности соединения ?

ServerSocket проверка на физический разрыв сети Найти похожие ветки