Разработка моделей лицензирования

Для лицензирования защищаемого приложения предполагается использовать две модели:

  1. Ограниченная. Конечное число лицензий для работы на терминальном сервере и в локальной сети.
    Захват лицензий происходит попроцессно.

  2. Терминальная (неограниченная). Неограниченное число лицензий для работы на терминальном сервере.
    Возможность запускать неограниченное число процессов защищаемого приложения на терминальном сервере.

Предполагается, что цена ключей для ограниченной модели будет в разы меньше, чем цена ключа для терминальной модели.
В ограниченной модели формируются ключи на 5, 10, 20 и т. п. лицензий.

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

Вторая модель основана на использовании локального ключа.
В функции GrdSetFindMode передается флаг GrdFMR_Local.

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

Т. е. модель лицензирования зависит от сборки приложения и ключа.

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

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

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

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

Требование: модель лицензирования должна зависеть только от ключа: есть терминальный ключ - работаем в терминале, есть сетевой ключ - работаем в сети и в терминале.

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

Но здесь есть нюанс с поиском ключей.
Для сетевого ключа есть возможность выполнить GrdLogin, как для локального.

Получается, что если задать GrdSetFindMode(GrdFMR_Local | GrdFMR_Remote), а потом GrdLogin,
то можем подключиться к сетевому ключу локально.

Тогда ограничения на максимальное число лицензий, заданные в сетевом ключе, снимаются.

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

Для работы описанных моделей нужны варианты 1 и 4.
Вариант 3 (комбинация GrdFMR_Local + Sign/SP Net) нужно исключить разработчиком самостоятельно:
необходимо запрещать подключение к сетевому ключу с флагом GrdFMR_Local.

Алгоритм поиска и подключения на ключ, обеспечивающей работу моделей лицензирования:

  1. Выполнить GrdSetFindMode(GrdFMR_Local | GrdFMR_Remote);

  2. Сформировать список всех найденных ключей с помощью GrdFind;

  3. Выбрать ключ, с которым необходимо работать.
    Для выбора ключа разработчиком создается стратегия, например, сначала пробовать подключиться к локальным ключам, потом - к сетевым.

  4. Когда ключ выбран и известен его тип (локальный/сетевой), необходимо гарантировать, что тип ключа совпадает с типом модели: на локальный ключ подключаемся локально (по-другому не получится),  на сетевой ключ - удаленно.
    Например, выбрали сетевой ключ, тогда выполнить GrdSetFindMode(GrdFMR_Remote, ...).

  5. Выполнить GrdLogin.

Вопросы:

  1. Прошу оценить корректность вышеизложенных рассуждений. Прошу указать на ошибки, если таковые имеются.

  2. Есть ли возможность задавать ограничения на число одновременных сеансов для локального ключа?
    Может, использовать защищенную ячейку для учета числа подключений (вызовов GrdLogin)?

Re: Разработка моделей лицензирования

Здравствуйте.

Отвечаем на Ваши вопросы:

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

  2. Есть ли возможность задавать ограничения на число одновременных сеансов для локального ключа?
    Может, использовать защищенную ячейку для учета числа подключений (вызовов GrdLogin)?

  1. Тут реализация вызывает некоторые сомнения. У электронных ключей есть дополнительные атрибуты, которые также можно учитывать. К примеру тут описан один из вариантов (который косвенно показывает решение и Вашей задачи) сортировки электронных ключей;

  2. Такими, готовыми, опциями Guardant API не располагает.

Re: Разработка моделей лицензирования

  1. Тут реализация вызывает некоторые сомнения. У электронных ключей есть дополнительные атрибуты, которые также можно учитывать. К примеру тут описан один из вариантов (который косвенно показывает решение и Вашей задачи) сортировки электронных ключей;

  2. Такими, готовыми, опциями Guardant API не располагает.

Благодарю за помощь. Ситуация, описанная тут, совпадает с моей: раскрыта суть моего вопроса.

Re: Разработка моделей лицензирования

2. это возможно реализовать только в случае использования Guardant Code (счетчик держим в самом ключе)

Re: Разработка моделей лицензирования

Александр (Rouse_) Багель пишет:

2. это возможно реализовать только в случае использования Guardant Code (счетчик держим в самом ключе)

Благодарю за ответ.

Думаю, здесь есть некоторая проблема:

1. При использовании сетевого ключа лицензиями управляет сервер GLDS. В случае аварийного завершения защищенного приложения
без выполнения GrdLogout не будет освобождения ранее захваченная лицензия. В крайнем случае можно через веб-интерфейс или перезагрузку GLDS освободить "зависшие" лицензии.

2. Если поместить счетчик захваченных лицензий в ключ Guardant Code, тогда невозможно его сбросить в случае аварийного завершения, кроме как из защищенного приложения. Если несколько копий приложения работает с ключом, то какое из них будет иметь высший приоритет при управлении счетчиком?

Re: Разработка моделей лицензирования

Александр (Rouse_) Багель пишет:

2. это возможно реализовать только в случае использования Guardant Code (счетчик держим в самом ключе)

safelog пишет:
Александр (Rouse_) Багель пишет:

2. это возможно реализовать только в случае использования Guardant Code (счетчик держим в самом ключе)

Благодарю за ответ.

Думаю, здесь есть некоторая проблема:

1. При использовании сетевого ключа лицензиями управляет сервер GLDS. В случае аварийного завершения защищенного приложения
без выполнения GrdLogout не будет освобождения ранее захваченная лицензия. В крайнем случае можно через веб-интерфейс или перезагрузку GLDS освободить "зависшие" лицензии.

2. Если поместить счетчик захваченных лицензий в ключ Guardant Code, тогда невозможно его сбросить в случае аварийного завершения, кроме как из защищенного приложения. Если несколько копий приложения работает с ключом, то какое из них будет иметь высший приоритет при управлении счетчиком?

Тут нужно отметить, что ключи Guardant Code не выпускаются в сетевом варианте и являются исключительно локальными моделями.

Re: Разработка моделей лицензирования

Антон Тихиенко пишет:

Тут нужно отметить, что ключи Guardant Code не выпускаются в сетевом варианте и являются исключительно локальными моделями.

Да, как раз и требуется понять, как с помощью локального ключа (например, Sign) ограничить максимальное число одновременно работающих копий приложения на терминально сервере (см. Guardant Sign на терминальном сервере).

Re: Разработка моделей лицензирования

safelog пишет:

Да, как раз и требуется понять, как с помощью локального ключа (например, Sign) ограничить максимальное число одновременно работающих копий приложения на терминально сервере (см. Guardant Sign на терминальном сервере).

Ответ был дан в указанном топике.

Re: Разработка моделей лицензирования

Антон Тихиенко пишет:

Тут нужно отметить, что ключи Guardant Code не выпускаются в сетевом варианте и являются исключительно локальными моделями.

Опс, да действительно - моя ошибка.