Real-time communication

BroadcastGraphics uses WebSocket connections to keep every renderer and every control panel in sync with the server. The technology is Socket.IO under the hood.

Rooms

Each output has its own room. Control panels that drive that output and renderers that display it all join the same room. Commands and state updates flow only to rooms that need them — a command on one output does not leak into another.

What travels on the wire

• Commands from control panels to the server: Take, Out, Pause, Continue, row change, data change.
• State broadcasts from the server to all clients in the room: "layer X is now live", "dataset Y updated".
• Status pings so everyone knows who is connected.

The actual pixel rendering happens in the renderer's browser; the server never sends images.

Latency

On a healthy connection, the round-trip from Take to on-air is under 100 ms. Most of that is in the animation itself — the network contribution is usually a handful of milliseconds.

Reconnect behaviour

If a client drops the connection, it re-joins on reconnect and the server re-pushes the current state. The renderer keeps the last frame on screen during the outage so the broadcast is not interrupted.

What you cannot do

• Broadcast from control panel A to renderer B (they must be in the same output's room).
• Bypass the server (every command goes through it; peer-to-peer is not supported).
• Persist commands across server restarts (state is in-memory; re-take when the server restarts).