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

Секретного способа нет, таблица LMS должна быть всегда доступна для чтения.

Так следует делать всегда, для всех сетевых ключей.

Да.

Я теперь понимаю это так:

Современный сервер (видимо, начиная с 6 версии) берет ограничитель лицензий из LMS. Ячейку 38SAM он вообще не рассматривает. Таким образом, теперь, чтобы считать истинный ограничитель лицензий, придется читать LMS.
В ключах Stealth III/Sign LMS-это защищенная ячейка, поэтому для ее чтения можно использовать Grd_PIRead(). Это если для LMS вообще разрешено чтение. Если разрешено с паролем, потребуется пароль. Если чтение запрещено (в моем случае, так и есть), то, похоже, облом. Правда, сервер как-то умудряется считывать ограничитель лицензии, так что, какой-то секретный способ все-таки есть. Да, еще есть тонкости, что нужно еще знать номер защищенной ячейки LMS, что ограничитель лицензий может быть одно- или двухбайтовым.
В ключах Stealth II LMS-это область памяти. И если она не защищена от чтения, то ее тоже можно прочитать.

Таким образом, считать ограничитель лицензий из ключа - нетривиальная операция, которая, к тому же может закончиться неудачей. Видимо, имеет смысл при программировании ключа записывать ограничитель лицензий еще и в 38SAM. По крайней мере GrdUtil так и поступает. Ячейка 38SAM никакой роли уже не играет, но ее содержимое легко прочитать, значительно легче, чем LMS. Наверное, именно это имеется в виду под фразой "это поле нужно только для утилиты диагностики"?

Все верно?

А что представляют собой поля структуры FindInfo byMaxNetRes и wRealNetRes?
Ну, byMaxNetRes- это, вероятно, просто содержимое 19SAM?
А wRealNetRes? Это содержимое 38SAM, или же значение, считанное из LMS?

А еще в таблице лицензий есть ограничитель. Как его учесть? Он, кстати, недоступен для чтения.

Информация тут должна быть полезной для этого вопроса.

В таком случае, после логина, можно только читать SAM 19 (максимальный  ресурс) и SAM 38 (реальный сетевой ресурс).

А еще в таблице лицензий есть ограничитель. Как его учесть? Он, кстати, недоступен для чтения.

Но нужнее узнать количество лицензий, которое данный ключ может выдать пользователю (с учетом ограничений в 38SAM и LMS)

В таком случае, после логина, можно только читать SAM 19 (максимальный  ресурс) и SAM 38 (реальный сетевой ресурс).

Тут можно запросить сервер через http (web-монитор) и распарсить ответ.

Но нужнее узнать количество лицензий, которое данный ключ может выдать пользователю (с учетом ограничений в 38SAM и LMS)

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

Реальное количество лицензий в сетевом ключе можно узнать из FindInfo.wRealNetRes. А точнее, как мы недавно выяснили, нужно брать минимум из FindInfo.wMaxNetRes и FindInfo.wRealNetRes. Структуру FindInfo мы получаем при поиске ключа, до Логина. После Логина нам становится доступна функция GrdGetInfo(), но она, вроде, не готова сообщить количество лицензий в ключе.

Можно ли как-то узнать реальное количество лицензий на текущем, залогиненном ключе?

Итак, рекомендации для пользователей по переходу на новый сервер:

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

Правильно?

Да.

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

Правильно?

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

Конфигурационный файл именно пустой, нет никаких записей, или в таком файле не заполняются нужные параметры (UUID, HOST_ID, IP_NAME)?

Насколько я знаю, второе.

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

Нормально ли находится сетевой электронный ключ, если конфигурационный файл gnclient.ini выгружается из web-интерфейса сервера сетевых ключей Guardant Net?

Вроде, да.
Хорошо бы, чтоб новый сервер вытягивал правильные настройки из старого gnclient.ini.
Или, может, бэкапил бы старый gnclient.ini.

Судя по всему, сервер сетевых ключей в данном случае работает нормально, а механизм автоматического заполнения и формирования конфигурационного файла gnclient.ini, реализованный в Guardant API и автозащите, не всегда может заполнить конфигурационный файл.

Ваши замечания переданы нашим разработчикам, а имитировать бэкапирование "старого" gnclient.ini, при помощи Guardant API v.7, можно задав собственную директорию расположения нового конфигурационного файла, при помощи функции GrdStartupEх.

Конфигурационный файл именно пустой, нет никаких записей, или в таком файле не заполняются нужные параметры (UUID, HOST_ID, IP_NAME)?

Насколько я знаю, второе.

Вроде, да.
Хорошо бы, чтоб новый сервер вытягивал правильные настройки из старого gnclient.ini.
Или, может, бэкапил бы старый gnclient.ini.

Раньше наше приложение защищалось Guardant API 6, использовался старый сервер 5.5, и у пользователей были настроенные для их среды файлы gnclient.ini. Наша программа установки-обновления никак не затрагивает gnclient.ini.
Новая версия приложения использует Guardant API 7. Пользователи обновляют программу, устанавливают новый седьмой сервер, gnclient.ini остается прежним. При запуске приложения ключ не находится, а старый gnclient.ini исчезает и заменяется на новый, пустой.

Конфигурационный файл именно пустой, нет никаких записей, или в таком файле не заполняются нужные параметры (UUID, HOST_ID, IP_NAME)?

Нормально ли находится сетевой электронный ключ, если конфигурационный файл gnclient.ini выгружается из web-интерфейса сервера сетевых ключей Guardant Net?

А как быть с файлом gnclient.ini при переходе с 5-го сервера на 7 (API тоже изменилось с 6 на 7)?
Клиенты жалуются, что старый, работавший gnclient.ini перезаписывается новым, пустым и неработающим.

Тут не совсем понятно, в составе дистрибутива приложения, защищенного при помощи Guardant API 7 версии, поставляется "старый" конфигурационный файл gnclient.ini?