![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TServerSocket в режиме stThreadBlocking [D6, Win95/98, WinME, NT4, Win2k, WinXP]
Filin2000 © (2002-11-12 15:47:00)при работе с TServerSocket в режиме stnonBlocking при отключении клиента проходит событие OnClientDisconect... есть ли что-ниб аналогичное в режиме stThreadBlocking????
filin2000 (2002-11-12 18:22:00) [1]спасибо... буду копать дальше
Digitman (2002-11-12 18:06:00) [2]Скажу более : навряд ли, конечно, авторитет Борланда значит что-то для тебя повлияет на твое оконяательное решение, но вот то, что BSS использует именно такой способ корректной обработки штатного дисконнекта - это факт.
Убедись, если хочешь, сам, изучив тело соотв.метода в коде демо-проекта scktsrvr.dpr
Digitman (2002-11-12 18:02:00) [3]для блок.режима - вряд ли
так или иначе, но факт дисконнекта определяется в этом режиме по возврату значения SOCKET_ERROR с WSAGetLastError = WSAECONNRESET или WSAECONNABORTED для вызванной в какой-то момент ф-ции send()/recv()
Filin2000 (2002-11-12 17:55:00) [4]тоесть для проверки на связи ли клиет ... кроме как пытаться ему что-ниб послать и получить ошибку если он отключен.. ничего более изящьного нельзя придумать???
Digitman (2002-11-12 17:46:00) [5]
у меня когда клиент отключается
Ка отключается ? Выполняет на своей стороне ClientSocket.Close ? Или - ножницами по сет.кабелю ? Абсолютно разные ж вещи ! И реакция совершенно разная д.б. предусмотрена на штатный и нештатный разрыв транспортного канала
> свойство ClientSocket.Connected
> не переходит в false
И не перейдет - гнездо-то по-умолчанию работает в синхронном блокирующем режиме. Явный перевод гнезда в неблок.режим ощутимо усложнит код ClientExecute(), хотя и даст возможность использовать асинхронные нотификации о состоянии кл.транспорта (и некоторые иные преимущества)
Filin2000 (2002-11-12 17:37:00) [6]это логично.. но не решает проблемму..
у меня когда клиент отключается свойство ClientSocket.Connected не переходит в false
Digitman (2002-11-12 17:32:00) [7]стандартное решение (и, пожалуй, самое простое для блок.режима) - одно :
while not Terminated and ClientSocket.Connected do
try
..... все, что угодно
except
on e:ESocketConnectionError do
ClientSocket.Close;
end;
Filin2000 (2002-11-12 17:19:00) [8]код ничего не даст... :-(
хотя хотельсь бы что-то типа
...
repeat
if ClientSocket.ReceiveLength<>0 then ..что-то делаем
until Terminated or (not ClientSocket.Connected)
...
и вот... когда клиет закрывает соединение то ничего не происходит.. Thread так и прожолжает работать...
вообще как мне кажется должно быть стандартное решение этой проблеммы.. но найти его я никак не могу....
Digitman (2002-11-12 17:07:00) [9]>Filin2000
Давай-ка, чтобы не трепаться впустую, приведи свой существующий вариант тела ClientExecute. Желательно - полный. Я прокомментирую и выскажу свои соображения.
Filin2000 (2002-11-12 16:59:00) [10]такая система работает... пробовал...
тока вот по сети гонять пакеты ради проверки состояния????
и потом... при отключении клиента серверу приходит некий пакет (проверял)... вопрос.. как его отловить???
Digitman (2002-11-12 16:52:00) [11]
> охота
Охота пуще неволи )
О том, что клиент отключился, в этом случае ты узнаешь, получив исключение при попытке вызова любого Send-метода объекта TServerClientWinSocket для возврата результата клиентского запроса. Перехватывай это исключение и немедленно "закругляйся" с выполнением процедуры TServerClientThread.ClientExecute
Все остальное объект TServerSocket сделает сам.
Filin2000 (2002-11-12 16:40:00) [12]хочется сделать следующее...
на каждого клиента по одному потоку (обработка запросов клиентов может сильно затянуться.. а хочется чтоб в это время короткие запросы других клиентов тоже обрабатывались)... и вот клиент запрос поставил и отключился .... охота откличить Thread
Digitman (2002-11-12 16:23:00) [13]тебе для каких целей нужно это событие ?