Where the two screens plug in

The picture above puts both screens on one PC. That is the usual case, but not the only one — and the good news is that the choice changes nothing in your code.

The tablet works out its WebSocket address from the address of the page it was loaded from. So whichever machine serves the page is the machine the tablet talks to. Pointing a browser at a different address is the entire configuration. There is no list of IPs to maintain anywhere.

Two questions decide which one you are building:

  1. Is Unreal on site, or somewhere else? On site → A, B or C. Somewhere else → D or E.

  2. How many machines on site? One → A, B or D. Two → C or E.

Find yours in this table, then read only that one section.

Scenario Machines on site Where Unreal runs Big screen Touchscreen

A

Avatar only, no tablet

1

on site

Unreal, full screen

B

One PC, both screens

1

on site

Unreal, full screen

browser on display 2

C

Powerful PC + mini-PC, both on site

2

on site

Unreal, full screen

browser on a mini-PC

D

Streamed, one mini-PC for both screens

1

remote

browser showing a video stream

browser on display 2

E

Streamed, one mini-PC per screen

2

remote

browser showing a video stream

browser on its own box

Every one of these needs a working internet connection. The avatar’s conversation happens on our backend, not on the machine in the room. Nothing runs off-line: a kiosk with the cable out cannot talk to anybody, and will take itself out of service and say so.

What separates them is where the rendering happens. In A, B and C the avatar is drawn on site, and only the conversation crosses the internet — a modest, forgiving amount of traffic. In D and E the avatar is drawn elsewhere and arrives as video, bringing a continuous multi-megabit stream and a networking problem the others lack.

Before you choose D or E, check that you actually need them. Streaming is for when Unreal genuinely cannot be near the screen: another building, another city, or a cloud machine. If the PC is merely down the corridor in a machine room, run a cable instead. If the LAN cable reaches, a DisplayPort or HDMI extender almost always reaches too, over fibre if it is far. This turns the job back into scenario B or C, which is cheaper, sharper, has no latency, and skips every problem in the next three sections. Streaming buys you distance; do not pay for it if you do not need it.

A — One PC, big screen only

No tablet at all. Unreal runs full screen and that is the whole installation. The tablet is optional — you are not switching anything off, you simply never open the browser. Nothing else about the setup changes.

The control channel is still running. If you later want a tablet, a phone, or your own building-management system to press Start, it can connect without you redeploying anything.

There is nothing to lock down. The channel only lets a connection act without a token when it came from this very machine; anything off the network must present one. See locking the control channel to confirm what you have.

B — One PC, big screen + touchscreen

The usual installation. One PC drives both screens: Unreal fills the big one, and a browser on the touchscreen shows the tablet page served by the same PC.

Unreal, full screen browser 127.0.0.1:8080 one PC

The tablet’s address is http://127.0.0.1:8080/. The traffic never leaves the machine, so there is no firewall rule to write and no AuthToken to set. Open the browser on the second display, as described in Opening the page so a visitor cannot leave it.

C — Powerful PC for the avatar + mini-PC for the tablet

Both machines are on site, on the same network — nothing is streamed. The powerful PC runs Unreal and drives the big screen. A cheap mini-PC sits behind the touchscreen doing nothing but showing a browser.

This is scenario B split across two machines. It is often the better approach because the browser cannot compete with the avatar for CPU or GPU. It also lets you place the expensive machine somewhere ventilated and out of reach, leaving only a cheap box behind the touchscreen.

Unreal, full screen browser 192.168.1.50:8080 same network the Unreal PC a mini-PC

The tablet’s address becomes the Unreal PC’s address on the LAN. Three things to get right:

  • Open two ports on the Unreal PC’s firewall — the page (8080) and the control channel (9010). Make them port rules and apply them to every network profile. A venue’s Wi-Fi is routinely classified "Public", leaving a "Private" rule enabled but doing nothing. Third-party security suites usually need their own rule too, as their filters are independent of the Windows firewall.

  • Give the Unreal PC a fixed address, or a DHCP reservation. The mini-PC has it written down.

  • Nothing, to get it working — the mini-PC’s tablet reaches port 9010 and both sides already share a token. However, because that token is printed in this guide, replace it on a venue LAN or shared network: see locking the control channel.

The mini-PC does not have to run Windows. The tablet is an ordinary web page, so anything with a browser will do — see What to run it all on below.

D — Streamed, one mini-PC driving both screens

Unreal runs in a machine room or another building, and the big screen shows a video stream of it. Both screens are now web pages — the big one is the streaming player, the touchscreen is the tablet — and one mini-PC on site drives both.

browser: video stream browser the tablet one mini-PC on site internet Unreal runs elsewhere

The cheapest on-site hardware of any scenario: one box, no GPU work beyond decoding video. Two things this shape needs that the others do not:

  • Two browser windows, each with its own profile. Without a separate --user-data-dir, the second launch hands its URL to the already-running browser and silently ignores the monitor you asked for — see Opening the page.

  • A box big enough for both jobs. This one mini-PC decodes a live video stream and runs the tablet page in two browser windows at once. Video decoding is much heavier, and shows when the machine runs short: the picture stutters or drops frames. If this happens, the box is undersized. Move to E and give each screen its own machine, or buy a bigger one. Check for hardware video decoding (most mini-PCs have it; make sure the browser is using it).

E — Streamed, one mini-PC per screen

The same as D, split across two boxes: one drives the big screen and its streaming player, the other drives the touchscreen and the tablet. Nothing is shared between them.

browser: video stream browser the tablet mini-PC #1 mini-PC #2 internet Unreal runs elsewhere

Each box has exactly one display, so each is configured for its primary screen. Neither needs monitor-pinning or profile juggling. This makes it the simpler of the two streamed shapes to set up, at the cost of a second box. It is also the easiest to lock down, because each machine has one job and can be an appliance.

What D and E both need

The tablet must reach Unreal’s 8080 and 9010 across the internet, not just a LAN. Getting the packets there is your decision — a tunnel or a reverse proxy, not the ports opened directly. However, whoever ends up able to reach them must not be able to use them, and that half has an answer: locking the control channel.

If you put two browser windows on one mini-PC, give each its own browser profile — see the warning in Opening the page. Without it, the second window silently ignores which monitor you asked for.

The big screen’s player is a separate piece of software from this repo — see the notes below.