This page has been translated automatically.
Видеоуроки
Интерфейс
Основы
Продвинутый уровень
Подсказки и советы
Основы
Программирование на C#
Рендеринг
Профессиональный уровень (SIM)
Принципы работы
Свойства (properties)
Компонентная Система
Рендер
Режимы вывода изображения
Физика
Браузер SDK 2
Лицензирование и типы лицензий
Дополнения (Add-Ons)
Демонстрационные проекты
API Samples
Редактор UnigineEditor
Обзор интерфейса
Работа с ассетами
Контроль версий
Настройки и предпочтения
Работа с проектами
Настройка параметров ноды
Setting Up Materials
Настройка свойств
Освещение
Sandworm
Использование инструментов редактора для конкретных задач
Расширение функционала редактора
Встроенные объекты
Ноды (Nodes)
Объекты (Objects)
Эффекты
Декали
Источники света
Geodetics
World-ноды
Звуковые объекты
Объекты поиска пути
Player-ноды
Программирование
Основы
Настройка среды разработки
Примеры использования
C++
C#
UnigineScript
Унифицированный язык шейдеров UUSL (Unified UNIGINE Shader Language)
Плагины
Форматы файлов
Материалы и шейдеры
Rebuilding the Engine Tools
Интерфейс пользователя (GUI)
Двойная точность координат
API
Animations-Related Classes
Containers
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Objects-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
IG Plugin
CIGIConnector Plugin
Rendering-Related Classes
VR-Related Classes
Работа с контентом
Оптимизация контента
Материалы
Визуальный редактор материалов
Material Nodes Library
Miscellaneous
Input
Math
Matrix
Textures
Art Samples
Учебные материалы

Плагин Syncker

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

Внимание

ЭТО НЕ MULTIPLAYER РЕШЕНИЕ!

Для создания многопользовательского приложения в настоящее время следует использовать стороннее решение.

Просто подключите несколько компьютеров к одному бесшовному дисплею с высоким разрешением по локальной сети. И не имеет значения, работают ли эти компьютеры на Windows и Linux одновременно, поскольку Syncker работает даже на разных платформах. Более того, созданные виртуальные среды могут иметь любую конфигурацию монитора, поскольку все вьюпорты полностью настраиваются и поддерживаются сетки с несколькими мониторами на компьютерах Slave.

Syncker

Компьютеры в локальной сети подключены через Syncker

Более того, Syncker предлагает вам гибкую настройку всего процесса синхронизации на основе пользовательских сообщений . Вместо отправки всего набора данных трансформаций для объектов, которые можно только повернуть, или отправки огромных объемов данных трансформаций для всех частей сложных объектов, когда их положение можно определить с помощью всего лишь нескольких простых параметров, вы можете отправить один кватернион или набор параметров.

Смотрите также#

Syncker API:

  • Подробнее об управлении Syncker с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе Manager.
  • Подробнее об управлении Syncker Master с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе Master.
  • Подробнее об управлении Syncker Slave с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе Slave.

Структура и принципы#

Syncker позволяет отображать мир на разных компьютерах, синхронизированных по локальной сети. Эти компьютеры могут быть двух типов:

Master

Приложение Master - это приложение, работающее на главном компьютере. Помимо рендеринга, он также выполняет анимацию и вычисления физики, а также управляет приложениями Slave.

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

Все остальные приложения синхронизируются с Master.

Slave

Приложения Slave - это все остальные приложения, работающие на компьютерах, подключенных к сети. К одному Master может быть подключено неограниченное количество приложений Slave (если позволяет пропускная способность сети). Цель таких приложений - визуализировать все ноды, которые видны в их вьюпортах.

  • Весь рендеринг выполняется непосредственно на графическом процессоре Slave.
  • Физическое моделирование выполняется Master.

    Примечание
    Физическое моделирование в приложениях Slave следует отключить для повышения производительности.
  • Автоматически синхронизируются объекты следующих типов: ObjectWaterGlobal, ObjectCloudLayer, ObjectParticles, WorldLight, если они присутствуют в файле *.world на всех компьютерах.
  • Анимации обновляются на компьютере Master, в то время как приложения Slave получают только рассчитанные трансформации костей.
  • Системы частиц обновляются на Slave, но в соответствии с параметрами, полученными от Master.
  • Физическое моделирование в приложениях Slave должно быть отключено, чтобы не переопределять положение и ориентацию нод, отправленных по сети из Master.

Конфигурация Slave настроена так, чтобы соответствовать конфигурация мониторов .

Порядок запуска#

Порядок запуска приложений Master и Slave значения не имеет: вы можете запустить несколько приложений Slave, затем Master, а затем остальные приложения Slave - синхронизация начнется автоматически. Master запускает сеанс, как только все приложения Slave подключены.

Если присутствует только Master (-sync_count 1) и включено подключение дополнительных приложений Slave на лету (-sync_allow_extra_slaves 1), сеанс начинается немедленно и продолжается пока включен Master.

Синхронизация#

Syncker работает в асинхронном режиме , обеспечивая синхронизацию между каналами посредством реконструкции с использованием данных предыдущих кадров. В асинхронном режиме все компьютеры рисуют свои собственные кадры, каждый со своей частотой кадров. Итак, в этом режиме мы синхронизируем время.

В случае, если используется много приложений Slave, что приводит к значительному увеличению нагрузки на сеть, рекомендуется попытаться снизить нагрузку, включив режимы адресации broadcast или multicast. Если изменение режима адресации не решает проблему, рекомендуется настроить скорость отправки, параметры интерполяции / экстраполяции.

UNIGINE Syncker использует Interpolated Snapshots (IS) для решения проблемы потери пакетов между Master и Slave. Он работает, беря две старые, но известные позиции и интерполируя объект между ними. Это достигается за счет наличия буфера полученных позиций и поворотов, а также времени, которое они представляют. Обычно мы берем наше текущее местное время за вычетом некоторой предопределенной величины - периода интерполяции (по умолчанию 40 мс), затем заходим в наш буфер, находим два индекса, которые находятся непосредственно перед и сразу после этого времени, и интерполируем.

Если у нас нет полученной позиции и поворота на время, которое мы ищем, используется экстраполяция (предположение). Он также имеет ограниченный период экстраполяции по времени (по умолчанию 200 мс). Если период экстраполяции закончился, но пакеты все еще не получены, все объекты «заморозятся».

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

Двусторонняя связь#

Slave не молчит, он может отправлять сообщения в Master, он может даже управлять Master, а также другими приложениями Slave (например, запускать профилировщик на всех компьютерах или закрывать все приложения), отправляя команду sync.

Для отправки и получения сообщений между Master и Slave, Syncker использует один сокет UDP со следующими пятью технологиями:

  • Reliable - гарантирует доставку пакетов с использованием так называемых пакетов подтверждения. Когда Master отправляет сообщение, Slave сообщает, что сообщение получено. В случае, если Slave не отвечает в течение определенного периода времени, Master пытается повторно отправить сообщение.
  • Sequenced - гарантирует получение всех пакетов в правильном порядке с обнаружением всех дубликатов. У каждого пакета есть номер, и пока Slave не получит пакет, Master не будет отправлять ему следующие (с большими номерами).
  • Merged - маленькие сообщения объединяются в большее, вместо того, чтобы отправлять их все одно за другим (отправьте один 100-байтовый пакет, вместо 10 пакетов по 10 байтов каждый). Это упрощает и ускоряет отправку пакетов подтверждения отправителю.
  • Fragmented - большое сообщение, превышающее размер MTU (Maximum Transmission Unit), должно быть разбито на несколько пакетов, имеющих размер MTU. Это обеспечивает доставку всех пакетов, защищая Slave от переполнения буфера, вызванного одним большим пакетом.
  • Compressed - все сообщения перед отправкой сжимаются по алгоритму LZ4. Это снижает нагрузку на сеть, но немного увеличивает нагрузку на сам компьютер.

Итак, вот как доставляются пакеты:

  1. Во время кадра до точки синхронизации данных Master подготавливает сообщения к отправке и помещает их в очередь. Это «большое сообщение» сжимается, разбивается на части в соответствии с размером MTU, упаковывается в пакеты со следующими тремя числами, указанными для каждого из них: порядковый номер (группа пакетов), номер фрагмента и общее количество фрагментов в этой последовательности.
  2. Пакеты отправлены.
  3. При получении любого из пакетов Slave изменяет размер своего скользящего окна в соответствии с количеством фрагментов и добавляет полученный фрагмент в это окно.
  4. В случае пропущенных / потерянных пакетов Slave добавляет соответствующую информацию об отсутствующей части, которую он запрашивает для повторной отправки, в пакет подтверждения, отправленный на Master.

Режимы доставки#

В принципе, вы можете использовать следующие режимы доставки для отправки / получения сообщений:

  • Reliable - Надежный и последовательный режим, включен по умолчанию. Все пакеты должны быть доставлены получателю в том порядке, в котором они были отправлены.
  • Unreliable - Чистый UDP. Пакеты могут быть потеряны, дублированы или получены в порядке, отличном от того, в котором они были отправлены. Пакеты не сжимаются, не фрагментируются и не объединяются. Все отправляется «как есть». Этот режим самый быстрый, так как не требует дополнительного времени на обработку. Вы можете использовать этот режим для отправки вспомогательных данных с отметками времени (например, для интерполяции), имеющих размер, близкий к MTU.

    Пример : отправка 10 раз в секунду позиций 10 самолетов с информацией о текущем времени, состоянии закрылков, предкрылков, элеронов, шасси и т.д.

  • Sequenced - Пакеты могут быть потеряны, но никогда не дублируются, они прибывают в том порядке, в котором были отправлены. Этот режим можно использовать для отправки вспомогательных данных размером, близким к MTU.

    Пример : отправка каждого кадра положения 10 самолетов с информацией о состоянии закрылков, предкрылков, элеронов, шасси и т.д.

Несколько систем могут использовать сеть Syncker одновременно (например, IG и приложение пользователя App). Для удобства все сообщения отправляются и принимаются по именованным каналам. Если указанный канал не существует, он должен быть создан.

Режимы адресации#

Доступны следующие режимы адресации для связи:

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

Лучшая практика
Режим Unicast рекомендуется использовать на этапе разработки как наиболее гибкий, а Multicast и Broadcast рассматриваются как варианты для производства. Режим Broadcast - лучший вариант, если сеть состоит только из IG-хостов.
Broadcast

Master отправляет пакеты всем компьютерам в сети. Сообщения принимаются компьютерами Slave, а также всеми другими компьютерами, не имеющими отношения к Synker.

Примечание
Все хост-компьютеры должны находиться в одной подсети и использовать один и тот же порт.

Преимущества:

  • Уменьшена нагрузка на хост Master (должен быть отправлен только один пакет вместо отправки одной отдельной его копии на каждый Slave).
  • Простая настройка (просто установите режим вещания для Master через -sync_method broadcast

Недостатки:

  • Невозможно протестировать на одном компьютере.
  • Сообщения принимаются на все компьютеры в сети (даже те, которые не имеют отношения к Synker), что приводит к значительной нагрузке на сеть, маршрутизатор и сами компьютеры, если в сети много таких компьютеров.
Unicast

Master отправляет сообщения только своим приложениям Slave: отдельная копия сообщения отправляется каждому Slave.

Примечание
Все хост-компьютеры могут находиться в разных подсетях и использовать любые порты (кроме Master).

Преимущества:

  • Простая настройка (работает по умолчанию).
  • Компьютеры могут принадлежать к разным подсетям (например, несколько компьютеров из LAN плюс несколько подключенных через WiFi).
  • Сообщения от Master принимаются только его приложениями Slave.
  • Легко протестировать на одном компьютере.
  • Никаких ограничений, кроме точно определенного порта для Master.

Недостатки:

  • Значительное количество приложений Slave увеличивает нагрузку на сегмент сети между Master и маршрутизатором, так как отдельная копия должна быть отправлена на каждый Slave.

    Примечание
    Переключение в режимы Multicast/Broadcast помогает снизить нагрузку на сеть в случае увеличения количества Slaves. Поскольку в этих режимах нагрузка практически не затрагивается, в отличие от Unicast, где нагрузка пропорциональна количеству Slaves.
Multicast

Master отправляет сообщение на уникальный многоадресный адрес, и маршрутизатор перенаправляет это сообщение только на компьютеры, которые «слушают» этот адрес (присоединились к группе multicast).

Примечание
Все компьютеры должны использовать один и тот же порт. Master должен знать адрес многоадресной рассылки, а приложения Slave должны быть подключены к той же группе multicast.

Преимущества:

  • Минимально возможная нагрузка на Master и сеть.
  • Master отправляет сообщение только один раз, приложения Slave получают копии того же сообщения.
  • Копии сообщения принимаются только ПК Slave, другие ПК в сети их не получают.

Недостатки:

  • Необходимо настроить дополнительные параметры.
  • Настройки маршрутизатора по умолчанию могут привести к блокировке пакетов Syncker. Возможно, вам придется изменить эти настройки, чтобы этого избежать.
  • Невозможно протестировать на одном компьютере.

Сетевая нагрузка#

Обобщая информацию из приведенной выше таблицы в отношении нагрузки сетевого трафика:

  • Режим Multicast генерирует минимальный сетевой трафик по сравнению с другими режимами, таким образом создавая наименьшую нагрузку на роутер и Wi-Fi.
  • Режим Broadcast может быть более затратным, потому что пакеты отправляются на все сетевые ПК, включая те, которые не имеют Slave (если есть). Если в вашей сети нет других компьютеров, кроме Slave, то объем трафика будет таким же, как в режиме Multicast.
  • Режим Unicast генерирует объем сетевого трафика, который можно рассчитать как Multicast * количество ПК Slave .

Для дальнейшей оптимизации загрузки трафика вы можете увеличить временные интервалы отправки пакетов:

Исходный код (C++)
//On the Master
	master->setSendRate(15.0f); // send packets 15 times per second

	//Both on the Master and all Slaves
	syncker->setInterpolationPeriod(0.1f); // 100 ms delay

В этом примере пакеты будут отправляться только 15 раз в секунду, поэтому задержка составит 100 мс.

Примечание

Во избежание визуального дрожания необходимо выполнение следующего условия:

interpolation period > (1 / send rate)

Следовательно, уменьшение лага (периода интерполяции) требует увеличения скорость отправки , что повлияет на загрузку сети:

Исходный код (C++)
//On the Master
	master->setSendRate(30.0f); // send packets 30 times per second

	//Both on the Master and all Slaves
	syncker->setInterpolationPeriod(0.05f); // 50 ms delay

Несколько камер и Slave с несколькими мониторами#

Syncker позволяет синхронизировать виды с нескольких камер. Есть два типа камер:

  • Основная мастер-камера - отдельная камера, соответствующая положению основного зрителя. В конфигурация экрана определяет вьюпорты относительно этой камеры.

    Пример: камера в кабине самолета, соответствующая точке зрения пилота.

  • Вспомогательная камера - дополнительная камера (статическая или динамическая), которую можно установить в любом месте сцены. Вы можете иметь столько камер этого типа, сколько необходимо.

    Пример: наземная камера наблюдения или тепловизионная камера, установленная на крыле самолета.

По умолчанию используется основная мастер-камера. Вы можете создать дополнительные камеры и указать их вьюпорты, которые будут отображаться выбранными приложениями Slave. Такие камеры синхронизируются автоматически.

Syncker предоставляет исключительную гибкость конфигурации вьюпортов. Вы можете использовать до 6 мониторов на одном Slave, каждому из которых назначено собственный вьюпорт. Для этого следует использовать предустановку Wall плагина SpiderVision.

Конфигурации экрана#

Чтобы настроить экраны/проекции, в проект необходимо добавить плагин SpiderVision для всех компьютеров — и Master и Slave. Порядок плагинов в списке имеет значение — SpiderVision должен быть указан перед Syncker:

Shell-команды
-extern_plugin UnigineSpiderVision,UnigineSyncker

Окно настройки открывается при нажатии кнопки F10 на любом компьютере (Master или Slave) для настройки рендеринга всех вьюпортов.

Конфигурация экрана для Syncker должна соответствовать следующим требованиям:

  • Каждый дисплей в конфигурации должен соответствовать одному из мониторов / проекторов.
  • Положение и ориентация каждого дисплея / проектора должны быть относительно главной Master-камеры . Чем ближе монитор к зрителю, тем выше значение FOV.

Можно использовать два типа конфигурации:

  • Установка с несколькими мониторами, состоящая из дисплеев, где каждый Slave отображает свое окно просмотра на соответствующем мониторе (или нескольких мониторах).

    Примечание
    Матрицы проекции и обзора модели автоматически рассчитываются на основе положения зрителя.

    На следующем рисунке показана конфигурация экрана для настройки с несколькими мониторами, где каждый Slave отображает свой вьбпорт на одном мониторе.

    Конфигурация экрана (левое изображение) для настройки нескольких мониторов (правое изображение)
  • Мультипроекторная установка, состоящая из проекторов, где каждый Slave отображает свое окно просмотра через соответствующий проектор. По умолчанию проекторы отображают изображения, видимые с позиции зрителя.

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

Работа с Syncker#

Обычно Syncker имеет 4 состояния:

  • Wait for connections - ожидание подключения всех Slave ПК.
  • Starting... - расчет MTU и стартовая синхронизация всех хостов.
  • Session Started - сессия запущена.
  • Session Finished - сессия окончена, все ПК Slave отключены.

Давайте рассмотрим работу Syncker с использованием широковещательной адресации с Master и одним Slave:

  1. После запуска Master открывает порт (-sync_port) и начинает его слушать. Статус Syncker переключается на "Wait for connections".
  2. Slave получает список всех доступных сетевых адаптеров (Wifi, Ethernet), находит широковещательный адрес для каждого из них и периодически отправляет пакеты запросов на соединение (режим broadcast). Статус Syncker равен "Wait for connections".
  3. Master принимает пакет запроса на соединение, регистрирует Slave и отправляет пакет ответа на соединение (режим unicast), где указывает загруженный в данный момент мир. Когда все ПК Slave подключены, статус Syncker переключается на "Starting...", и Master отправляет настройки проекции всем им.
  4. Как только Slave получает подтверждение от Master, статус переключается на "Starting..." и начинается загрузка мира с Master.
  5. Пока статус Syncker остается "Starting...", и Master, и Slave пытаются найти максимально возможное значение MTU (в настоящее время ограничено 1432 байтами).
  6. По завершении Slave отправляет сообщение Master, что он готов к продолжению. После получения таких сообщений от всех компьютеров Slave (и нахождения MTU для каждого Slave), Master изменяет статус на "Session Started", уведомляя все хосты.
  7. Сессия началась, все готово к работе.

Использование Syncker#

Простая синхронизированная демонстрация#

Предположим, вы подготовили «статический» проект (это означает, что в нем не создаются новые объекты и не удаляются и не перемещаются существующие) с некоторой кинематикой. Это соответствует большинству проектов Archviz или различным типам демонстраций.

Предположим, вы хотите продемонстрировать этот проект с помощью системы Wall . Здесь должен работать Syncker, но в вашем проекте об этом нет ничего, ни единой строчки кода! Что ж, вам это не нужно, просто используйте специальный системный скрипт, который запускает Syncker! Это все, что вам нужно сделать, поскольку единственное, что движется во время кинематографического эпизода, - это камера (которая синхронизируется автоматически), а все остальные объекты статичны (нет необходимости их синхронизировать).

Это самый простой режим, вам не нужно знать IP-адреса или порты, и вам не нужно писать какой-либо код. Все, что вам нужно знать, это:

  • Кто должен быть Master.
  • Какое количество ПК Slave.

Затем вы просто делаете следующее:

  • Запустите приложение Master, подставив Системный сценарий выполнения со специальным (core/systems/syncker/unigine.cpp) и обеспечивающим необходимый запуск параметры командной строки чтобы определить его как Master и установить общее количество хост-компьютеров:

    Shell-команды
    <your_app> -sync_init 1 -extern_plugin "UnigineSyncker" -sync_master 1 -sync_count 2

    -sync_count здесь устанавливает общее количество компьютеров (Slave ПК + Master). В этом простейшем случае -sync_count 2 - означает одиночный Master и единственный Slave.

  • Запустите каждое приложение Slave, используя один и тот же системный скрипт и указав, что хост - это Slave (а не Master):

    Shell-команды
    <your_app> -sync_init 1 -extern_plugin "UnigineSyncker" -sync_master 0

И все! Запускайте Master и Slave (s) в любом порядке (это не имеет значения). Slave автоматически найдет Master в сети и подключится к нему.

Базовый порядок действий#

Базовый порядок действий выглядит следующим образом:

  1. Реализуйте логику Syncker для ваших приложений Master и Slave (вы можете использовать одно и то же приложение для сторон Master и Slave).
  2. Подготовьте свое окружение .

    Рекомендуется использовать LAN 100 Мб. В противном случае могут возникнуть задержки в сети (см. Поиск проблемы раздел).

    Все используемые вами приложения должны иметь доступ ко всем файлам Unigine и данным проекта. Итак, вы должны скопировать свой проект на все компьютеры. Если некоторые ноды отсутствуют в мировом файле на локальном компьютере, они не будут отображаться.

  3. Запустите приложение Master.

    Для запуска приложения Master необходимо обеспечить необходимый запуск параметры командной строки , например:

    Shell-команды
    <your_app> -extern_plugin UnigineSpiderVision,UnigineSyncker -sync_init 1 -sync_master 1 -computer_name <computer_name> -sync_count <number_of_hosts>
    Примечание
    Порядок запуска приложений Master и Slave значения не имеет.
  4. Запустите приложение Slave.

    Для запуска приложения Slave необходимо обеспечить необходимый запуск параметры командной строки , например:

    Shell-команды
    <your_app> -extern_plugin UnigineSpiderVision,UnigineSyncker -sync_init 1 -sync_master 0 -computer_name <computer_name>

    Если настраивать проекции и дисплеи, вы должны использовать плагин SpiderVision.

    Примечание
    Порядок плагинов в списке имеет значение: SpiderVision должен быть указан перед Syncker.
  5. Настройте конфигурации экранов / проекций . Этот шаг выполняется, когда все хосты Syncker успешно подключены и работают.

Окно отладки (Debug)#

Окно отладки Syncker позволяет вам контролировать иерархию объектов во время выполнения. Под всей иерархией понимаются все объекты (не только зарегистрированные в Редакторе), включая объекты в кеше, внутреннюю структуру ссылки на ноды и т.д. Когда нода выбрана, отображается вся необходимая отладочная информация. Эта информация обновляется каждый кадр.

Параметр Search позволяет найти любую ноду по ее имени или идентификатору (на Master или Slave), поэтому некорректную ноду можно найти быстро.

Чтобы открыть окно отладки, запустите консольную команду syncker_debug из Master или Slave следующим образом:

Исходный код
syncker_debug 1

Окно отладки также можно открыть через System Menu:

  1. Откройте System Menu, нажав Esc.
  2. Включите опцию Show debug window:

Откроется окно отладки:

Окно отладки

Поиск и устранение неполадок#

Slave не может подключиться к Master#

Консоль должна выглядеть так:

Slave периодически отправляет широковещательные сообщения при попытке найти отвечающий Master, но ответа нет. Сообщения не доходят до Master.

Решения:

  • Убедитесь, что порт, используемый Slave для отправки / получения сообщений (Slave UDP port), не заблокирован брандмауэром на Master. Попробуйте отключить брандмауэры на Master и всех ПК с Slave.
  • Убедитесь, что широковещательные / многоадресные сообщения не блокируются маршрутизатором / коммутатором. Маловероятно, но все же возможно.
  • Попробуйте явно указать IP-адрес Master с помощью команды sync_master_address, например:

    Исходный код
    -sync_master_address 192.168.0.1

    В этом случае Slave должен пропустить фазу поиска Master через широковещательные сообщения и использовать одноадресный режим для прямого подключения.

  • Убедитесь, что Master действительно ждет новых подключений. Проверьте значение sync_count, оно больше 1?

Master не может ответить Slave#

В этом случае консоль будет выглядеть так:

Запросы на соединение от Slave были получены Master, соединение было открыто и сеанс был запущен, но ответ соединения не достиг Slave.

Решения:

  • Убедитесь, что порт, используемый Slave для отправки / получения сообщений (Slave UDP port), не заблокирован брандмауэром. Попробуйте отключить брандмауэры на Master и всех ПК с Slave.
  • Убедитесь, что сообщения broadcast/multicast не блокируются маршрутизатором / коммутатором. Маловероятно, но все же возможно.
  • Попробуйте использовать одноадресное соединение:

    Исходный код
    -sync_method unicast
  • Убедитесь, что найденный широковещательный адрес действителен, попробуйте настроить широковещательный канал для всех хостов:

    Исходный код
    -sync_broadcast_address 255.255.255.255
  • Попробуйте установить другой адрес многоадресной рассылки на ПК Master и Slave с помощью команды sync_multicast_address.
  • Проверьте IP / порт Slave, подключенного к Master. Это правильный Slave, или, может быть, есть другой экземпляр Slave, который ищет Master на том же порту? Попробуйте изменить номер порта на Master и Slave (например, -sync_port 25100) и перезапустите приложения.

Задержка в сети#

Если задержка в сети слишком велика, несмотря на пропускную способность 1 ГБ или выше, это может быть вызвано подключением к сети устройства на 100 или 10 МБ. Скорость обмена данными упадет до максимальной скорости, поддерживаемой таким устройством, замедляя скорость соединения Syncker.

  • Некоторые устройства на 100 или 10 МБ могут иметь рабочий сетевой интерфейс в выключенном состоянии.
  • Также возможно, что в выключенном состоянии устройства на 1 Гб имеют сетевой интерфейс, работающий на скорости 100 Мб, что замедляет соединение в локальной сети.
Внимание
Syncker не предназначен для использования в сетях Wi-Fi , для стабильной работы необходимы проводные соединения.

Интеграция с инструментом Microprofile позволяет отслеживать производительность, обнаруживать узкие места и устранять их.

Полезный инструмент#

Если у вас есть исходный SDK, вы можете использовать простой и полезный инструмент для отслеживания скорости обмена сетевыми сообщениями. Это server.usc, найденное в source/tools/Interpreter/scripts/network/.

Проблемные устройства#

Тестирование и эксплуатация показали, что плагин Syncker может иметь проблемы при использовании со следующим оборудованием:

  • 3COM OfficeConnect Switch 5
  • D-Link DES-1005D

Если возникнут проблемы, попробуйте переключиться на другое оборудование.

Последнее обновление: 13.12.2024
Build: ()