Конференция "Прочее" » Подскажите идею отслеживания отвалившегося юзера
 
  • ВладОшин © (01.11.18 16:23) [0]
    Приветствую!

    Думаю..Как бы начать.. С данных на экране, над которыми подзавис

    -- table LOG
    --[PC] [varchar](50)
    --[User] [varchar](50)
    --[DT] datetime
    --[ID] [int]

    данные:
    T7-737 q2627 08:59:25 3951473
    T7-344 q2627 09:02:29 3951516
    T7-737 q2627 11:35:34 3952084  
    T7-737 q2627 14:36:36 3952819

    расшифровка:
    Юзер с компьютера T7-737 залогинился и отошел
    Вернулся, залогинился с T7-344, тут вспомнил, что уже залогинивался. Бросил открытой и залогиненной программу
    Вернулся на T7-737, работал весь день (залогинивался/разлогинивался)

    ID - ссылка на таблицу Seance ( LOG.ID -> Сеанс.ID )
    --[ID] [int]
    --[TimeBegin] [datetime]
    --[TimeEnd] [datetime]
    --[CloseReason] [int]

    При залогировании в программу, добавляется строка в Seance : TimeBegin = TimeEnd = getdate(now), CloseReason = 0, ID - out (IDout)
    Пока программа залогинена, она каждую минуту делает TimeEnd = getdate where ID = IDout
    При корректном выходе TimeEnd = getdate,  CloseReason = [1/2/3] where  ID =IDout
    (соответственно, если CloseReason=0, и TimeEnd + 2минуты < getdate, юзер отвалился/вышел некорректно и т.п.)

    в указанном случае с юзером q2627, получается, что он работал на компе T7-344 весь день, равно как и на T7-737
    по косвенным признакам - просмотр лога - выяснилось, что просто не разлогинился на одном из них.

    Хотел задать вопрос
    Как сделать, что бы как-то закрывать запись с компа, где юзера нет физическию?
    вот в этом месте "Пока программа залогинена, каждую минуту делает TimeEnd = getdate where ID = IDout" надо игнорировать такие записи
    для этого можно что-то куда-то записать, таблицу новую создать что-то еще, все что угодно.
    Подскажите идею, в общем
  • ВладОшин © (01.11.18 16:36) [1]
    Да, главное. Крайне не хотелось бы выдавать окошки с вопросами
    Так то можно было посмотреть есть ли у него сеанс с TimeEnd свежим и CloseReason =0 и сказать пусть вернется на тот комп, или выйдет там, или подтвердит что теперь с этого только будет работать

    просто только такая идея и приходит - диалог
  • xayam © (01.11.18 21:46) [2]
    может активность мыши/клавиатуры отслеживать
  • Читатель © (02.11.18 07:31) [3]
    Задача по тому работает за компом или нет - невыполнимая. Я уже как-то доказывал это, но точно не помню. Когда я учился, мы сидели за компами и надо было лабухи делать. Или еще что-то не помню. И ко мне подходит студент посмотреть что я делаю. А я в Total Comander (или подобная прога, не помню давно было) двигаю стрелками туда-сюда. Он засмеялся. Если сделать систему отслеживания, она посчитает что я работал. Такой невыполнимый бред..

    Мало того, что даже лог - зарегился/вышел из программы тоже не всегда адекватно отрабатывать. К примеру, зашел человек в программу, коннектится на базу, в логе прописывается коннект с датой. Через 5 минут выключают свет, электричество. Записи о дисконнекте не будет. И все, инфа уже недостоверная. А разные вылеты и зависания могут быть и не редкими...
  • virex(home) © (02.11.18 08:18) [4]

    > Как сделать, что бы как-то закрывать запись с компа, где
    > юзера нет физическию?

    отслеживать "физическое присутствие"
    задействовать датчики: вэбкамера, микрофон, инфракрасный датчик, тепловизор
  • Читатель © (02.11.18 09:24) [5]
    Ага, чипировать сотрудника, и если он надолго отлучается от компа включать электрошокер...
  • ВладОшин © (02.11.18 09:46) [6]

    > активность мыши/клавиатуры отслеживать

    отслеживаю..

    Условия несколько усложнены. Почему юзер работал за обоими компами - потому что он цепляется удаленно в сеансе rdp. Он открыл один сеанс с одним PC, потом открыл с другим PC, а потом вернулся в окно первого PC. Второй не закрыл, а свернул/задвинул на второй план.
    В обоих есть активность, RDP-API позволяет поймать мышь/клаву, если окно сессии не закрыто. Оба открыты - в обоих есть in/out
    Мышь и клава также проверяется в программе, так вот в одном случае они есть, а в другом нет. Хорошо, можно через 5 минут бездействия, допустим, выбить юзера. Но он мог читать просто что-то с экрана. Понятно, что через час нельзя читать ничего, что бы не двинуть ничем. Причем, не в сессии rdp - тут нормально все, а в самой программе

    Как вариант, при пролонгации сеанса (которая каждую минуту идет, поинтересоваться вопросом, а ты где вообще сидишь, почему у тебя 2 сеанса) В какой программе подтвердит, тот сеанс и продлевается, а со второго компа - ежеминутные пролонгации прекращаются


    > Читатель

    Свет/повисло - ошибка в минуту, прекратит обновляться TimeEnd
    Второй момент, не преследуется задача доказать бездельника. Преследуется задача вычеркнуть левый сеанс. Пусть он в одном хоть авто-мышкой-водилку поставит и обманет всех. Но что бы это можно сделать только с одного места


    > virex(home)


    Смешно. Но не поможет все равно, потому что это удаленка.. Физически он сидит за своим домашним компом в Бердичевске(надеюсь, этот город существует и он российский)), все по честному.
  • ВладОшин © (02.11.18 10:04) [7]
    В общем, без вопроса не обойтись
    При пролонгации сеанса, надо проверить, нет ли сеансов, отличных менее чем на минуту, которые CloseReason = 0. Запомнить такие.
    При следующей пролонгации проверить, не изменился ли их TimeEnd. Если так, то их тоже пролонгируют. Значит, 2 сеанса параллельно идут.
    И тут программа задает вопрос, "а ты тут?". Если подтверждает, то остальные сеансы закрываются. CloseReason <> 0
    И каждая программа пролонгирует только тот свой сеанс, который CloseReason = 0. Т.е. с другого компьютера пролонгация ничего не поменяет, ее сеанс уже CloseReason <> 0

    соотв. rowcount апдейта =0, соотв. авторазлогирование.

    спасибо ) Так и сделаю..
    Но если есть еще идеи - буду рад, перепишу на них, если лучше будут
  • Читатель © (02.11.18 10:17) [8]
    Чтобы вычислить левый сеанс без опроса пользователей не обойтись.
    Отслеживание что они там тыкают и зачем ни о чем не скажет. Эта проблема организационная, а не программная.
  • Читатель © (02.11.18 10:27) [9]
    Может я не так все понял.. Но скорее надо искать другие пути, а не решать нерешаемое.
    Можно например не давать залогиниться два раза одному юзеру - это и сделать легче. Чем выдавать окно "а ты тут" по таймеру, когда он вышел задержался в туалете дольше обычного..
    И вообще, непонятно чему мешают "лишние" сессии. Ни какая база, ни какая архитектура не указанна. Непонятно совсем о чем речь..
  • Читатель © (02.11.18 10:29) [10]
    А когда "умная" система вдруг решит закрыть сессию которая оказалась на самом деле нужной, можно узнать многоэтажной нецензурной лексики от пользователя в лучшем случае..
  • KSergey © (02.11.18 10:47) [11]
    Казалось бы, проще всего не давать логиниться, если уже залогинен.
    Тут, правда, возникает нюанс, когда сеанс завершился некорректно и не отловили отлогиневание, но это надо просто порешать, например пингами того сеанса, который считается залогиненым; если за таймаут не получили ответ - считаем, что там было отлогинивание и пускаем в новый сеанс
  • ухты © (02.11.18 11:01) [12]

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

    А что со спящими компами делать? Короче надо мировой опыт смотреть )
  • ВладОшин © (02.11.18 11:17) [13]
    Ни какая база, ни какая архитектура - это важно?
    Признаюсь, умолчал о том, что юзер удаленно заходит по rdp на компы в сетиA с которых работает.
    База mssql, в сети А - толстый клиент

    Да, можно на открытие сеанса поставить..

    Не давать второй раз логинится не правильно. Юзер намерено менять может удаленку. Просто не выйти по старому месту. Там его сеанс так же продлевается таймером.
    Можно при логине спросить, что вот есть сеанс, 30 сек назад, не закрытый. Закроем?

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

    >>когда сеанс завершился некорректно и не отловили отлогиневание
    его время менее минуты от getdate.
    В принципе, Можно также при логине спросить, что вот есть сеанс, 30 сек назад, не закрытый. Закроем?
    и т.д.
  • ВладОшин © (02.11.18 11:29) [14]
    во!
    а можно при логине ничего не спрашивать..
    Закрывать открытые сеансы сразу, а они при пролонгации по таймеру сделают авторазлогирование. Или, если там повисло/оборвалось, то и ладно. Они закрытые уже
  • Читатель © (02.11.18 11:45) [15]
    Правильней наверно типа такого сообщения: "Нельзя зарегистрироваться в систему, т.к. уже есть отрытый сеанс. Закройте активные сеансы, чтобы зарегистрироваться вновь". Чтобы юзвер закрыл лишний сеанс [b]сам[/b]
  • KSergey © (02.11.18 11:51) [16]
    > ВладОшин ©   (02.11.18 11:29) [14]
    > а можно при логине ничего не спрашивать..
    > Закрывать открытые сеансы сразу,

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

    Я описал рабочую схему, применяемую в одном ПО (ForService), причем это лучшее в данном вопросе по разумной продуманности, что я лично видел. Уже учтены многие нюансы и истории из реальной жизни.

    Но можно придумывать всё заново, да. Самостоятельно допиливать (а иногда и так бросать, ибо "я знаю как правильно"). Зачем только, вот бы понять. Меня этот вопрос мучает на работе уже 5-й год.

    Могу в деталях описать то, как сделано там (интерфейсно, как внутри - не знаю). На мой взгляд - лучшее по сумме ситуаций, что я видел для решения указанной задачи.
  • KSergey © (02.11.18 11:52) [17]
    > Читатель ©   (02.11.18 11:45) [15]
    > Правильней наверно типа такого сообщения: "Нельзя зарегистрироваться в систему, т.к. уже есть отрытый сеанс. Закройте активные
    > сеансы, чтобы зарегистрироваться вновь".

    Вот, типичный программистский подход. В любой неудобной программисту ситуации послать пользователя в императивном наклонении.
    Так и живём.
  • Sha © (02.11.18 12:36) [18]
    > Могу в деталях описать то, как сделано там (интерфейсно, как внутри - не знаю).
    > На мой взгляд - лучшее по сумме ситуаций, что я видел для решения указанной задачи.

    было бы интересно
  • Читатель © (02.11.18 12:48) [19]

    > Вот, типичный программистский подход. В любой неудобной
    > программисту ситуации послать пользователя в императивном
    > наклонении.
    > Так и живём.

    Ну так юзеры потом начнут ныть - а что он закрылся, я его не закрывал.
    И поди разберись кто виноват, прога, сам крашнулся или что еще. Я уже испил сполна чашу бед в связи с автоматическими, якобы помогающими действиями имеющие сомнительный в проектном плане характер. Вот сейчас с одной прогой такой разбираюсь...
 
Конференция "Прочее" » Подскажите идею отслеживания отвалившегося юзера
Есть новые Нет новых   [118456   +51][b:0][p:0.001]