Плагин Syncker

• Статью Запуск Syncker для пользовательского проекта для более подробной информации о коде инициализации и синхронизации Syncker.
• Статью Параметры Syncker для более подробной информации о параметрах командной строки Syncker и консольных командах.
• Статью Вывод на видеостены с подключаемым модулем Wall статья для более подробной информации об использовании плагина Wall для многомониторных конфигураций Slave.

Syncker API:

• Подробнее об управлении Syncker с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе Manager.
• Подробнее об управлении Syncker Master с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе Master.
• Подробнее об управлении Syncker Slave с помощью кода (C ++, C #, UnigineScript) см. В статье об интерфейсе 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 мс (период интерполяции) отстает от текущего времени, так что новые пакеты успевают прибыть с данными.

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

• Reliable - Надежный и последовательный режим, включен по умолчанию. Все пакеты должны быть доставлены получателю в том порядке, в котором они были отправлены.

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

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

• 

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

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

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

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

• Unicast
• Multicast
• Broadcast

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

Лучшая практика

Режим 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 .

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

//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 мс.

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

//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

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

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

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

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

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

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

  Shell-команды

  <your_app> -system_script core/systems/syncker/unigine.cpp -extern_plugin "Syncker" -sync_master 1 -sync_count 2

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

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

  Shell-команды

  <your_app> -system_script core/systems/syncker/unigine.cpp -extern_plugin "Syncker" -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 "Syncker" -sync_master 1 -sync_view <display_name> -sync_count <number_of_hosts>

   Примечание

   Порядок запуска приложений Master и Slave значения не имеет.

4. Запустите приложение Slave.

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

   Shell-команды

   <your_app> -extern_plugin "Syncker" -sync_master 0 -sync_view <display_name>

   Если вы хотите, чтобы Slave с конфигурацией с несколькими мониторами отображал несколько окон просмотра, вы должны использовать плагин Wall и назначить окна просмотра для мониторов с помощью параметров sync_view_n, например:

   Shell-команды

   <your_app> -extern_plugin "Wall,Syncker" -sync_master 0 -sync_view_0 <display_0> -sync_view_1 <display_1>

   Примечание

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

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

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?