Форум

Руслан, спасибо!

А что скажут уважаемые разработчики? Реализован ли функционал поддержки соединения keepalive для websocket?

Коллеги, добрый день.
В дополнение к существующим на форуме, ещё одна проблема с push-server.

Вообще он работает, но при определенных условиях.
Расскажу по порядку:

Имеется Битрикс Корпоративный портал, поднятый на BitrixVM версии 7.4.3 в CentOS 7.
Для пользователей оказался важен функционал уведомлений в Веб-мессенджере. Т.е. один пользователь ищет собеседника из списка сотрудников и отправляет ему сообщение. Если собеседник находится на портале, то ему должно всплыть уведомление. На деле происходит следующее:
При отправке сообщения и у получателя и у отправителя в окне браузера с открытым порталом начинают постоянно перемигивать сообщения то на синем, то на коричневом фоне, сигнализирующие о том, что "Устанавливаем соединение с сервером" и "Соединение с сервером установлено". При это само уведомление о сообщении получателю не приходит.
При этом в логах сервера по пути /var/log/push-server тишина.

Чтоб разобраться в проблеме было принято решение поднять тестовый портал. Что и было сделано. Причем портал был поднят в тестовом сегменте сети, никак не связанном с тем сегментом, в котором работает продуктивный портал.
Каково же было удивление, когда на тестовом портале функционал уведомлений заработал с ходу, без каких-либо доп. настроек, кроме Install/Update NodeJS RTC service через ssh консоль.

Стали выяснять обстоятельства и выяснили, что продуктивный портал и клиентские машины пользователей находятся в разных сегментах сети. Данные сегменты (подсети) имеют разные гейтвеи (gateway/шлюз) и общаются через маршрутизатор. Казалось бы, что вы этом особенного? Обычная топология сети. Но это оказалось важным.
Решили поднять машину с Windows 10 в серверной подсети, там же где и продуктивный портал. И оказалось, что с данной машины функционал уведомлений работает как надо. Тот же самый продуктивный портал. Без каких каких-либо доп. настроек. Просто поместили и сервер и клиент в "плоскую" сеть.

Продолжил дальнейшее разбирательство, поговорив с коллегами разработчиками, которые в своих разработках используют websocket. Они мне поведали о том, что websocket представляет из себя tcp туннель, который поднимается между сервером и браузером и позволяет осуществлять двунаправленную передачу данных в реальном времени. За счет чего, собственно, и срабатывают уведомления на сайте.
А ещё рассказали печальную историю о том, что есть сетевое оборудование, коммутаторы и маршрутизаторы, которые любят оптимизировать соединения внутри себя, и если видят, что через конкретное соединение не происходит передача данных, то обрывают его. А оконечные устройства об этом не подозревают и пытаются слать данные через уже разорванное соединение, в результате чего, применительно к Битрикс, мы наблюдаем сообщения на коричневом и голубом фоне, о которых было рассказано выше.
Также поделились знаниями о том, что websocket не обладает стандартным функционалом поддержания установленного соединения, так называемого keepalive. Чтоб оно не разрывалось, требуется самостоятельно кодить функционал, осуществляющий постоянную передачу "пустых" данных, чтобы коммутатор между сервером и клиентом видел, что какие-то данные передаются и не рвал соединение, а поддерживал его.

В связи с выше описанной проблемой вопросы:
1. Реализован ли в push-server Битрикс функционал поддержания соединения websocket? Если да, то где он включается/настраивается? Во всех найденных конфигах по путям /opt/push-server и /etc/push-server ничего похожего на то, что мне нужно не нашлось.
2. Если не поддерживает, то какие ещё способы борьбы с данной проблемой могут быть?
(переделывать всю сетку предприятия в плоскую не предлагать)

Прошу прощения за объем. Наболело.

Прошу прощения. Всё работает, неправильно проверял.

У меня не срабатывает.
Вернее скрипт выполняется, только данные пользователя не синхронизируются.

Нашел решение, позволяющее не заставлять пользователя логиниться на Портал для синхронизации полей из AD:

После того, как изменили поля пользователя в AD, идете в Настройки-Пользователи-Список пользователей. Находите пользователя которого изменили, ставите напротив него галочку. Листаете вниз таблицы. Внизу в поле Действия выбираете Активировать. Жмете кнопку Применить. После этого ждете. У меня изменения прилетали за время от нескольких секунд до 40 минут. От чего зависит не понятно.

В инструкциях почему-то об этом не написано. Надеюсь сэкономил кому-нибудь неделю времени.

Как выяснилось, проблема не только с перемещением пользователя по Структуре компании. Любые изменения в профиле пользователя в AD требуют перелогина данного пользователя на портале, чтоб они применились на портале.
Например, сегодня изменили пользователю телефон в AD, а на портале отображался старый, до того момента, пока пользователь не залогинился на портале.
Периодическая синхронизация происходит раз в час.

Коллеги добрый день.
Перечитал Инструкцию1, Инструкцию 2, поискал на форуме по ключевым словам. Ответа на вопрос не нашел.

Имеется Корпоративный портал: главный модуль версии 20.0, AD/LDAP модуль версии 18.5

Имеется пользователь в AD Иванов Иван с заполненными полями Department и Manager, например, "Бухгалтерия" и "Петров Петр"
Он отображается на портале в разделе Сотрудники в Структуре компании в "квадратике" Бухгалтерия.
Допустим, мы переводим сотрудника из Бухгалтерии в Дирекцию. Для этого в AD меняем поля Department и Manager на "Дирекция" и "Сидоров Сидр" и делаем импорт пользователей, либо дожидаемся Периодической синхронизации. Но пользователь не перемещается в Дирекцию, а остается в Бухгалтерии.

Чтоб пользователь Иванов Иван всё таки переместился в из Бухгалтерии в Дирекцию в Структуре компании, ему требуется залогиниться на портал под своей доменной учетной записью.
Вопрос:
Как избежать этого ненужного шага? По идее ничего не мешает передвинуть пользователя в Структуре компании во время Периодической синхронизации или Импорта, но этого не происходит. Может быть я что-то не до конца настроил?