| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Ошибка на сокете
Leviathan © (2001-12-10 22:29:00)Привет! Скажем, произошла на сокете ошибка, было три клиента, один нелегально отпал (завис, например). Как это обработать? OnDisconnect, естественно, не происходит. И будет ли продолжать за сокетом числиться этот номер коннекшна?
Polevi (2001-12-14 15:22:00) [1]>продолжает числиться как здоровый коннекшн
раз конекшн "здоровый" - откуда OnError?
Digitman (2001-12-13 07:53:00) [2]OnError в такой ситуации никогда не возникнет.
Leviathan (2001-12-11 19:51:00) [3]Большое спасибо всем за помощь!
Polevi:
Я правильно понял что умерший клиент продолжает числиться как здоровый коннекшн, и только после его отключения список коннекшнов "сдвинется вниз"? Если да, то почему бы вместо периодического опроса не проводить такой опрос в OnError? Возможно это?
Digitman (2001-12-11 15:43:00) [4]>Leviathan
Логику, упомянутую <Polevi>, принято определять термином "Keep Alive" (по-русски примерно интерпретируемую как механизм периодического извещения взаимодействующих друг с другом процессов о том , что каждый из них "жив" и способен реагировать на последующие сообщения партнера по коннекту). Программная реализация механизма "Keep Alive" на уровне приложений, конечно же, усложняет протокол информационного взаимодействия в распределенных системах, но в ряде случаев оправдан (ICQ!!!). Программная реализация того же механизма на уровне Winsock тоже существует, но не может быть задействована при использовании "жестко прошитых" классов TServerSocket и TClientSocket.
Polevi (2001-12-11 15:01:00) [5]Придется хранить для каждого сокета значение LastActive, периодически опрашивать все сокеты и отключать те, для которых Now-LastActive>SomeInterval
Digitman (2001-12-11 13:27:00) [6]При использовании логики, "прошитой" в TServerSocket такая ситуация не может быть определена сервером, и кл.соединение будет считаться активным неопределенное время.
А вообще такие ситуации могут спокойно обрабатываться, если программировать гнездовые соединения на уровне API. При этом можно будет задать зн-е таймаута, в теч.которого клиент обязан "подать голос" и по истечении которого (при возникновении события, связанного с превышением тайм-аута) сервер просто принудительно откулючает клиента как "зависшего", не подающего "признаки жизни"
| |
