Нужна идея для снятия блокировки пользователя...

@Mz@2 · Регистрация: 22.04.2011

Студворк — интернет-сервис помощи студентам

Здравствуйте, уважаемые!
Извините за откровенный оффтопик, просто я здесь часто бываю и знаю, что здесь бывают люди, которые наверняка смогут ответить. Моя проблема к VB имеет лишь опосредованное отношение (оболочка клиентской части написана на нем, а все что касается работы в сети - WinSock API - написано на C и подключается в виде DLL).

К моему серверу подключаются около 50 клиентов, территориально удаленные до 100 км по схеме СЕРВЕР - МЕСТНАЯ ЛОКАЛЬНАЯ СЕТЬ - DSL <--> DSL - УДАЛЕННАЯ ЛОКАЛЬНАЯ СЕТЬ - КЛИЕНТ. Пользователи на сервере авторизуются и не могут повторно входить с того же или с любого другого компьютера (так нужно по замыслу).

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

Вопрос: "Есть ли возможность на сервере (Сервис на Си + WinSock API) узнать, что данное соединение неработоспособно из-за аварийного завершения работы клиента, кроме как периодическим пингом?".
Таймер на бездействие клиента тоже не очень приемлемое решение, т.к. часто пользователи все рабочее время проводят в системе, даже если никакой активности при этом не проявляют.

Проблема в том, что функция WSAEventSelect на сервере не всегда определяет (или никогда?) событие FD_CLOSE при некорректном завершении работы клиента. В настоящей реализации сервера то, что соединение разрушено сервер узнает только при попытке передать какие-либо данные, но логика его работы такова, что сервер только отвечает клиенту, т.е. самостоятельно, по своей инициативе, ничего клиенту не посылает. Следовательно, если клиент "умер" и сервер не получает никаких запросов он никогда не узнает об этом и не деблокирует повторный вход пользователя.

Я видел пару подобных систем. Там проблема решается вручную: в случае чего пользователь звонит администратору, а тот "убивает" клиента на стороне сервера и клиент снова получает доступ к серверу.

Что-то не вериться, что это единственно приемлемое решение... Хотелось бы написать более или менее не требующий ежедневного обслуживания сервер.

Подкиньте, пожалуйста, идею.

@Alexey · 10.10.2011, 12:48

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

@Mz@2 · 10.10.2011, 13:18 **[ТС]**

Спасибо!
Идея ясна, наверное в этом направлении и надо копать... чтобы обойти следующую ситуацию: Пользователь в системе, нормально себе работает... выходит из своего кабинета... с дугого компа ( он же, или кто-то другой, знающий его пароль - это не редко бывает) добросовестно пытается войти ... и входит в систему прибив предыдущий сеанс, а там несохраненные данные и т.п.!!!

@Alexey · 10.10.2011, 13:28

[underline]сервер проверяет что соединение этого юзера/пк уже было[/underline]

т.е. я подразумевал что открытая сессия привязана к компьютеру/станции, а не только к имени пользователя. или это не так?

@Mz@2 · 10.10.2011, 14:12 **[ТС]**

Ага! То, что нужно!
Хотя я на своем сервере предусматривал такую фишку, как привязка пользователя к определенному IP-адресу, она все время отключена... для удобства пользователей, но все же сервер, и в таком режиме, запоминает адрес подключения и соответственно помнит адрес якобы "живого" подключения.

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

А меня, после бессонной ночи замкнуло на поиски призрачной WinSock API функции, которая решила бы мою проблему.

Не знаю, может быть, такое решение будет иметь какие-то побочные эффекты - надо подумать – но, кажется это полное решение проблемы.
Спасибо огромное!

Может, есть и другие идеи ?

11.10.2011, 01:00

Ну, все серьезные софтины обычно "пинги" кидают - надежнее способа нету...

У меня вот в сети каждому клиенту от сервера раз в 15 секунд "пинг" проскакивает

@Mz@2 · 11.10.2011, 12:04 **[ТС]**

Пинг - это конечно первое, что пришло в голову, но проблема в том, что асинхронные сокеты у меня только на стороне сервера. Таким образом, если сервер "от себя" что-то посылает, клиент выбивается "из колеи", т.к. последний, послав запрос, дожидается ответа и не пытается дальше читать данные до следующего запроса - иначе возможна блокировка, как минимум, до следующего пинга. Еще, если сервер отдал все запрошенные данные, и в этот момент связь нарушился - клиент все равно не сможет обработать уже полученные данные из-за блокировки.
Отсюда вывод - надо переделывать клиент под асинхронный сокет, или использовать многопоточность - в любом случае переделать свой dll.
Это, конечно, даст и другие дополнительные плюсы (и головные боли с синхронизацией тоже), просто такое усовершенствование у меня не входило в число первоочередных задач, и я надеялся, что, возможно, есть другое простое и изящное (или хотя бы стандартное) решение. Например, что-то вроде гипотетического WSAGetConnectState на стороне сервера %).

@Mz@2 · 11.10.2011, 15:11 **[ТС]**

>> to Messir
А что Вы скажете про обратный метод:
Клиенты, каждые 15 сек. посылают "я жив", а сервер, не дождавшись от кого-либо соответсвующего сигнала в течение определеного времени, закрывает сеанс с этим пользователем и прибивает обслуживающий поток...

@Mz@2 · 11.10.2011, 19:37 **[ТС]**

Я пока не попробовал, но, кажись, нашлось то самое "стандартное решение" с помощью "призрачной" функции:
http://www.rsdn.ru/article/net/keep_alive.xml#EFA

@Alexey · 12.10.2011, 00:35

Сообщение от Messir

Ну, все серьезные софтины обычно "пинги" кидают - надежнее способа нету...

У меня вот в сети каждому клиенту от сервера раз в 15 секунд "пинг" проскакивает

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

мой вариант был бы лучше

12.10.2011, 18:42

Сообщение от smalig

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

мой вариант был бы лучше

Эта проблема легко решается разрешением каждому пользователю только одной удаленной сессии.

А в случае, когда от постоянно живого соединения зависит качество работы продукта, и потеря связи - это потеря прибыли компании, то пинги - самое надежное решение

12.10.2011, 18:44

Сообщение от Mz@2

Я пока не попробовал, но, кажись, нашлось то самое "стандартное решение" с помощью "призрачной" функции:
http://www.rsdn.ru/article/net/keep_alive.xml#EFA

Фактически - те же самые пинги, но на уровне системы

@Mz@2 · 12.10.2011, 20:19 **[ТС]**

[quote="Messir"]
Согласен, однако, теперь я могу не спешить с переделкой клиента - ведь, как Вы заметили, все происходит на уровне системы. А добавить одну функцию в код сервера, несомненно, проще.
Я уже испытал свой доработанные сервер в домашних условиях: с помощью двух компов, соединенных "кривым" шнуром. Работает как надо! Завтра попробую в «боевых условиях».

PS: Хотелось бы добавить к тому, что нашел по вышеуказанной ссылке следующее: несмотря на то, что там говорится, что изменения режима касаются только того сокета, который указан в аргументе, нет никакой необходимости применять функцию к каждому подключению, если ее разместить перед accept, т.к. accept как-бы клонирует сокеты по шаблону своего аргумента, и они получаются уже с включенными keep-alive.

Новые блоги и статьи Все статьи Все блоги /
Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а привычная функция main(). . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .
http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь(не выше 3-го порядка) постоянного тока с элементами R, L, C, k(ключ), U, E, J. Программа находит переходные токи и напряжения на элементах схемы классическим методом(1 и 2 з-ны. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47

	Нужна идея для снятия блокировки пользователя... 10.10.2011, 12:43. Показов 1708. Ответов 12 Метки нет (Все метки) Здравствуйте, уважаемые! Извините за откровенный оффтопик, просто я здесь часто бываю и знаю, что здесь бывают люди, которые наверняка смогут ответить. Моя проблема к VB имеет лишь опосредованное отношение (оболочка клиентской части написана на нем, а все что касается работы в сети - WinSock API - написано на C и подключается в виде DLL). К моему серверу подключаются около 50 клиентов, территориально удаленные до 100 км по схеме СЕРВЕР - МЕСТНАЯ ЛОКАЛЬНАЯ СЕТЬ - DSL <--> DSL - УДАЛЕННАЯ ЛОКАЛЬНАЯ СЕТЬ - КЛИЕНТ. Пользователи на сервере авторизуются и не могут повторно входить с того же или с любого другого компьютера (так нужно по замыслу). Проблема вот в чем: иногда на стороне клиента случаются перебои в питании, или еще что-то, и пользователь на сервере остается авторизованным, а потому уже не может войти в систему после перегрузки или устранения проблемы. Вопрос: "Есть ли возможность на сервере (Сервис на Си + WinSock API) узнать, что данное соединение неработоспособно из-за аварийного завершения работы клиента, кроме как периодическим пингом?". Таймер на бездействие клиента тоже не очень приемлемое решение, т.к. часто пользователи все рабочее время проводят в системе, даже если никакой активности при этом не проявляют. Проблема в том, что функция WSAEventSelect на сервере не всегда определяет (или никогда?) событие FD_CLOSE при некорректном завершении работы клиента. В настоящей реализации сервера то, что соединение разрушено сервер узнает только при попытке передать какие-либо данные, но логика его работы такова, что сервер только отвечает клиенту, т.е. самостоятельно, по своей инициативе, ничего клиенту не посылает. Следовательно, если клиент "умер" и сервер не получает никаких запросов он никогда не узнает об этом и не деблокирует повторный вход пользователя. Я видел пару подобных систем. Там проблема решается вручную: в случае чего пользователь звонит администратору, а тот "убивает" клиента на стороне сервера и клиент снова получает доступ к серверу. Что-то не вериться, что это единственно приемлемое решение... Хотелось бы написать более или менее не требующий ежедневного обслуживания сервер. Подкиньте, пожалуйста, идею. 0

@Alexey 0 / 1 / 3 Регистрация: 27.03.2012
	10.10.2011, 12:48
	как вариант. соединение умерло, юзер пытается зайти снова, сервер проверяет что соединение этого юзера/пк уже было, убивает его и создает новое 0

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	10.10.2011, 13:18 [ТС]
	Спасибо! Идея ясна, наверное в этом направлении и надо копать... чтобы обойти следующую ситуацию: Пользователь в системе, нормально себе работает... выходит из своего кабинета... с дугого компа ( он же, или кто-то другой, знающий его пароль - это не редко бывает) добросовестно пытается войти ... и входит в систему прибив предыдущий сеанс, а там несохраненные данные и т.п.!!! 0

@Alexey 0 / 1 / 3 Регистрация: 27.03.2012
	10.10.2011, 13:28
	[underline]сервер проверяет что соединение этого юзера/пк уже было[/underline] т.е. я подразумевал что открытая сессия привязана к компьютеру/станции, а не только к имени пользователя. или это не так? 0

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	10.10.2011, 14:12 [ТС]
	Ага! То, что нужно! Хотя я на своем сервере предусматривал такую фишку, как привязка пользователя к определенному IP-адресу, она все время отключена... для удобства пользователей, но все же сервер, и в таком режиме, запоминает адрес подключения и соответственно помнит адрес якобы "живого" подключения. И Ваш метод решит проблему входа с другого компа сразу (не тот адрес, с которого застрял пользователь), а если пользователь пытается войти с того же адреса - то поступаем так, как Вы предложили в первом ответе, не забыв поставить мютекс на клиент, чтобы с одной машины можно было запускать не более одного клиента (у меня так уже и было) т.к. в этом случае попытка повторного входа с "застрявшего" адреса означает перезагрузку компа клиента, или как минимум снятие процесса клиента. А меня, после бессонной ночи замкнуло на поиски призрачной WinSock API функции, которая решила бы мою проблему. Не знаю, может быть, такое решение будет иметь какие-то побочные эффекты - надо подумать – но, кажется это полное решение проблемы. Спасибо огромное! Может, есть и другие идеи ? 0

Messir
	11.10.2011, 01:00
	Ну, все серьезные софтины обычно "пинги" кидают - надежнее способа нету... У меня вот в сети каждому клиенту от сервера раз в 15 секунд "пинг" проскакивает

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	11.10.2011, 12:04 [ТС]
	Пинг - это конечно первое, что пришло в голову, но проблема в том, что асинхронные сокеты у меня только на стороне сервера. Таким образом, если сервер "от себя" что-то посылает, клиент выбивается "из колеи", т.к. последний, послав запрос, дожидается ответа и не пытается дальше читать данные до следующего запроса - иначе возможна блокировка, как минимум, до следующего пинга. Еще, если сервер отдал все запрошенные данные, и в этот момент связь нарушился - клиент все равно не сможет обработать уже полученные данные из-за блокировки. Отсюда вывод - надо переделывать клиент под асинхронный сокет, или использовать многопоточность - в любом случае переделать свой dll. Это, конечно, даст и другие дополнительные плюсы (и головные боли с синхронизацией тоже), просто такое усовершенствование у меня не входило в число первоочередных задач, и я надеялся, что, возможно, есть другое простое и изящное (или хотя бы стандартное) решение. Например, что-то вроде гипотетического WSAGetConnectState на стороне сервера %). 0

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	11.10.2011, 15:11 [ТС]
	>> to Messir А что Вы скажете про обратный метод: Клиенты, каждые 15 сек. посылают "я жив", а сервер, не дождавшись от кого-либо соответсвующего сигнала в течение определеного времени, закрывает сеанс с этим пользователем и прибивает обслуживающий поток... 0

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	11.10.2011, 19:37 [ТС]
	Я пока не попробовал, но, кажись, нашлось то самое "стандартное решение" с помощью "призрачной" функции: http://www.rsdn.ru/article/net/keep_alive.xml#EFA 0

@Mz@2 1 / 1 / 0 Регистрация: 22.04.2011 Сообщений: 47
	12.10.2011, 20:19 [ТС]
	[quote="Messir"] Согласен, однако, теперь я могу не спешить с переделкой клиента - ведь, как Вы заметили, все происходит на уровне системы. А добавить одну функцию в код сервера, несомненно, проще. Я уже испытал свой доработанные сервер в домашних условиях: с помощью двух компов, соединенных "кривым" шнуром. Работает как надо! Завтра попробую в «боевых условиях». PS: Хотелось бы добавить к тому, что нашел по вышеуказанной ссылке следующее: несмотря на то, что там говорится, что изменения режима касаются только того сокета, который указан в аргументе, нет никакой необходимости применять функцию к каждому подключению, если ее разместить перед accept, т.к. accept как-бы клонирует сокеты по шаблону своего аргумента, и они получаются уже с включенными keep-alive. 0