Syncker Plugin

• The Running Syncker for a custom project article for more details on Syncker initialization and synchronization code.
• The Syncker-specific options article for more details on Syncker command-line options and console commands.
• The Video Wall Output with AppWall Plugin article for more details on using the AppWall plugin for multi-monitor slave configurations.

Syncker API:

• The Manager interface article for more details on managing Syncker via code (C++, C#, UnigineScript).
• The Master interface article for more details on managing Syncker master via code (C++, C#, UnigineScript).
• The Slave interface article for more details on managing Syncker slave via code (C++, C#, UnigineScript).

The order of launching master and slave applications does not matter: you can launch several Slaves, then the Master, and then the rest of the Slaves — synchronization will start automatically. Master starts the session as soon as all Slaves are connected.

In case only the Master is present (-sync_count 1) and connection of additional slaves on the fly is enabled (-sync_allow_extra_slaves 1), the session starts immediately and lasts forever (until the Master is on).

Syncker works in Asynchronous mode providing synchronization between the channels by means of reconstruction using the data of previous frames. In asynchronous mode all computers draw their own frames, each with its own frame rate. So, in this mode we synchronize time.

In case there are a lot of Slaves used, resulting in significant growth of the network load, it is recommended to try and reduce load by enabling broadcast or multicast addressing modes. If changing the addressing mode does not solve the problem, you are recommended to adjust send rate, interpolation/extrapolation parameters.

UNIGINE Syncker uses Interpolated Snapshots (IS) to tackle with the problem of lost packets between the Master and Slaves. It works by taking two old, but known positions and interpolating the object between them. It is accomplished by having a buffer of received positions and rotations, along with the time they represent. We usually take our current local time minus some predefined amount — interpolation period (40 ms by default), then go into our buffer, find the two indices that are just before and just after this time and interpolate.

If we don't have a received position and rotation for the time we're looking for, the extrapolation (guessing) is used. It also has a limited time — extrapolation period (200 ms by default). If the extrapolation period is over but there are still no packets received, all objects will freeze.

In most cases, this method provides a very accurate representation of the world to each Slave, as in general only already known positions of remote objects are rendered and in rare cases the system will try to extrapolate (guess) where an object is. This, however, comes at a cost, as we always render 40 ms (interpolation period) behind current time, so that new packets have time to arrive with data.

Basically, you can use the following delivery modes for sending/receiving messages:

• Reliable - Reliable and sequenced mode, enabled by default. All packets shall be delivered to the recipient in the exact order they were sent.
• Unreliable - Pure UDP. Packets may be lost, duplicated, or received in an order that differs from the one they were sent. Packets are not compressed, fragmented, or merged. Everything is sent "as is". This mode is the fastest one as it requires no additional time for processing. You can use this mode for sending timestamped auxiliary data (e.g., for interpolation) having the size close to MTU. Example: sending 10 times a second positions of 10 aircrafts with the information on the current time, status of flaps, slats, ailerons, landing gears, etc.
• Sequenced - Packets may be lost, but never duplicated, they arrive in the exact order they were sent. This mode can be used for sending auxiliary data having the size close to MTU. Example: sending each frame positions of 10 aircrafts with the information on the status of flaps, slats, ailerons, landing gears, etc.

Multiple systems may use Syncker's network simultaneously (e.g. IG and a users App application). For convenience, all messages are sent and received via named channels. If the specified channel does not exist, it shall be created.

The following addressing modes for communication are available:

• Unicast
• Multicast
• Broadcast

Depending on your project's requirements, you can choose the one that fits best: ensures the lowest possible load, or provides additional features like easy testing on a single PC or communication between hosts from different subnets using different ports.

Suppose, you have prepared a "static" project (meaning that no new objects are created in it and no existing ones are deleted or moved) with some cinematics. This corresponds to the majority of archviz projects or various types of demonstrations.

Suppose, you'd like to demonstrate this project using a wall or a CAVE system. Syncker should do the job here, but there is nothing in your project about it, not a single line of code! Well, you don't need it, simply use a special system script that launches the Syncker! That's all you should do, as the only thing moving during the cinematic sequence is the camera (which is synchronized automatically) with all other objects being static (no need to sync them).

This is the simplest mode, you don't have to know IP addresses or ports neither do you have to write any code. All you need to know is:

• Who shall be the Master.
• What is the number of Slaves.

Then you simply do the following:

• Run a Master application substituting the System Runtime Script with the special one (core/systems/syncker/unigine.cpp) and providing necessary startup command-line options to define it as the Master and set the total number of host computers:
  Shell commands

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

  -sync_count here sets the total number of computers (Slaves + Master). In this simplest case -sync_count 2 - means a single Master and a single Slave.

• Run each Slave application using the same system script and indicating that the host is a Slave (not Master):
  Shell commands

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

That's it! Run Master and Slave(s) in any order (it doesn't matter). Slaves shall automatically find the Master in the network and connect to it.

The basic workflow is as follows:

1. Implement Syncker logic for your Master and Slave application (you can use the same application on both Master and Slave sides).

2. Prepare your environment.

   It is recommended to use a 100 Mb LAN. Otherwise, you may experience network lags (see Troubleshooting section).

   All applications you use must have access to all Unigine files and project data. So, you should copy your project to all computers. If some nodes are missing in the world file on a local computer, they will not be rendered.

3. Run the Master application.

   To run a Master application provide necessary startup command-line options, e.g.:

   Shell commands

   <your_app> -extern_plugin "Syncker" -sync_master 1 -sync_view <display_name> -sync_count <number_of_hosts>

   Notice

   The order of launching Master and Slave applications does not matter.

4. Run a Slave application.

   To run a Slave application provide necessary startup command-line options, e.g.:

   Shell commands

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

   If you want a Slave with a multi-monitor configuration to render several viewports, you should use the AppWall plugin and assign viewports to monitors via the sync_view_n options, e.g.:

   Shell commands

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

   Notice

   The order of plugins in the list matters: AppWall must be specified before Syncker.
5. Set up screen / projection configuration. This step is performed when all Syncker hosts are successfully connected and working.

The console shall look like this:

A Slave periodically sends broadcast messages when trying to find the Master that responds, but there's no reply. Messages do not reach the Master.

Solutions:

• Make sure that the port used by the Slave for sending/receiving messages (Slave UDP port) is not blocked by the firewall on the Master. Try disabling firewalls on the Master and all the Slaves.
• Make sure that broadcast / multicast messages are not blocked by the router/switch. It is unlikely, but still possible.
• Try to explicitly specify Master's IP address via the sync_master_address command, for example:
  Source code

  -sync_master_address 192.168.0.1

  In this case a Slave shall skip the phase of searching for the Master via broadcast messages and shall use unicast mode for direct connection.
• Make sure that Master really waits for new connections. Check the sync_count value, is it greater than 1?

In this case the console shall look like this:

Connection requests from a Slave were received by the Master, the connaction was opened and the session was started, but connection response did not reach the Slave.

Solutions:

• Make sure that the port used by the Slave for sending/receiving messages (Slave UDP port) is not blocked by the firewall. Try disabling firewalls on the Master and all the Slaves.
• Make sure that broadcast / multicast messages are not blocked by the router/switch. It is unlikely, but still possible.
• Try using a unicast connection:
  Source code

  -sync_method unicast

• Check that the broadcast address found is valid, try setting up a broadcast channel for all hosts:
  Source code

  -sync_broadcast_address 255.255.255.255

• Try setting another multicast address on the Master and Slaves via the sync_multicast_address command.
• Check IP/port of the Slave connected to the Master. Is this the right Slave, or maybe there is another instance of the Slave looking for the Master on the same port? Try changing port number on the Master and Slaves (e.g., -sync_port 25100) and restart applications.

If the network latency is too large despite 1Gb bandwidth or higher, it can be caused by a 100 Mb or 10 Mb device connected to a network. Data exchange rate will drop down to the maximum rate supported by such device, slowing down Syncker connection speed.

• Some 100 Mb or 10 Mb devices can have a working network interface when they are turned off.
• It is also possible that when turned off, 1 Gb devices have a network interface working at 100 Mb rate, which slows down connection in the LAN.

Integration with the Microprofile tool enables you to monitor performance, detect bottlenecks, and eliminate them.

Useful Tool#

Testing and operation revealed that Syncker Plugin may have issues when used with the following equipment:

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

If any issues arise, try switching to other equipment.