vif Session Fleet
Ask for a dedicated session, join it from a terminal or this browser
Fleet
This page needs JavaScript: it talks to the session API and streams log records over the same origin.
The page script did not load, so nothing here is live. Reload the page; if it persists, the console will name the reason.
One request starts one session: a Kubernetes Job whose pod runs the game, behind its own Service. The allocator answers once the pod is ready, the Service has an endpoint and the game responds, so this can take up to about a minute.
No session selected. Request one, or pick an active session below.
Session
—- Terminal
—- Browser
- Open in a new tab ↗
- Players
- —
- Tick
- —
- Expires in
- —
Reading the fleet…
How it works
- Request
- The button posts the options picked above, or an empty object when every one is left on the allocator default. One Job and one Service it owns are created, and the Job's pod runs the game container. The response arrives only once the pod is ready, the Service has a ready endpoint and the game answers — there is no second readiness check to wait through.
- Options
- Scenario, players and session log level list what the allocator reports, refreshed on every poll; it reads its scenario volume on every request, so the scenarios can change while this page is open. A value it still refuses comes back with its reason, and Allocator default leaves the choice to the allocator's own configuration.
- Terminal
- The card shows the whole
vif -joincommand for a native build. Its address is the session Service's NodePort, what Docker would call a published port: raw TCP to the node, not through the web server, and unaffected by anything on this page. - Browser
- The same session in the browser build, opened in a new tab and joined over a WebSocket on this origin. It reaches the session's pod through the web server and the allocator, which checks the origin and the session's own readiness before it upgrades anything. The game protocol is the one a terminal build speaks; only the path to it differs. The link appears only when the deployment publishes a browser route, and like the terminal command it can be copied and handed to another player.
- First join
- A 90-second window starts the moment the session is handed over; the card counts it down as Join within. Nobody arriving in it ends the session, and its capacity returns to the fleet.
- Ending
- A session ends itself when its roster empties for the grace period. There is no delete button here on purpose: an anonymous caller must not be able to end somebody else's game.
- At capacity
- The fleet's capacity is ten concurrent sessions, enforced in the cluster by a ResourceQuota rather than by this page. At capacity the allocator answers with a retry delay, which the page waits out rather than retrying immediately.
- Logs
- The record stream is a separate route and fails on its own. If it is down the fleet summary and the game keep working; the panel says so rather than implying an outage.
Session log
Every active session's records, live over the same origin. Filter to one session to follow it alone. The stream and the fleet summary fail independently.
Connecting…