Загрузка процессора и задержки до некоторой степени связаны с системой защиты ключа: Guardant API защищено псевдокодом Guardant, он замедляет код примерно на 3 порядка, но аналогично затрудняет анализ и реверс-инжиниринг.

Указанное поведение воспроизводится и для Windows XP SP3. Информация передана разработчикам.

Уточните, пожалуйста, каковы максимальные задержки наблюдаются при поиске ключа защищенным приложением? Также приложите содержимое конфигурационного файла (gnclient.ini) "проблемного" защищенного приложения.

Сейчас, при переходе на сервер 6.1.0.370, заморочки с подсоединением (длинные таймауты, отсутствие коннекта) к ключу исчезли.
Но уже заметили, что при коннекте клиентского приложения с другого компьютера к машине, на которой стоит сервер ключей 6.1,
происходит кратковременная 1-2сек загрузка процессора на сервере ключей до 50% (проц AMD 2.3ГГц, памяти 2Гб),
мышь PS/2 подвисает (в "событиях Windows" пишется, что "Переполнение кольцевого буфера для поступающих данных мыши").

И еще один более критичный момент: запуск GLDS.exe, как сервиса, работает не совсем корректно на WinXP SP2.
1) при включении компьютера сервис стартует как надо, автоматом (в настройке службы указан тип запуска "авто").
2) если же зайти пользователем, затем выйти ("завершить сеанс") и снова зайти, сервер обнаруживается в выключенном состоянии.
(в "событиях Windows" пишется, что "Служба "Guardant dongle licensing system" перешла в состояние Остановлена).
Вот с этим что-то нужно делать, при входе-выходе пользователей на сервере служба не должна рестартовать или останавливаться.

При поиске сетевого ключа действительно допустимы некоторые задержки из-за того, что защищенное приложение посылает широковещательный запрос внутри ЛВС и ожидает ответа от сервера сетевых ключей Guardant Net.

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

Также приложите содержимое конфигурационного файла (gnclient.ini) "проблемного" защищенного приложения.

Про "(не забудьте установить GrdFM_Type!!)" читал в начале топика, но не понял тогда, куда прописать.
Сейчас все работает. Но... Проверка идет медленно, т.к. последовательно производится поиск разных ключей
с заметной задержкой (при отсутствии искомого ключа).
"Хоть три версии делай, чтобы без задержки проверяли локальный и 2 вида сетевых ключей..."

> Что же касается поиска и проверки сетевого ключа

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

P.S. Переход на сервер 6.1.0.370 проблему с нестабильностью подключения к лок.ключу вроде как устранил :)

Для того, чтобы при поиске учитывались флаги типов ключей (GrdDT_LAN, GrdDT_Time, GrdDT_GSII64 и др.) нужно в качестве параметра dwFlags, функции GrdSetFindMode, передавать соответствующее значение - GrdFM_Type - разрешающее учитывать при поиске параметр dwType.

Таким образом, вызов функции GrdSetFindMode, должен производится со следующими параметрами:
( hGrd, GrdFMR_Local, GrdFM_NProg + GrdFM_Type, dwProgV-CryptPG, 0, 0, 0, 0, GrdDT_LAN, GrdFMM_Sign, GrdFMI_USB ).

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

Для того чтобы однозначно исключить влияние подобных факторов следует проводить тестирование по следующему алгоритму:

1) Взять два ПК полностью отключенных от ЛВС;
2) На одном установить драйвер, подсоединить ключ и запустить сервер Guardant Net, а на другом установить защищенное приложение;
3) Соединить данные две машины, прямым (без использования хабов или маршрутизаторов), кроссовым патчкордом;
4) Вручную настроить стандартную (вида: 192.168.x.x) подсеть между данными компьютерами;
5) Выключить абсолютно все средства проактивной защиты запущенные на обоих компьютерах;
6) Запустить защищенное приложение на ПК-клиенте.

Обращение к ключу делаю со следующими параметрами:
nRet =  GrdSetFindMode( hGrd, GrdFMR_Local, GrdFM_NProg, dwProgV-CryptPG, 0, 0, 0, 0, GrdDT_LAN, GrdFMM_Sign, GrdFMI_USB );
dwID = 0;
nRet = GrdFind( hGrd, GrdF_First, &dwID, &GrdFindInfo );

Пока решил данную проблему проверкой флага GrdDT_LAN уже у найденного локального ключа и т.п. Тут все работает.

P.S. Нестабильно проходит проверка на наличие сетевого ключа. То находит его, то нет.
На сервере - таймаут блокировки ключа поставил в 5 сек, отправки и получения данных по 30 сек.
На клиенте - поднял значения RECONNECT_TRY_NUMBER = 5, TO_SEARCH = 10, TO_RECEIVE = 30.
Не помогло.

Если бы существовал аналог флага GrdDT_LAN, но с признаком локального ключа, то только настройкой через GrdSetFindMode мы бы отсекли возможность логина к NET-ключу, которая нежелательна в нашем случае.

Такой флаг сильно осложнил бы использование флагов GrdDT именно потому, что любой сетевой ключ как подмножество включает в себя все возможности локального. Т.е. гипотетический флаг GrdDT_LOCAL обозначал бы не какую то возможность ключа, а ее отсутствие (GrdDT_LAN). Это противоречит смыслу параметра флагов.

Т.е. если вы хотите найти все ключи "сетевые но используемые локально" то это можно достичь только описанной выше комбинацией флагов GrdDT и GrdFMR. Объединить эти флаги в одном параметре было бы очень вредно по многим причинам.

Наличие данного флага не принесло бы никакой практической пользы и носило бы явно дублирующий характер т.к. этот функционал выполняют флаги GrdFMR_XXX

Вот не понял этого утверждения, тогда объясните, почему при использовании в маске единственного флага GrdFMR_Local возможен к ключу типа NET, если он установлен на данном компьютере? Собственно это и есть источник проблем. Если бы этого не было, то никакие схемы не были бы нужны.

Данную схему легко самостоятельно модифицировать любым нужным образом.

Например, так -

1) Выполняем блок инициализации (GrStartup(GrdFMR_Local+GrdFMR_Remote)), GrdCreateHandle, GrdSetAccessCode) - т. е. активируем и локальное и сетевое GrdAPI

2) Вызываем функцию GrdSetFindMode с обязательными параметрами dwRemoteMode=GrdFMR_Local и dwType=GrdDT_LAN (не забудьте установить GrdFM_Type!!) - т. е. собираемся искать только сетевые ключи - и только локально. После этого вызываем GrdFind для поиска.

3) Если  GrdFind на шаге 2) вернул Ок, то перед нами гарантировано сетевой ключ (метка GrdDT_LAN есть только у сетевых), в этом случае мы:
3а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Remote -  т. е. активируем только сетевое GrdAPI, заставляя приложение искать ключ только через сервер сетевого ключа.
3б) Вызываем GrdLogin. Если успех - работаем, если неудача - требуем запустить сервер ключа и работаем

4) Если шаг 2) вернул 1 (ключ не найден), то у нас две возможности - ключ локальный и ключа на этом компьютере нет. Поэтому мы:
4а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Local - т. е. активируем только локальное GrdAPI
4б) Вызываем GrdLogin. Если успех - работаем с локальным ключом, если неудача - ключа вообще нет, либо есть сетевой ключ, но на другой машине

5) Если шаг 4) вернул 1 (ключ не найден), то ищем сетевой ключ по сети:
5а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Remote -  т. е. активируем только сетевое GrdAPI, заставляя приложение искать ключ только через сервер сетевого ключа.
5б) Вызываем GrdLogin. Если успех - работаем, если неудача - требуем запустить сервер ключа и работаем

Вопрос: возможно ли запретить использование NET-ключа как локального, используя другие флаги в GrdSetFindMode?  (Была надежда на флаг типа ключа GrdDT_LAN, но обратного к нему нет и эксперименты были неудачными)