...
How does BSN.Cloud notify the player of new BrightAuthor:connected content?
| Expand | ||
|---|---|---|
| ||
All connected and healthy players establish and keep persistent WebSocket connections with bsn.Content. If a player has "BSN" setup type and an active subscription, it will receive events from the server when either its settings or schedule are changed by any user in BrightAuthor:connected. The event propagation should take not more than few minutes (typically one minute), and the player requests the new settings or schedule immediately after receiving such an event. |
How does BSN.cloud notify the player of new BrightAuthor:connected content?
| Expand | ||
|---|---|---|
| ||
If a player is active, has a WebSockets connection, and a change was made in the schedule or settings (not in the playlist or feed) the player gets only a notice, not the actual content. After getting the notice, it sends one or more requests to retrieve the updated Schedule/Settings. Dynamic Playlists, Tagged Playlists, Live Data Feeds and Live Media Feeds changes are propagated differently. Each of these entities has an underlying mRSS feed, and after retrieving them from the presentation, a player checks for changes in each feed separately with a frequency defined by the |
Do the logs show when there has been a successful sync with the cloud?
| Expand | ||
|---|---|---|
| ||
You can look for the |
...
as well. |
Do I need to configure my firewall to accept any inbound connections from BSN.Cloud?
| Expand | ||
|---|---|---|
| ||
BrightSign No. BSN.Cloud does not initiate any contact with BrightAuthor:connected or players. Users initiate BrightSign software (BrightAuthor:connected, BOS, autoruns, plugins, etc.) initiates connections, send requests, or subscribe to events, and the server replies. There are no cases when a server sends a request to a player, which would be impossible in most cases anyway since players are behind firewalls/gateways. |
...
The BSN.cloud Ports and URLs for Players and Software page lists the services and ports which BrightAuthor:connected and players access in outbound connections. |
Do I need to allow outbound connections from Players to TCP port 80? If so, why?
| Expand | ||
|---|---|---|
| ||
Yes, at least one service requires this, but there nothing sensitive in that traffic. Only two server endpoints listen on TCP port 80 and do not require transport-level encryption (as described on this page):
The first is an NTP server and has other endpoints as well, and the second is used only to check the connection with the cloud at the early stages of the BOS boot. In both cases, it is impossible to use TLS because the handshake and certificate validation are possible only when boot is finished and the player's clock is initialized correctly. |