Architecture Overview

A WebStream ACP session follows a simple path: the browser connects to a gateway, the gateway routes the session to a host, and the host runs the Windows application and streams it back. Policy is enforced at the host, where the interaction actually happens.

The request path

1. Browser. The user opens their workspace over HTTPS. No client install is required.
2. Gateway. Terminates the connection, authenticates the user, and routes them to an appropriate session host. The gateway is stateless and can scale horizontally.
3. Session host. Runs the Windows application in a streamer process and enforces the assigned policy — files, printing, clipboard, and network.
4. Windows application. The unmodified application runs as normal; ACP mediates how the user interacts with it.

Why enforcement at the host matters

Because policy is applied where files are opened and saved, where print jobs are produced, and where clipboard data moves, ACP can govern those interactions precisely — something a pure transport layer like a VPN cannot do.

Session lifecycle

A session is more than one request. From launch to logout the Gateway keeps all of a user's traffic coherent — many HTTP calls and long-lived WebSockets, all landing on the same session host.

1. Launch. The browser posts /gateway/session/select with the chosen workspace. The gateway validates the user's entitlement, reserves a concurrency slot, picks a backend by load-balancing strategy, and pins the browser session (its X-Session-ID) to that backend — this is session affinity.
2. Repeat requests, same backend. Once affinity is set, every follow-on request for that session — /getConnection and the /capture, /control, and /audio WebSockets — routes to the same backend and streamer. WebSocket routing requires affinity: per-session state lives on that host, so multiple access requests within one session never spread across backends.
3. Connection queuing. On the backend, the disk-heavy part of a session start (profile preparation and RDP logon) runs one at a time. Under a burst of launches, users are routed to their pinned host and the browser shows preparing while each start waits its turn. If the whole cluster has no free slots, a new launch is answered with capacity_reached instead (auto-scaling, where configured, then adds a host). See Session Host for the queue settings.
4. Multiple workspaces. Concurrent workspaces per user are governed by workspace leases. Relaunching a workspace that is already live in another browser session returns WORKSPACE_ALREADY_ACTIVE; exceeding the concurrent-workspace limit returns MAX_WORKSPACES_REACHED. Limits are set in the Session Lifecycle policy.
5. Reconnect. After a network drop or page refresh, the client preflights /gateway/session/status; affinity returns it to the same live session on the same host rather than starting a new one.
6. Logout / disconnect. Ending the workspace posts /gateway/session/release, freeing the concurrency slot. When the streamer exits it checks out of the licence registry (/gateway/license/streamer-checkout) and the workspace lease is released; the session host then recycles the pool account — profile cleanup and NTFS ACL enforcement — ready for the next user. An operator can force-end a live session from Operations or via the MCP sessions_disconnect tool.