230 lines
8.7 KiB
TeX
230 lines
8.7 KiB
TeX
% Created 2025-10-08 Wed 17:17
|
|
% Intended LaTeX compiler: pdflatex
|
|
\documentclass[11pt]{article}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage{graphicx}
|
|
\usepackage{longtable}
|
|
\usepackage{wrapfig}
|
|
\usepackage{rotating}
|
|
\usepackage[normalem]{ulem}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{capt-of}
|
|
\usepackage{hyperref}
|
|
\author{Akilan}
|
|
\date{\today}
|
|
\title{}
|
|
\hypersetup{
|
|
pdfauthor={Akilan},
|
|
pdftitle={},
|
|
pdfkeywords={},
|
|
pdfsubject={},
|
|
pdfcreator={Emacs 30.1 (Org mode 9.7.11)},
|
|
pdflang={English}}
|
|
\begin{document}
|
|
|
|
\section{Xplane WebRTC}
|
|
\label{sec:orgc15d32b}
|
|
\begin{center}
|
|
\includegraphics[width=.9\linewidth]{./xprc.drawio.png}
|
|
\end{center}
|
|
|
|
The Xplane WebRTC project takes inspiration from Google Stadia
|
|
for a streaming based solution for playing video games. But our
|
|
plan is to build one specifically for flight simulators. We target
|
|
Xplane 11 for being cross platform and completely offline dependent
|
|
on sceneries with reasonable documentation on usage of the SDK to use the game.
|
|
The novelty of the project being all aspects of the project will be completely open source.
|
|
There are already major segments of the project complete and have been tested which will
|
|
be mentioned in the appropriate section for the necessary details. I am also investing
|
|
in my PhD to familiarize myself to work with slim down kernels on HPC scenarios
|
|
(This will help me extend the Xplane to run on a distributed scenario). This
|
|
project is fun long term work and has no heavy deadlines but rather the art of
|
|
optimizing the current paradigm of how we use heavy workload applications.
|
|
The following above is a really high level abstraction description of the
|
|
projects and barely covers the depth of what the project intends to push forward.
|
|
|
|
The big question is what parts have been rebuilt for the project and how they
|
|
contribute to the end goal of the project. The first property of the project is
|
|
that it should be able to run on a p2p network. P2PRC is a p2p orchestrator designed
|
|
to run applications in a p2p network using Containers initially. There are plans to
|
|
extend it to run on Uni-kernels and based on my PhD extend it to run on a Multi-kernel
|
|
paradigm as well. This will be our custom alternative to Kubernetes which will be used to
|
|
distribute and run on workloads on p2p effectively. This would make our entire run on
|
|
Anyone's machine which can reside behind NAT.
|
|
|
|
We also intend to make an open source solution to distribute a slim down version of X Plane
|
|
so that nodes can quickly Spawn Xplane instantly with only the required scenery needed.
|
|
This will be in contrast to running the full scenery of the game which is around 55 GB.
|
|
Something novel that could be worked on here is a novel approach to only send the scenery
|
|
of the flight path when distributing the game. This will mean building parsers for the
|
|
Xplane scenery files and then finding techniques to only get a correct set of scenery
|
|
files needed in other machines. The techniques are expected to open source but since the
|
|
scenery files are proprietary they are expected to be public.
|
|
|
|
The streaming part of the project is expected to use the browser standard WebRTC sockets
|
|
with the corresponding sockets. This is because there is already massive development
|
|
of the chromium browser with GPU encoders and decoders for faster performance.
|
|
We have already built a prototype which has been tested and seems to work as intended.
|
|
|
|
The PhD will be one of a long term novel approach which will support Multi-kernels with
|
|
TAG based architecture support for running C++ programs more securely. This might mean
|
|
most parts of the PhD might not be used. The Multi-kernel approach is definitely an
|
|
interesting area to experiment on to figure out how the project would use such an
|
|
approach and this open lot of areas of future research and hopefully better
|
|
performant flight simulators with better purposed algorithm to offload tasks to
|
|
devices such as FPGAs or potato machines in abstraction layer similar to speaking nodes in an network.
|
|
\section{Architecture}
|
|
\label{sec:org858acc8}
|
|
This chapter dives into the high architecture design of the
|
|
project and each module is communicated in detail on the following
|
|
section below.
|
|
\begin{figure}[htbp]
|
|
\centering
|
|
\includegraphics[height=500px]{./Flightsimarch.drawio.png}
|
|
\caption{High level architecture of the entire project}
|
|
\end{figure}
|
|
\subsection{Game allocator}
|
|
\label{sec:orga2f79cd}
|
|
The game allocator stores information about the game sessions. This consists of attributes
|
|
such as:
|
|
\begin{verbatim}
|
|
- Game Session ID <UUID>
|
|
- Session name <String>
|
|
- Nodes Running the game [
|
|
{ Rendered Node IP <String>
|
|
Rendered Node Specs <Node Specs>
|
|
Flight Route Path loaded <TBD when network
|
|
scenery files
|
|
defined>
|
|
User on Node <UUID>
|
|
Flight Sim API url <String>
|
|
} ..... N ]
|
|
- Instructor ID <String>
|
|
\end{verbatim}
|
|
|
|
|
|
The following above shows a high level data structure for storing session
|
|
information. A session consists of multiple pilots training with a single
|
|
instructor. Each pilot is assigned a node to render the game remotely
|
|
and the instructor can set the scenarios to be trained on.
|
|
\subsubsection{Interfaces}
|
|
\label{sec:orgfc05025}
|
|
We will now motivate the higher level interfaces to construct a \uline{game allocator}
|
|
this term is inspired from the use of terms like \emph{malloc} and \emph{free} in userspace
|
|
for allocating memory in a kernel.
|
|
|
|
\begin{verbatim}
|
|
Instructor = AddInstructor(<Instructor object>)
|
|
\end{verbatim}
|
|
This function creates a insturctor in database.
|
|
|
|
\begin{verbatim}
|
|
Player = AddPlayer(<player object>)
|
|
\end{verbatim}
|
|
Creates a player (i.e trainer) to the database.
|
|
|
|
\begin{verbatim}
|
|
NodePlayer = AllocateNode(<player object>)
|
|
\end{verbatim}
|
|
Finds a free node varaible and adds allocates
|
|
a player to it based on least latency.
|
|
|
|
\begin{verbatim}
|
|
FreeNode(NodePlayer)
|
|
\end{verbatim}
|
|
Frees the player from the node. Normally called
|
|
after the end of the flight session.
|
|
|
|
\begin{verbatim}
|
|
Node = AddNode(<register node information>)
|
|
\end{verbatim}
|
|
Adds a node that can redered the flight sim
|
|
into the network.
|
|
|
|
\begin{verbatim}
|
|
FreeNode(Node)
|
|
\end{verbatim}
|
|
Removes the flight sim render node
|
|
from the network.
|
|
|
|
\begin{verbatim}
|
|
Session = CreateSession([Player],...n],[Instuctor,...n])
|
|
\end{verbatim}
|
|
Create session of players mapped and adds
|
|
instructors to the session. This function
|
|
is a high level function that encapsulates
|
|
\emph{AllocateNode} and maps it to \emph{Instructors}.
|
|
|
|
\begin{verbatim}
|
|
FreeSession(Session)
|
|
\end{verbatim}
|
|
Free the entire session created.
|
|
\section{Render machine}
|
|
\label{sec:orga549ee2}
|
|
\uline{Note: We do not talk about how the game}
|
|
\uline{itself is deployed here and we assume that
|
|
the game is avaliable to execute.}
|
|
|
|
This node is incharge of computing the game
|
|
in it's CPU and GPU. This layer does not
|
|
distinguish if the game is running bare-metal
|
|
or on a virtualised environment but rather
|
|
focuses on game itself is rendered and
|
|
is pass through the \emph{user machine}. Xplane
|
|
is called using the binary.
|
|
locally on the machine and the instructions
|
|
relating to which window it's running is
|
|
\uline{yet to be decided (This is considered a todo}).
|
|
This section is split into 3 parts:
|
|
\begin{itemize}
|
|
\item Streaming part
|
|
\item Keyboard and mouse passthrough
|
|
\item API layer
|
|
\end{itemize}
|
|
\subsection{Streaming part}
|
|
\label{sec:org7a44338}
|
|
The flight sim session is streamed using
|
|
WebRTC. We will initially hook a chromuim
|
|
browser to detect the screen and over time
|
|
reduce this to a simple screencapture
|
|
native program to stream the video feed.
|
|
|
|
\uline{TODO: Specifics to be documented.}
|
|
\subsection{Keyboard and mouse passthrough}
|
|
\label{sec:orga1a7e26}
|
|
We plan to maintain a open source fork
|
|
of InputLeap. Input Leap is software that
|
|
mimics the functionality of a KVM switch,
|
|
which historically would allow you to use
|
|
a single keyboard and mouse to control
|
|
multiple computers by physically turning
|
|
a dial on the box to switch the machine
|
|
you're controlling at any given moment.
|
|
Input Leap does this in software,
|
|
allowing you to tell it which machine to
|
|
control by moving your mouse to the edge
|
|
of the screen, or by using a keypress to
|
|
switch focus to a different system.
|
|
|
|
\uline{TODO: Diagramtic explaination of setup.}
|
|
\subsection{API layer}
|
|
\label{sec:org5b1f52a}
|
|
We use the Xplane API REST server and UDP calls
|
|
to transmit data back to the
|
|
\emph{Instructor machine} for further analyses
|
|
and controlling the flight scenarious.
|
|
We will implement our own wrapper on
|
|
top of the Xplane API to create standarised
|
|
controls no matter the version of the flight
|
|
sim and we can more fine system control
|
|
such as new scenery files to pull.
|
|
|
|
\uline{TODO: Internal Xplane APIs to use, Extact routes}
|
|
\_and relation to transmitted to the instructor server.
|
|
\section{Network of Scenery files}
|
|
\label{sec:org61f9966}
|
|
Not documented until mid 2026.
|
|
\end{document}
|