Как настроить прослушивание TCP-порта и создать сокет-сервер в 1С

При попытке организовать сетевой TCP-сервер внутри 1С:Предприятие с помощью ActiveX-компонента MSWinsock.Winsock разработчики часто сталкиваются с ситуацией, когда сокет переходит в состояние прослушивания (State = 2), однако внешние клиенты не могут подключиться, а обработчики событий ConnectionRequest или DataArrival не срабатывают.

Разберем подробнее причины такого поведения платформы 1С и компонента Winsock, выясним технические ограничения данного подхода и рассмотрим рабочие альтернативы для реализации межсистемного обмена и оповещения клиентов.

Анализ кода и причин неработоспособности MSWinsock в 1С

Проанализируем стандартный пример кода, с помощью которого обычно пытаются запустить TCP-сервер на клиенте 1С:

WinSocket = Новый COMОбъект("mswinsock.winsock");
WinSocket.LocalPort = "4444";
WinSocket.Bind("4444", "127.0.0.1");
WinSocket.listen();

ДобавитьОбработчик WinSocket.DataArrival, DataArrival;
ДобавитьОбработчик WinSocket.Error, WinSocketError;
ДобавитьОбработчик WinSocket.ConnectionRequest, ConnectionRequest;

Несмотря на то, что метод listen() переводит объект в режим ожидания соединений, обработка событий не происходит. Выясним основные причины, почему данный механизм работает некорректно:

1. Особенности очереди сообщений Windows и платформы 1С: Обработчики событий COM-объектов подписываются через системную очередь сообщений ОС. Платформа 1С обрабатывает эти события только тогда, когда поток выполнения свободен и клиентское приложение находится в режиме ожидания ввода пользователя. Если в 1С выполняется плотный цикл или код запущен на стороне сервера, очередь сообщений блокируется, и события COM-объекта просто накапливаются в буфере без вызова функций 1С.
2. Отсутствие вызова метода Accept: Для успешного установления TCP-соединения сокет-сервер должен при поступлении события ConnectionRequest явно вызвать метод Accept с передачей идентификатора запроса (requestID) на новом объекте сокета или переподключить текущий. Без вызова Accept рукопожатие TCP не завершается, клиент видит ошибку тайм-аута или отсутствие подключения, а событие получения данных DataArrival никогда не наступает.
3. Разрядность и системные ограничения: Компонент mswinsck.ocx является 32-разрядным ActiveX-элементом. Он физически не сможет работать в 64-битной версии клиента 1С, на стороне 64-битного сервера 1С, в Linux-окружении или в веб-клиенте.

Альтернативные варианты реализации сетевого взаимодействия в 1С

Поскольку встроенные средства работы с сырыми сокетами в языке BSL отсутствуют, а компонент Winsock налагает существенные ограничения, рассмотрим надежные архитектурные решения задачи.

1. Использование штатных HTTP-сервисов 1С

Если задача заключается в передаче данных между 1С и внешними приложениями (или другими клиентами), оптимальным решением является использование HTTP-сервисов.

1. В конфигурации создается объект HTTP-сервис с необходимыми шаблонами URL и методами (POST, GET).
2. Информационная база публикуется на веб-сервере (IIS, Apache или Nginx).
3. Внешние клиенты отправляют сообщения по стандартному протоколу HTTP/HTTPS, получая гарантированный ответ от 1С.

2. Использование Сервера взаимодействия 1С

Если необходимо организовывать мгновенные оповещения между клиентами 1С («дергать» конкретных пользователей извне или из других сеансов), наилучшим выбором станет штатный механизм платформы — Сервер взаимодействия.

Он работает по протоколу WebSocket в фоновом режиме, поддерживает мгновенную доставку сообщений и пуш-уведомлений на управляемые формы без необходимости настройки сторонних сокетов и проброса портов.

3. Внешние компоненты по технологии Native API

Если требуется слушать специфический TCP-порт и принимать бинарный трафик от стороннего оборудования или программ (например, софта на Delphi):

1. Создается или подключается внешняя компонента (C++, Rust или Go), написанная с использованием Native API 1С.
2. Компонента запускает TCP-сервер в отдельном системном потоке ОС, благодаря чему прослушивание порта не блокирует интерфейс 1С.
3. При получении данных компонента вызывается метод ВнешнееСобытие(), которое штатно обрабатывается в 1С через модуль формы или клипборд событий.

4. Использование службы-прокси (Sidecar)

Разберем еще один частый сценарий: создание небольшой внешней консольной службы или сервиса (на Go, Python или C#), который выполняет роль прокси.

1. Внешняя служба слушает необходимый TCP-порт и принимает подключение клиентов.
2. Полученные данные служба транслирует в 1С через HTTP-сервис или OData REST API.
3. Такой подход позволяет полностью изолировать специфику сетевого протокола от кода 1С и обеспечивать стабильную работу в любой операционной системе.