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 article on SpiderVision Plugin for more details on the setup of 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 Slave apps, then Master, and then the remaining Slave apps — synchronization will start automatically. Master starts the session as soon as all Slave apps are connected.

In case only Master is present (-sync_count 1) and connection of additional Slave applications on the fly is enabled (-sync_allow_extra_slaves 1), the session starts immediately and lasts forever (until 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 Slave applications 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 Master and Slave. 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 the Syncker's network simultaneously (e.g. IG and a user's 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.

Summarizing the information from the table above as related to the network traffic load:

• The Multicast mode generates the minimum network traffic, as compared to other modes, thus creating the least load on the router and wi-fi.
• The Broadcast mode can be more consuming, because the packets are sent to all network PCs, including those that are not Slave (if any). If you don't have any other PCs in your network except for Slave ones, then the traffic amount will be the same as in the Multicast mode.
• The Unicast mode generates amount of network traffic that can be calculated as Multicast * number of Slave PCs.

To further optimize the traffic load, you can increase the time intervals for packets sending:

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

In this example, packets will be sent only 15 times per second, thus the lag will make 100 ms.

Consequently, reducing the lag (interpolation period) requires increasing the send rate, which will affect the network load:

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

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 the Wall 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 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 Master.
• What is the number of Slave PCs.

Then you simply do the following:

• Run the 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 Master and set the total number of host computers:

  Shell commands

  <your_app> -sync_init 1 -extern_plugin "UnigineSyncker" -sync_master 1 -sync_count 2

  -sync_count here sets the total number of computers (Slave PCs + 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 Slave (not Master):

  Shell commands

  <your_app> -sync_init 1 -extern_plugin "UnigineSyncker" -sync_master 0

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

The basic workflow is as follows:

1. Implement Syncker logic for your Master and Slave applications (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 UnigineSpiderVision,UnigineSyncker -sync_init 1 -sync_master 1 -computer_name <computer_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 UnigineSpiderVision,UnigineSyncker -sync_init 1 -sync_master 0 -computer_name <computer_name>

   If you want to configure projections and displays, you should use the SpiderVision plugin.

   Notice

   The order of plugins in the list matters: SpiderVision 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:

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

Solutions:

• Make sure that the port used by Slave for sending/receiving messages (Slave UDP port) is not blocked by the firewall on Master. Try disabling firewalls on Master and all Slave PCs.
• 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 Slave shall skip the phase of searching for Master via broadcast messages and 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 Slave were received by Master, the connection was opened and the session was started, but connection response did not reach Slave.

Solutions:

• Make sure that the port used by Slave for sending/receiving messages (Slave UDP port) is not blocked by the firewall. Try disabling firewalls on Master and all Slave PCs.
• 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 Slave PCs via the sync_multicast_address command.
• Check IP/port of the Slave connected to Master. Is this the right Slave, or maybe there is another instance of Slave looking for Master on the same port? Try changing port number on Master and Slave (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 the 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.