Объект %session создается автоматически csp демоном.

Кукисы можно отключить в редакторе конфигурации->CSP->Приложения->Использовать Cookies для сеанса.

Количество процессов обслуживающий csp запросы не обязательно совпадает с количеством подключений. IMXO

По поводу использования лицензий в данном контексте (ссылку не нашел дам текст)
Bill McCormick
Механизм работы лицензий с CSP

Недавно в новостной конференции InterSystems обсуждались проблемы с
лицензионной политикой при использовании технологии CSP (Cache Server Pages).
После длительных дебатов, вопросов и ответов очень интересное письмо написал
Бил Маккормик (Bill McCormick, Web/Objects Support Manager, InterSystems
Corporation), в котором подытожил все проблемы. Приводим перевод в некотором
сокращении, думаем, что рекомендации Била будут полезны, так как в документации
пока на этот счет очень мало советов.

Начнем с начала.

Лицензирование CSP отличается от лицензирования других подключений к Cache.
Если мы устанавливаем соединение с ODBC, JDBC, Java, ActiveX, Telnet, любой тип
соединения, мы получаем IP адрес клиента, передаем его серверу и связываем его
с лицензией.

Мы позволяем организовать до 12 таких соединений на одного клиента. Все эти
соединения указанных типов используют только ОДНУ лицензию (одно лицензионное
число). Вплоть до 5 версии Cache механизм CSP работал совсем по другим
правилам. CSP не разделял лицензию с другими типами соединений и не мог
использовать одну и ту же лицензию с несколькими сессиями CSP.
%CSP.Session.Login() все это изменил. Вы можете теперь связать ВСЕ типы
соединений Cache от одного клиента под одну единицу лицензии при условии
использования Вами нескольких программных интерфейсов.

Это общие сведения, а теперь рассмотрим конкретно CSP.
Лицензия CSP связана с браузером на машине клиента в течение действия Сессии.
Когда бы не создавалась новая Сессия, сразу отсчитывается одно лицензионное
число и закрепляется за новой Сессией. Когда Сессия заканчивается по времени
ожидания или закрывается, механизм CSP сообщает Менеджеру Лицензий, что одна
лицензия должна быть освобождена, основываясь на правилах перида задержки
(grace period). Об этом немного позже.

То, что требуется знать о Сессиях. Сессии поддерживаются через куки (cookies)
по умолчанию или через "tokens", когда куки выключены. Каждый раз, когда
браузер устанавливает соединение без передачи этих двух параметров, будет
отсчитана новая лицензия, независимо от того, что пользователь уже был
зарегистрирован в другом окне.

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

Фреймы - если вы загрузили страницу HTML с frameset, в котором имеется 3
targets, являющихся страницами CSP - все эти окна (target windows) заберут
по отдельной лицензии. Все они будут вызваны поочередно и куки будут связаны с
последним вызовом. Но первые два окна тоже захватят 2 лицензионых числа,
которые не будут использоваться, а будут сиротливо ожидать, когда истечет
установленное время ожидания для их Сессии. Ответ для такого случая - делайте
frameset только в странице CSP... или используйте первую страницу на входе в
приложение без фреймов.
Рассуждения о браузерах. Netscape/Mozilla формируют единое пространство для
куки (for cookies), независимо от того, как открывался браузер. Это означает,
что на ПК с таким браузером Вы не сможете открыть более одной Сессии - и это
хорошо. Если вы используете команду js open() или CTRL-N, куки будут переданы
в порожденное окно (child window). Если Вы откроете новое окно с иконки
Internet Explorer, в этом случае куки не будут переданы (не будут
использоваться из уже открытого окна) и при запуске новой страницы CSP будет
забрана одна Лицензия..

Порт 1972 - Не используйте Studio "View Web Page" (встроенный Web-сервер)!!!
Суперсервер не работает с правилами, установленными для лицензий CSP. Каждый
запрос к странице CSP будет забирать лицензию. Не используйте этот порт или
исправьте проект, чтобы использовать действительный Web сервер, но не порт 1972.
Начиная с версии Cache 5.0.1 это является основным требованием.
Еще несколько общих пожеланий.

Учите пользователей - Не закрывайте окно браузера - вы потеряете Сессию.
Научите пользователей вместо зарытия окна нажимать клавишу выхода, которая
вызовет функцию закрытия Сессии %Session.End=1.

(прим.перев. - в своем приложении мы кроме кнопки выхода из приложения на
всякий случай повесили функцию закрытия Сессии и на событие "закрытие окна" -
некоторых пользователей учить - себе дороже...)

ПОЛЬЗУЙТЕСЬ %session.Login()!!!!!

В своем приложении заставляйте пользователя регистрироваться. И свяжите свою
регистрацию с этим функционалом. ВСЕ ваши проблемы уйдут прочь.
Пользователь закрыл окно? Ну и что? Когда он снова будет регистрироваться,
мы свяжем Сессию с этой же Лицензией.
Пользователь запустил приложение еще раз в другом окне? Прекрасно, мы объединим
эти соединения под одну Лицензию.
Пользователи используют сразу Java и CSP и ODBC? Отлично, мы объединим все эти
коннекты...

Забыл совсем про период задержки (grace period) порассуждать....
В Менеджере лицензий мы запоминаем время старта Сессии. Когда механизм Сессий
сообщает, что сессия закрыта, происходят некоторые дополнительные проверки в
менеджере Лицензий...
Правило такое: Лицензия не может быть освобождена (счетчик пользователей
уменьшен на единицу) ранее, чем через 5 минут после закрытия Сессии. И также
Лицензия не может быть освобождена ранее, чем через 10 минут после создания
Сессии.

Простая таблица: в первой колонке, сколько времени (минуты)
Сессия проработала, во второй - время, на которое была захвачена Лицензия.
2 10
4 10
5 10
7 12
14 19
Это сделано для предотвращения возможности использовать CSP с малым количеством
лицензий, как у его прародителя Weblink.

И еще, я предлагаю устанавливать невероятно короткий период закрытия сессии по
умолчанию - 30 секунд или менее. А чтобы предотвратить потерю данных при
использовании гиперсобытий, использовать на странице регистрации пользователя
%session.Login() и переназначение AppTimeout в значение, необходимое для работы
конкретной задачи или конкретного пользователя.

--
Bill McCormick
Web/Objects Support Manager
InterSystems Corporation


---

А в целом присоденияюсь к предыдущему оратору - такое "ТЗ" обязательно делать через CSP ?

Dmitry V. Liseev]
>>Через что делать? В принципе, на Cache можно написать свой TCP сервер.
Это именно то, что надо для данной задачи. Пропадает необходимость гонять пакеты
поверх протокола HTTP и прочие накладные расходы, связанные с Apache.

Можно - с лицензией придётся разбираться самому

>>Проблема в том, что на каждое такое соединение Cache забирает отдельную
лицензию. А с каждой рабочей станции может быть установлено в среднем
5 независимых соединений (у юзера несколько приложений, причем многопоточных).
Хотелось бы, чтобы лицензию забирала рабочая станция, если она установила
хотя-бы одно соединение, и эта лицензия могла использоваться разумным
числом соединений с нее (примерно до 10).
____________________________

в тексте, что я привел, да и в редакторе кофигурации разрешается до 12-ти соединений для одной лицензии.

Кстати для собственного TCP сервера....

достаточно форкать JOB с прослушкой порта для конкретного клиента - в нем логиниться через команду выше - и обслуживать уже по тому протоколу какой хочеться.

По крайней мере мы так привязываем фоновые задачи к клиенту ... вроде работает. Попробуйте.