Cinegy Route Directory Service is quick and easy to set up, and works great in small to medium size environments. However, once the number of connected clients increases, or network topology becomes more complex, the polling request model becomes limited.
To address this, Cinegy Route comes with the Route Directory Relay Service, a dedicated service for tracking changes on a central Route Directory Service and notifying the broadcast clients about them over multicast, reducing network load and the load on the core Route service.
Using Cinegy Route Directory Relay Service is an advanced option. It requires the installing engineer to have skills in network configuration, multicast adjustment and routing, as well as packet inspection to verify correct operations and perform any multicast troubleshooting.
Cinegy Route Directory Relay Service tracks changes on Cinegy Route Directory Service and sends them to the signal receivers. It is started automatically as a Windows service, and is configured with a single XML file. Installation of this service is optional, and in many cases the Cinegy Route Directory Service will function seamlessly without the installation of the relay service.
The following diagram shows the general channel relay workflow, in normal operation:
As shown above, Cinegy Route Directory Relay Service sends requests to Cinegy Route Directory Service for information about changes in the physical sources and virtual destinations configuration. If any changes are found, they are sent to the network as a multicast data stream, which any broadcast clients discover by checking a fixed multicast address for changes that are applicable to them. Then clients adjust to the change with no communication to Cinegy Route Directory Service required.
When the relay multicast messages are not received by a client for more than 10 seconds, for example because of connection loss or the service being stopped, the client will try to directly connect to the main Cinegy Route Directory Service. In case of failure to connect, the last known configuration is retained until messages are recovered. The following diagram shows this configuration model: