регистрация пользовательских логинов с целью сообщения о том, что клиент превысил количество лицензий

Question

Я ведущий разработчик коммерческого приложения для Windows (c #). Новым требованием является отслеживание клиентов, злоупотребляющих лицензией.

Например: скажем, клиент покупает лицензионное соглашение на 10 пользователей, то есть 10 одновременных пользователей.

Мне нужно иметь возможность сообщать, оглядываясь на историю, все время, когда в клиент входило более 10 пользователей одновременно.

У меня уже есть таблица User со столбцами: userid (первичный ключ), pw, lastLogin, lastLogout.

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

LogId, UserId, LoginDateTime, LogoutDateTime

... и тогда у меня будет история о каждом входе / выходе пользователя из приложения ...

но я не уверен, будет ли такой дизайн таблицы пригоден для эффективных вычислений для составления отчетов ... использую ли я SQL или c # для выполнения вычислений, для меня не имеет значения, если это достаточно быстро ...

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

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

Answer 1

Думайте о начале и завершении сессий как о событиях, которые необходимо записать. Вы создаете одну таблицу для записи этих событий.

Таким образом, сеанс, который начинается и заканчивается, будет иметь две записи в таблице - одну для начала сеанса и одну для конца сеанса. Вы только добавляете записи в таблицу, но не изменяете предыдущие записи. Теперь таблица может очень просто отслеживать количество открытых сеансов, добавляя поле «счетчик сеансов» к записи, которое увеличивается от значения счетчика сеансов предыдущей записи, когда происходит событие начала сеанса, и уменьшается, когда происходит событие окончания сеанса.

Столбец «количество сеансов» теперь дает нам кусочно-непрерывную функцию во времени количества одновременных сеансов.

Пример данных:

    SessionId  EventType  .... your session data here ... SessionCount   
1.     1         Login         ................                 1
2.     2         Login         ................                 2
3.     3         Login         ................                 3
4.     1         Logout        ................                 2
5.     4         Login         ................                 3
6.     4         Logout        ................                 2
7.     2         Logout        ................                 1
8.     3         Logout        ................                 0
9.     5         Login         ................                 1
10.    6         Login         ................                 2

О чем беспокоиться:

1. Вы должны убедиться, что вы связываете события начала / окончания, поэтому в случае любого сбоя события окончания сеанса все равно должны быть сгенерированы.
2. Вам нужен стол для защиты от подделки? Если так, у меня есть метод для этого также.

РЕДАКТИРОВАТЬ: обратите внимание, что там, где я поместил «ваши данные сеанса здесь», я действительно имел в виду «данные вашего сеанса здесь». Информация, такая как отметка времени, будет здесь. Другая таблица должна использоваться для отслеживания информации о сеансе, общей для обоих событий, такой как личность пользователя, которому принадлежит сеанс (используйте один и тот же ключ SessionId для обеих таблиц).

Answer 2

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

Затем вы можете создать триггер при вставке (и, возможно, удалить), и вы можете войти оттуда на основе количества сеансов. Если вы также регистрируете удаление, у вас есть представление о том, сколько времени они использовали чрезмерное количество пользователей.

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

Answer 3

Примечание. Эта проблема решалась ранее. Наилучший вариант, который я видел, состоит в том, чтобы поддерживать MRU-стек активности пользователей незарегистрированными пользователями (в данном случае глубина 10) и получен из транзакций базы данных - SELECT TOP 10 DISTINCT код пользователя из atable WHERE (последний тип транзакции был 'выходить из системы') ЗАКАЗАТЬ по отметке времени DESC. Как только кто-то получает доступ к системе, которая не входит в число последних 10, у вас есть два варианта. Вы разрешаете им входить в систему и повышать статус самого старого до выхода из системы (что создает трудности, но позволяет им продолжать свою работу); или вы заставляете их ждать, пока один из лучших 10 явно не выйдет из системы. Иногда пользователь делает выбор. Иногда это требует администратора. Но это различие в политике.

Затем вы выставляете счет за каждый вход в систему (по первой схеме) или просто устанавливаете лимит (по второй схеме).

Answer 4

Я бы с осторожностью реализовал что-то вроде проверки лицензии таким образом, потому что (как уже отмечалось в ответ Даниэля , вы не получите событие выхода из системы в случае сбоя вашего приложения или, возможно, даже если пользователь выйдет это определенным образом (Завершить процесс из диспетчера задач, ALT + F4, вместо того, чтобы проходить через File | Exit и т. д.).

Таким образом, вы можете предположительно иметь растущую долю мертвых сессий, поскольку пользователи используют приложение. Не только вы можете получить неправильные данные и впечатления о своих пользователях, но, что более важно, они будут разочарованы получением предупреждений, которых они не заслуживают. И если вы попытаетесь сказать им, что они нарушают лицензию, а на самом деле это не так, они могут стать весьма оскорбленными. Хороший способ потерять клиентов.

Я бы сказал, что разумная схема проверки лицензии требует, чтобы центральный сервер находился вне контроля клиента, и чтобы клиент имел доступ в Интернет. Это может быть что-то вроде этого:

1. при запуске приложения, программы информирует сервер лицензий о новом сессии;
2. во время работы приложения, программы периодически (скажем, 1x 5 минут или итак) посылает сигнал статуса в лицензию сервер;
3. при выходе из программы обычно отправляет сигнал окончания сеанса в лицензию сервер;
4. если сигнал состояния не получен в 10 минут от программы, сеанс считается прекращенным сервером лицензий в любом случае.

Answer 5

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

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

Answer 6

Проблема с наличием структуры таблицы (LogId, UserId, LoginDateTime, LogoutDateTime) состоит в том, что становится сложно агрегировать - запросы, чтобы увидеть всех, кто использует систему в указанное время, просты, но получить количество пользователей вообще времена тяжелые.

Один из возможных подходов состоит в том, чтобы немного денормализовать данные и записать единицы измерения вместо диапазонов. Вы можете отслеживать использование в 30-минутных блоках с помощью структуры таблицы (UserId, BlockDateTime).

Если BettyR использовала систему с 10:05 до 11:45, создайте в вашей таблице четыре записи:

BettyR, 10:00am
BettyR, 10:30am
BettyR, 11:00am
BettyR, 11:30am

Затем можно использовать обычный запрос SQL с предложением group by, чтобы найти число отдельных пользователей, которые использовали систему в течение каждого получасового периода.

select ...
from UsageBlocks
group by BlockDateTime
having count(*) > 10

В зависимости от ваших требований вы можете выполнить более глубокий анализ этих конкретных периодов времени с помощью приложения для составления отчетов.