All signage players supporting the Xibo CMS communicate over “web services”. These are available on the CMS via normal HTTP or secure HTTPS connections (the same communication method used to view web pages).
Each player has a Collection Interval which determines how often they connect to the CMS to download updated schedule information and new content.
There are 8 pieces of information regularly exchanged between Players and the CMS.
- Required Files
- File Download
- Resource Download *
- Media Inventory Status
- Proof of Play Statistics
The 1.7 CMS introduced 2 more
- Screenshot *
- Status *
The starred services communicate outside the collection interval because they are driven be events that occur during normal running of the player.
Resources include anything required by the Player which is not a media file stored in the library. Examples of this are RSS Feeds, Twitter Feeds, Text on Layouts. How often these are requested is controlled by the update interval set on that media. If there isn’t an update interval then a default of 5 minutes is applied.
After the first time resources are downloaded, they are only updated when they are shown on a Layout.
Widgets like web pages and embedded HTML may also request connection to external resources (or even the CMS, depending how the widget has been designed). These will only be requested when they are shown on a Layout.
From Xibo 1.8 onwards, the Player also makes a connection to the XMR (Xibo Message Relay) server, if it has been setup and configured to do so, on TCP port 9505. This allows the Player to receive real-time encrypted messages from the CMS so that it can act upon those messages more quickly than a periodic background poll as describe above would allow. For example it might tell the Player to send back a screenshot, or to poll again right now.
Xibo in the Cloud Players will download media items from a pool of servers dedicated to file downloads rather than asking the CMS for those files directly. Those files are transferred over HTTP or HTTPS (the same scheme is used as you have specified in the URL used to connect to the CMS) and the downloads are authenticated in the same way as they would be if downloaded directly from the CMS.