improved margings for creating a bounded version of the master thesis
This commit is contained in:
@@ -2,6 +2,250 @@
|
|||||||
|
|
||||||
\label{Introduction}
|
\label{Introduction}
|
||||||
|
|
||||||
This chapter introduces the Clan project, articulates its fundamental
|
\subsection{Motivation}
|
||||||
objectives, outlines the key components, and examines the driving
|
|
||||||
factors motivating its development.
|
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
||||||
|
infrastructure by eliminating single points of failure
|
||||||
|
\cite{shukla_towards_2021}.
|
||||||
|
These architectures underpin a growing range of systems---from IoT
|
||||||
|
edge computing
|
||||||
|
and content delivery networks to blockchain platforms like Ethereum.
|
||||||
|
Yet realizing these benefits requires distributing nodes across
|
||||||
|
genuinely diverse hosting entities.
|
||||||
|
|
||||||
|
In practice, this diversity remains illusory.
|
||||||
|
Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
|
||||||
|
(see Figure~\ref{fig:ethernodes_hosting}),
|
||||||
|
concentrating nominally decentralized infrastructure
|
||||||
|
within a handful of cloud providers.
|
||||||
|
More concerning, these providers operate under overlapping regulatory
|
||||||
|
jurisdictions,
|
||||||
|
predominantly the United States and the European Union.
|
||||||
|
This concentration undermines technical sovereignty:
|
||||||
|
a single governmental action could compel service termination,
|
||||||
|
data disclosure, or traffic manipulation across a majority of the network.
|
||||||
|
|
||||||
|
\begin{figure}[H]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
|
||||||
|
\caption{Distribution of Ethereum nodes hosted by various providers
|
||||||
|
\cite{noauthor_isps_nodate}}
|
||||||
|
\label{fig:ethernodes_hosting}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
Why does this centralization persist despite the explicit goals of
|
||||||
|
decentralization?
|
||||||
|
The answer lies in the practical barriers to self-hosting.
|
||||||
|
Cloud providers offer static IP addresses and publicly routable endpoints,
|
||||||
|
eliminating the networking complexity that plagues residential and
|
||||||
|
small-office deployments.
|
||||||
|
Most internet-connected devices sit behind Network Address Translation (NAT),
|
||||||
|
which prevents incoming connections without explicit port forwarding
|
||||||
|
or relay infrastructure.
|
||||||
|
Combined with dynamic IP assignments from ISPs, maintaining stable
|
||||||
|
peer connectivity
|
||||||
|
from self-hosted infrastructure traditionally required significant
|
||||||
|
technical expertise.
|
||||||
|
|
||||||
|
Overlay VPNs offer a solution to this fundamental barrier.
|
||||||
|
By establishing encrypted tunnels that traverse NAT boundaries,
|
||||||
|
mesh VPNs enable direct peer-to-peer connectivity without requiring
|
||||||
|
static IP addresses or manual firewall configuration.
|
||||||
|
Each node receives a stable virtual address within the overlay network,
|
||||||
|
regardless of its underlying network topology.
|
||||||
|
This capability is transformative:
|
||||||
|
it allows a device behind consumer-grade NAT to participate
|
||||||
|
as a first-class peer in a distributed system,
|
||||||
|
removing the primary technical advantage that cloud providers hold.
|
||||||
|
|
||||||
|
The Clan deployment framework builds on this foundation.
|
||||||
|
Clan leverages Nix and NixOS to eliminate entire classes of
|
||||||
|
configuration errors prevalent in contemporary infrastructure deployment,
|
||||||
|
reducing operational overhead to a degree where a single administrator
|
||||||
|
can reliably self-host complex distributed services.
|
||||||
|
Overlay VPNs are central to Clan's architecture,
|
||||||
|
providing the secure peer connectivity that enables nodes
|
||||||
|
to form cohesive networks regardless of their physical location or
|
||||||
|
NAT situation.
|
||||||
|
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
||||||
|
a web interface that enables users to design and deploy private P2P networks
|
||||||
|
with minimal configuration, assisted by an integrated LLM
|
||||||
|
for contextual guidance and troubleshooting.
|
||||||
|
|
||||||
|
During the development of Clan, a recurring challenge became apparent:
|
||||||
|
practitioners held divergent preferences for mesh VPN solutions,
|
||||||
|
each citing different edge cases where their chosen VPN
|
||||||
|
proved unreliable or lacked essential features.
|
||||||
|
These discussions were largely grounded in anecdotal evidence
|
||||||
|
rather than systematic evaluation.
|
||||||
|
This observation revealed a clear need for rigorous,
|
||||||
|
evidence-based comparison of peer-to-peer overlay VPN implementations.
|
||||||
|
|
||||||
|
Existing research on this topic remains sparse.
|
||||||
|
One notable work from 2024, ``Full-mesh VPN performance evaluation
|
||||||
|
for a secure edge-cloud continuum'' \cite{kjorveziroski_full-mesh_2024},
|
||||||
|
benchmarks a subset of mesh VPNs but focuses primarily
|
||||||
|
on solutions with a central point of failure.
|
||||||
|
In contrast, this thesis evaluates more widely adopted mesh VPNs
|
||||||
|
with an emphasis on fully decentralized architectures.
|
||||||
|
Furthermore, that study relied exclusively on iperf3 for performance
|
||||||
|
measurement,
|
||||||
|
whereas our benchmark suite includes real-world workloads
|
||||||
|
to better reflect practical usage patterns.
|
||||||
|
|
||||||
|
A further motivation was to create a fully automated benchmarking framework
|
||||||
|
capable of generating a public leaderboard,
|
||||||
|
similar in spirit to the js-framework-benchmark
|
||||||
|
(see Figure~\ref{fig:js-framework-benchmark}).
|
||||||
|
By providing an accessible web interface with regularly updated results,
|
||||||
|
we hope to encourage P2P VPN developers to optimize their implementations
|
||||||
|
in pursuit of top rankings.
|
||||||
|
|
||||||
|
\begin{figure}[H]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=1\textwidth]{Figures/krause-js-framework.png}
|
||||||
|
\caption{js-framework-benchmark results for Chrome 144.0
|
||||||
|
\cite{krause_krausestjs-framework-benchmark_2026}}
|
||||||
|
\label{fig:js-framework-benchmark}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\begin{figure}[h]
|
||||||
|
\centering
|
||||||
|
|
||||||
|
% Row 1
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage1.png}
|
||||||
|
\caption{Stage 1}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage2.png}
|
||||||
|
\caption{Stage 2}
|
||||||
|
\end{subfigure}
|
||||||
|
|
||||||
|
\vspace{1em} % Add spacing between rows
|
||||||
|
|
||||||
|
% Row 2
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage3.png}
|
||||||
|
\caption{Stage 3}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage4.png}
|
||||||
|
\caption{Stage 4}
|
||||||
|
\end{subfigure}
|
||||||
|
|
||||||
|
\vspace{1em} % Add spacing between rows
|
||||||
|
|
||||||
|
% Row 3
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage5.png}
|
||||||
|
\caption{Stage 5}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage6.png}
|
||||||
|
\caption{Stage 6}
|
||||||
|
\end{subfigure}
|
||||||
|
|
||||||
|
\vspace{1em} % Add spacing between rows
|
||||||
|
|
||||||
|
% Row 4
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage7.png}
|
||||||
|
\caption{Stage 7}
|
||||||
|
\end{subfigure}
|
||||||
|
\hfill
|
||||||
|
\begin{subfigure}{0.45\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{Figures/vision/stage8.png}
|
||||||
|
\caption{Stage 8}
|
||||||
|
\end{subfigure}
|
||||||
|
|
||||||
|
\caption{Visionary Webinterface to Setup a Clan Family Network}
|
||||||
|
\label{fig:vision-stages}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
|
\subsection{Research Contribution}
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
\subsection{Related Work}
|
||||||
|
|
||||||
|
\subsubsection{Nix: A Safe and Policy-Free System for Software Deployment}
|
||||||
|
|
||||||
|
Nix addresses significant issues in software deployment by utilizing
|
||||||
|
cryptographic hashes to ensure unique paths for component instances
|
||||||
|
\cite{dolstra_nix_2004}. Features such as concurrent installation of
|
||||||
|
multiple versions, atomic upgrades, and safe garbage collection make
|
||||||
|
Nix a flexible deployment system. This work uses Nix to ensure that
|
||||||
|
all VPN builds and system configurations are deterministic.
|
||||||
|
|
||||||
|
\subsubsection{NixOS: A Purely Functional Linux Distribution}
|
||||||
|
|
||||||
|
NixOS extends Nix principles to Linux system configuration
|
||||||
|
\cite{dolstra_nixos_2008}. System configurations are reproducible and
|
||||||
|
isolated from stateful interactions typical in imperative package
|
||||||
|
management. This property is essential for ensuring identical test
|
||||||
|
environments across benchmark runs.
|
||||||
|
|
||||||
|
\subsubsection{A Comparative Study on Virtual Private Networks}
|
||||||
|
|
||||||
|
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate
|
||||||
|
VPN protocols in the context of industrial communication systems (Industry 4.0),
|
||||||
|
benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard.
|
||||||
|
Their analysis focuses on point-to-point protocol performance; throughput,
|
||||||
|
latency, and CPU overhead; rather than overlay network behavior.
|
||||||
|
In contrast, this thesis evaluates VPNs that provide a full data plane
|
||||||
|
with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery.
|
||||||
|
|
||||||
|
\subsubsection{Full-Mesh VPN Performance Evaluation}
|
||||||
|
|
||||||
|
Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a
|
||||||
|
comprehensive evaluation of full-mesh VPN solutions for distributed
|
||||||
|
systems. Their benchmarks analyze throughput, reliability under packet
|
||||||
|
loss, and relay behavior for VPNs including ZeroTier.
|
||||||
|
|
||||||
|
This thesis extends their work in several ways:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Broader VPN selection with emphasis on fully decentralized
|
||||||
|
architectures
|
||||||
|
\item Real-world workloads (video streaming, package downloads)
|
||||||
|
beyond synthetic iperf3 tests
|
||||||
|
\item Multiple impairment profiles to characterize behavior under
|
||||||
|
varying network conditions
|
||||||
|
\item Fully reproducible experimental framework via Nix/NixOS/Clan
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{UDP NAT and Firewall Puncturing in the Wild}
|
||||||
|
|
||||||
|
Halkes and Pouwelse~\cite{halkes_udp_2011} measure UDP hole punching
|
||||||
|
efficacy on a live P2P network using the Tribler BitTorrent client.
|
||||||
|
Their study finds that 79\% of peers are unreachable due to NAT or
|
||||||
|
firewall restrictions, yet 64\% reside behind configurations amenable
|
||||||
|
to hole punching. Among compatible peers, over 80\% of puncturing
|
||||||
|
attempts succeed, establishing hole punching as a practical NAT
|
||||||
|
traversal technique. Their timeout measurements further indicate that
|
||||||
|
keep-alive messages must be sent at least every 55 seconds to maintain
|
||||||
|
open NAT mappings.
|
||||||
|
|
||||||
|
These findings directly inform the evaluation criteria for this thesis.
|
||||||
|
All mesh VPNs tested rely on UDP hole punching for NAT traversal;
|
||||||
|
the 80\% success rate sets a baseline expectation, while the 55-second
|
||||||
|
timeout informs analysis of each implementation's keep-alive behavior
|
||||||
|
during source code review.
|
||||||
|
|
||||||
|
\subsubsection{An Overview of Packet Reordering in TCP}
|
||||||
|
TODO \cite{leung_overview_2007}
|
||||||
|
|
||||||
|
\subsubsection{Performance Evaluation of TCP over QUIC Tunnels}
|
||||||
|
TODO \cite{guo_implementation_2025}
|
||||||
@@ -342,74 +342,3 @@ Every test result includes metadata recording:
|
|||||||
Results are organized hierarchically by VPN, TC profile, and machine
|
Results are organized hierarchically by VPN, TC profile, and machine
|
||||||
pair. Each profile directory contains a \texttt{tc\_settings.json}
|
pair. Each profile directory contains a \texttt{tc\_settings.json}
|
||||||
snapshot of the exact impairment parameters applied.
|
snapshot of the exact impairment parameters applied.
|
||||||
|
|
||||||
\section{Related Work}
|
|
||||||
|
|
||||||
\subsection{Nix: A Safe and Policy-Free System for Software Deployment}
|
|
||||||
|
|
||||||
Nix addresses significant issues in software deployment by utilizing
|
|
||||||
cryptographic hashes to ensure unique paths for component instances
|
|
||||||
\cite{dolstra_nix_2004}. Features such as concurrent installation of
|
|
||||||
multiple versions, atomic upgrades, and safe garbage collection make
|
|
||||||
Nix a flexible deployment system. This work uses Nix to ensure that
|
|
||||||
all VPN builds and system configurations are deterministic.
|
|
||||||
|
|
||||||
\subsection{NixOS: A Purely Functional Linux Distribution}
|
|
||||||
|
|
||||||
NixOS extends Nix principles to Linux system configuration
|
|
||||||
\cite{dolstra_nixos_2008}. System configurations are reproducible and
|
|
||||||
isolated from stateful interactions typical in imperative package
|
|
||||||
management. This property is essential for ensuring identical test
|
|
||||||
environments across benchmark runs.
|
|
||||||
|
|
||||||
\subsection{A Comparative Study on Virtual Private Networks}
|
|
||||||
|
|
||||||
Lackorzynski et al.\ \cite{lackorzynski_comparative_2019} evaluate
|
|
||||||
VPN protocols in the context of industrial communication systems (Industry 4.0),
|
|
||||||
benchmarking OpenVPN, IPSec, Tinc, Freelan, MACsec, and WireGuard.
|
|
||||||
Their analysis focuses on point-to-point protocol performance; throughput,
|
|
||||||
latency, and CPU overhead; rather than overlay network behavior.
|
|
||||||
In contrast, this thesis evaluates VPNs that provide a full data plane
|
|
||||||
with peer-to-peer connectivity, NAT traversal, and dynamic peer discovery.
|
|
||||||
|
|
||||||
\subsection{Full-Mesh VPN Performance Evaluation}
|
|
||||||
|
|
||||||
Kjorveziroski et al.\ \cite{kjorveziroski_full-mesh_2024} provide a
|
|
||||||
comprehensive evaluation of full-mesh VPN solutions for distributed
|
|
||||||
systems. Their benchmarks analyze throughput, reliability under packet
|
|
||||||
loss, and relay behavior for VPNs including ZeroTier.
|
|
||||||
|
|
||||||
This thesis extends their work in several ways:
|
|
||||||
\begin{itemize}
|
|
||||||
\item Broader VPN selection with emphasis on fully decentralized
|
|
||||||
architectures
|
|
||||||
\item Real-world workloads (video streaming, package downloads)
|
|
||||||
beyond synthetic iperf3 tests
|
|
||||||
\item Multiple impairment profiles to characterize behavior under
|
|
||||||
varying network conditions
|
|
||||||
\item Fully reproducible experimental framework via Nix/NixOS/Clan
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsection{UDP NAT and Firewall Puncturing in the Wild}
|
|
||||||
|
|
||||||
Halkes and Pouwelse~\cite{halkes_udp_2011} measure UDP hole punching
|
|
||||||
efficacy on a live P2P network using the Tribler BitTorrent client.
|
|
||||||
Their study finds that 79\% of peers are unreachable due to NAT or
|
|
||||||
firewall restrictions, yet 64\% reside behind configurations amenable
|
|
||||||
to hole punching. Among compatible peers, over 80\% of puncturing
|
|
||||||
attempts succeed, establishing hole punching as a practical NAT
|
|
||||||
traversal technique. Their timeout measurements further indicate that
|
|
||||||
keep-alive messages must be sent at least every 55 seconds to maintain
|
|
||||||
open NAT mappings.
|
|
||||||
|
|
||||||
These findings directly inform the evaluation criteria for this thesis.
|
|
||||||
All mesh VPNs tested rely on UDP hole punching for NAT traversal;
|
|
||||||
the 80\% success rate sets a baseline expectation, while the 55-second
|
|
||||||
timeout informs analysis of each implementation's keep-alive behavior
|
|
||||||
during source code review.
|
|
||||||
|
|
||||||
\subsection{An Overview of Packet Reordering in TCP}
|
|
||||||
TODO \cite{leung_overview_2007}
|
|
||||||
|
|
||||||
\subsection{Performance Evaluation of TCP over QUIC Tunnels}
|
|
||||||
TODO \cite{guo_implementation_2025}
|
|
||||||
@@ -1,173 +0,0 @@
|
|||||||
\chapter{Motivation} % Main chapter title
|
|
||||||
|
|
||||||
\label{Motivation}
|
|
||||||
|
|
||||||
Peer-to-peer architectures promise censorship-resistant, fault-tolerant
|
|
||||||
infrastructure by eliminating single points of failure
|
|
||||||
\cite{shukla_towards_2021}.
|
|
||||||
These architectures underpin a growing range of systems---from IoT
|
|
||||||
edge computing
|
|
||||||
and content delivery networks to blockchain platforms like Ethereum.
|
|
||||||
Yet realizing these benefits requires distributing nodes across
|
|
||||||
genuinely diverse hosting entities.
|
|
||||||
|
|
||||||
In practice, this diversity remains illusory.
|
|
||||||
Amazon, Hetzner, and OVH collectively host 70\% of all Ethereum nodes
|
|
||||||
(see Figure~\ref{fig:ethernodes_hosting}),
|
|
||||||
concentrating nominally decentralized infrastructure
|
|
||||||
within a handful of cloud providers.
|
|
||||||
More concerning, these providers operate under overlapping regulatory
|
|
||||||
jurisdictions,
|
|
||||||
predominantly the United States and the European Union.
|
|
||||||
This concentration undermines technical sovereignty:
|
|
||||||
a single governmental action could compel service termination,
|
|
||||||
data disclosure, or traffic manipulation across a majority of the network.
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=1\textwidth]{Figures/ethernodes_hosting.png}
|
|
||||||
\caption{Distribution of Ethereum nodes hosted by various providers
|
|
||||||
\cite{noauthor_isps_nodate}}
|
|
||||||
\label{fig:ethernodes_hosting}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
Why does this centralization persist despite the explicit goals of
|
|
||||||
decentralization?
|
|
||||||
The answer lies in the practical barriers to self-hosting.
|
|
||||||
Cloud providers offer static IP addresses and publicly routable endpoints,
|
|
||||||
eliminating the networking complexity that plagues residential and
|
|
||||||
small-office deployments.
|
|
||||||
Most internet-connected devices sit behind Network Address Translation (NAT),
|
|
||||||
which prevents incoming connections without explicit port forwarding
|
|
||||||
or relay infrastructure.
|
|
||||||
Combined with dynamic IP assignments from ISPs, maintaining stable
|
|
||||||
peer connectivity
|
|
||||||
from self-hosted infrastructure traditionally required significant
|
|
||||||
technical expertise.
|
|
||||||
|
|
||||||
Overlay VPNs offer a solution to this fundamental barrier.
|
|
||||||
By establishing encrypted tunnels that traverse NAT boundaries,
|
|
||||||
mesh VPNs enable direct peer-to-peer connectivity without requiring
|
|
||||||
static IP addresses or manual firewall configuration.
|
|
||||||
Each node receives a stable virtual address within the overlay network,
|
|
||||||
regardless of its underlying network topology.
|
|
||||||
This capability is transformative:
|
|
||||||
it allows a device behind consumer-grade NAT to participate
|
|
||||||
as a first-class peer in a distributed system,
|
|
||||||
removing the primary technical advantage that cloud providers hold.
|
|
||||||
|
|
||||||
The Clan deployment framework builds on this foundation.
|
|
||||||
Clan leverages Nix and NixOS to eliminate entire classes of
|
|
||||||
configuration errors prevalent in contemporary infrastructure deployment,
|
|
||||||
reducing operational overhead to a degree where a single administrator
|
|
||||||
can reliably self-host complex distributed services.
|
|
||||||
Overlay VPNs are central to Clan's architecture,
|
|
||||||
providing the secure peer connectivity that enables nodes
|
|
||||||
to form cohesive networks regardless of their physical location or
|
|
||||||
NAT situation.
|
|
||||||
As illustrated in Figure~\ref{fig:vision-stages}, Clan envisions
|
|
||||||
a web interface that enables users to design and deploy private P2P networks
|
|
||||||
with minimal configuration, assisted by an integrated LLM
|
|
||||||
for contextual guidance and troubleshooting.
|
|
||||||
|
|
||||||
During the development of Clan, a recurring challenge became apparent:
|
|
||||||
practitioners held divergent preferences for mesh VPN solutions,
|
|
||||||
each citing different edge cases where their chosen VPN
|
|
||||||
proved unreliable or lacked essential features.
|
|
||||||
These discussions were largely grounded in anecdotal evidence
|
|
||||||
rather than systematic evaluation.
|
|
||||||
This observation revealed a clear need for rigorous,
|
|
||||||
evidence-based comparison of peer-to-peer overlay VPN implementations.
|
|
||||||
|
|
||||||
Existing research on this topic remains sparse.
|
|
||||||
One notable work from 2024, ``Full-mesh VPN performance evaluation
|
|
||||||
for a secure edge-cloud continuum'' \cite{kjorveziroski_full-mesh_2024},
|
|
||||||
benchmarks a subset of mesh VPNs but focuses primarily
|
|
||||||
on solutions with a central point of failure.
|
|
||||||
In contrast, this thesis evaluates more widely adopted mesh VPNs
|
|
||||||
with an emphasis on fully decentralized architectures.
|
|
||||||
Furthermore, that study relied exclusively on iperf3 for performance
|
|
||||||
measurement,
|
|
||||||
whereas our benchmark suite includes real-world workloads
|
|
||||||
to better reflect practical usage patterns.
|
|
||||||
|
|
||||||
A further motivation was to create a fully automated benchmarking framework
|
|
||||||
capable of generating a public leaderboard,
|
|
||||||
similar in spirit to the js-framework-benchmark
|
|
||||||
(see Figure~\ref{fig:js-framework-benchmark}).
|
|
||||||
By providing an accessible web interface with regularly updated results,
|
|
||||||
we hope to encourage P2P VPN developers to optimize their implementations
|
|
||||||
in pursuit of top rankings.
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=1\textwidth]{Figures/krause-js-framework.png}
|
|
||||||
\caption{js-framework-benchmark results for Chrome 144.0
|
|
||||||
\cite{krause_krausestjs-framework-benchmark_2026}}
|
|
||||||
\label{fig:js-framework-benchmark}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
\begin{figure}[h]
|
|
||||||
\centering
|
|
||||||
|
|
||||||
% Row 1
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage1.png}
|
|
||||||
\caption{Stage 1}
|
|
||||||
\end{subfigure}
|
|
||||||
\hfill
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage2.png}
|
|
||||||
\caption{Stage 2}
|
|
||||||
\end{subfigure}
|
|
||||||
|
|
||||||
\vspace{1em} % Add spacing between rows
|
|
||||||
|
|
||||||
% Row 2
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage3.png}
|
|
||||||
\caption{Stage 3}
|
|
||||||
\end{subfigure}
|
|
||||||
\hfill
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage4.png}
|
|
||||||
\caption{Stage 4}
|
|
||||||
\end{subfigure}
|
|
||||||
|
|
||||||
\vspace{1em} % Add spacing between rows
|
|
||||||
|
|
||||||
% Row 3
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage5.png}
|
|
||||||
\caption{Stage 5}
|
|
||||||
\end{subfigure}
|
|
||||||
\hfill
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage6.png}
|
|
||||||
\caption{Stage 6}
|
|
||||||
\end{subfigure}
|
|
||||||
|
|
||||||
\vspace{1em} % Add spacing between rows
|
|
||||||
|
|
||||||
% Row 4
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage7.png}
|
|
||||||
\caption{Stage 7}
|
|
||||||
\end{subfigure}
|
|
||||||
\hfill
|
|
||||||
\begin{subfigure}{0.45\textwidth}
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{Figures/vision/stage8.png}
|
|
||||||
\caption{Stage 8}
|
|
||||||
\end{subfigure}
|
|
||||||
|
|
||||||
\caption{Visionary Webinterface to Setup a Clan Family Network}
|
|
||||||
\label{fig:vision-stages}
|
|
||||||
\end{figure}
|
|
||||||
28
main.tex
28
main.tex
@@ -25,10 +25,10 @@
|
|||||||
|
|
||||||
\documentclass[
|
\documentclass[
|
||||||
11pt, % The default document font size, options: 10pt, 11pt, 12pt
|
11pt, % The default document font size, options: 10pt, 11pt, 12pt
|
||||||
oneside, % Two side (alternating margins) for binding by default,
|
oneside,%twoside, % Two side (alternating margins) for binding by default,
|
||||||
% uncomment to switch to one side
|
% uncomment to switch to one side
|
||||||
english, % ngerman for German
|
english, % ngerman for German
|
||||||
singlespacing, % Single line spacing, alternatives: onehalfspacing
|
onehalfspacing, % Single line spacing, alternatives: onehalfspacing
|
||||||
% or doublespacing
|
% or doublespacing
|
||||||
%draft, % Uncomment to enable draft mode (no pictures, no links,
|
%draft, % Uncomment to enable draft mode (no pictures, no links,
|
||||||
% overfull hboxes indicated)
|
% overfull hboxes indicated)
|
||||||
@@ -75,13 +75,12 @@
|
|||||||
%----------------------------------------------------------------------------------------
|
%----------------------------------------------------------------------------------------
|
||||||
|
|
||||||
\geometry{
|
\geometry{
|
||||||
paper=a4paper, % Change to letterpaper for US letter
|
paper=a4paper,
|
||||||
inner=2.5cm, % Inner margin
|
inner=3.0cm, % Bindungsseite – braucht mehr Platz
|
||||||
outer=3.8cm, % Outer margin
|
outer=2.5cm, % Außenseite
|
||||||
bindingoffset=.5cm, % Binding offset
|
bindingoffset=0.5cm, % Zusätzlich für Klebebindung
|
||||||
top=1.5cm, % Top margin
|
top=2.5cm,
|
||||||
bottom=1.5cm, % Bottom margin
|
bottom=2.0cm,
|
||||||
%showframe, % Uncomment to show how the type block is set on the page
|
|
||||||
}
|
}
|
||||||
|
|
||||||
%----------------------------------------------------------------------------------------
|
%----------------------------------------------------------------------------------------
|
||||||
@@ -91,7 +90,7 @@
|
|||||||
\thesistitle{Decrypting the Overlay: A Reproducible Analysis of P2P
|
\thesistitle{Decrypting the Overlay: A Reproducible Analysis of P2P
|
||||||
VPN Implementation and Overhead} % Your thesis title, this is used in the title
|
VPN Implementation and Overhead} % Your thesis title, this is used in the title
|
||||||
% and abstract, print it elsewhere with \ttitle
|
% and abstract, print it elsewhere with \ttitle
|
||||||
\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is
|
%\supervisor{\textsc{Ber Lorke}} % Your supervisor's name, this is
|
||||||
% used in the title page, print it elsewhere with \supname
|
% used in the title page, print it elsewhere with \supname
|
||||||
\examiner{Prof. Dr. \textsc{Stefan Schmid}} % Your examiner's name,
|
\examiner{Prof. Dr. \textsc{Stefan Schmid}} % Your examiner's name,
|
||||||
% this is not currently used anywhere in the template, print it
|
% this is not currently used anywhere in the template, print it
|
||||||
@@ -158,11 +157,11 @@ and Management}} % Your department's name and URL, this is used in
|
|||||||
\begin{minipage}[t]{0.4\textwidth}
|
\begin{minipage}[t]{0.4\textwidth}
|
||||||
\begin{flushright} \large
|
\begin{flushright} \large
|
||||||
\emph{First Examiner:} \\
|
\emph{First Examiner:} \\
|
||||||
\textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmidt}}\\[1em]
|
\textcolor{mdtRed}{Prof.\ Dr.\ \textsc{Stefan Schmid}}\\[1em]
|
||||||
\emph{Second Examiner:} \\
|
\emph{Second Examiner:} \\
|
||||||
\textcolor{mdtRed}{\textsc{[TBD]}}\\[1em]
|
\textcolor{mdtRed}{\textsc{[TBD]}}\\[1em]
|
||||||
\emph{Supervisor:} \\
|
%\emph{Supervisor:} \\
|
||||||
\textcolor{mdtRed}{\supname}
|
%\textcolor{mdtRed}{\supname}
|
||||||
\end{flushright}
|
\end{flushright}
|
||||||
\end{minipage}\\[2cm]
|
\end{minipage}\\[2cm]
|
||||||
|
|
||||||
@@ -350,10 +349,9 @@ and Management}} % Your department's name and URL, this is used in
|
|||||||
|
|
||||||
% Include the chapters of the thesis as separate files from the Chapters folder
|
% Include the chapters of the thesis as separate files from the Chapters folder
|
||||||
% Uncomment the lines as you write the chapters
|
% Uncomment the lines as you write the chapters
|
||||||
\include{Chapters/Motivation}
|
\include{Chapters/Introduction}
|
||||||
\include{Chapters/Methodology}
|
\include{Chapters/Methodology}
|
||||||
|
|
||||||
\include{Chapters/Introduction}
|
|
||||||
|
|
||||||
%\include{Chapters/Chapter1}
|
%\include{Chapters/Chapter1}
|
||||||
%\include{Chapters/Chapter2}
|
%\include{Chapters/Chapter2}
|
||||||
|
|||||||
Reference in New Issue
Block a user