При работе в терминальном режиме (RDP) системные администраторы и программисты 1С часто сталкиваются с ситуацией, когда проброшенные локальные COM-порты клиентов становятся видимыми для всех участников сессии. Это создает путаницу при настройке торгового оборудования: в списке доступных портов 1С отображается множество устройств, и пользователю сложно определить, какой именно порт принадлежит его физическому сканеру. Рассмотрим детально, почему так происходит, и разберем шаги по устранению этой проблемы.
Прежде всего, важно понять, что администраторы не ошибаются: это действительно штатное поведение протокола RDP в современных версиях Windows Server. Проанализируем ситуацию. Когда клиент подключается к серверу с включенной опцией «Порты», служба удаленных рабочих столов создает перенаправление. В старых версиях ОС изоляция была жестче, однако в современных реалиях система создает символические ссылки в общем пространстве имен устройств.
Несмотря на то, что порты видны в общем списке, физический доступ к каналу передачи данных обычно ограничен. Если Пользователь_А попытается открыть COM3, который принадлежит Пользователю_Б, он, скорее всего, получит системную ошибку доступа. Однако программные интерфейсы 1С и драйверы оборудования (например, АТОЛ) при сканировании доступных ресурсов видят всю ветку реестра или все порты, зарегистрированные в системе, что и приводит к замусориванию списка выбора.
В современных конфигурациях на управляемых формах проблема решается на уровне платформы через механизм Рабочих мест. Разберем по шагам, как это функционирует. 1С идентифицирует каждое подключение по уникальному идентификатору, который формируется из имени компьютера клиента и имени пользователя Windows.
Когда мы настраиваем сканер штрихкода, настройки (номер порта, скорость, битность) сохраняются не «вообще для всех», а в привязке к конкретному ИдентификаторуРабочегоМеста. Даже если в системе 100 портов, 1С при запуске сессии конкретного пользователя будет обращаться только к тому COM-порту, который был указан в настройках именно для этого рабочего места. Проблема «видимости» остается лишь на этапе первоначального выбора порта в диалоговом окне.
Если нам необходимо программно определить, какой именно порт проброшен в текущую сессию, мы можем воспользоваться системной командой change port /query. Проанализируем, что она нам дает. Выполнение этой команды в консоли выводит список сопоставлений вида:
COM3 = \Device\RdpDrPort\;COM3:1\tsclient\COM3
Здесь COM3:1 указывает на номер сессии. Мы можем написать небольшую функцию, которая будет парсить вывод этой команды и автоматически предлагать пользователю только «его» порты. Рассмотрим пример логики обработки:
// Пример логики получения списка своих портов (псевдокод)
Команда = "change port /query";
РезультатВыполнения = ЗапуститьСистемнуюКоманду(Команда);
// Далее перебираем строки и ищем вхождение номера текущей сессии
// или идентификатора \tsclient\
При использовании драйверов АТОЛ (как упоминалось в обсуждении), важно правильно использовать механизм Логических Устройств. Драйвер позволяет создать именованную настройку. Посмотрим на ситуацию с точки зрения кода. В процедуре ОбработкаВнешнегоСобытия мы получаем данные от внешнего компонента (ВК). Параметр Источник или Событие часто содержит информацию о том, какое устройство передало данные.
Разберем структуру вызова:
Процедура ОбработкаВнешнегоСобытия(Источник, Событие, Данные) Экспорт
// Источник — это обычно имя драйвера или идентификатор ЛУ
// Данные — считанный штрихкод
Если Источник = "СканерШтрихкода" Тогда
// Обрабатываем данные
КонецЕсли;
КонецПроцедуры
Чтобы сканеры не конфликтовали, достаточно один раз в сеансе конкретного пользователя в настройках драйвера (ВК) жестко прописать номер порта. Драйвер при инициализации «захватит» этот порт. Если другой пользователь в своей сессии попытается захватить тот же порт (ошибочно), драйвер просто выдаст ошибку подключения, не мешая работе первого пользователя.
Если работа с COM-портами через RDP кажется нестабильной (что часто бывает из-за «залипания» портов при разрывах связи), рассмотрим более надежные альтернативы:
Выясним причину опасений автора: администраторы действительно не врут, порты будут видны. Однако это не является препятствием для работы. Основные рекомендации сводятся к следующему:
Таким образом, разделение доступа к сканерам происходит не на уровне «видимости» портов в списке Windows, а на уровне логического захвата порта конкретным экземпляром драйвера в конкретной сессии пользователя.