%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass[12pt,a4paper]{book} % o article, book, ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% packages...
\usepackage[utf8]{inputenc}
\usepackage[english, italian]{babel}
\usepackage[hyphens]{url}
%\usepackage{showframe}

% Per generare il file PDF aderente alle specifiche PDF/A-1b. Verificarne poi la validità.
\usepackage{colorprofiles}
\usepackage[a-2b,mathxmp]{pdfx}

\usepackage{hyperref}
\hypersetup{
    colorlinks,
    linkcolor={black!100!black},
    citecolor={blue!100!black},
    urlcolor={blue!100!black}
}

\usepackage{biblatex}
\bibliography{Biblio.bib}

\usepackage{graphicx}

\usepackage{geometry}

\usepackage{tabularx}

\usepackage{booktabs}

\usepackage{float}

\usepackage{caption}
\captionsetup[figure]{labelsep=period}

\usepackage{lipsum} % Per inserire testo a caso in attesa di realizzare i capitoli

\usepackage{listings} % Per inserire codice formattato
%\lstset{
	%lstset va usato dopo l'inizio del document e ogni volta che si vuole cambiare/impostare il linguaggio da formattare
	% language=bash
	%frame=single,
	%breaklines=true,
	%postbreak=\raisebox{0ex}[0ex][0ex]{\ensuremath{\color{red}\hookrightarrow\space}},
	%basicstyle=\ttfamily\footnotesize
%}

\usepackage{csquotes}

\usepackage{epigraph} % per le frasi inizio capitolo

\usepackage{fancyhdr}
\pagestyle{fancy}
\fancyhead[LEO]{\slshape \leftmark} %section
\fancyhead[REO]{\thepage}
\setlength{\headheight}{14.5pt}

%\usepackage{etoolbox}

\usepackage[italian, textsize=tiny]{todonotes}
\setlength{\marginparwidth}{2cm}

\usepackage{refcheck}

\usepackage{tikz}
\usetikzlibrary{arrows}

\usepackage{titlesec}

\newenvironment{usecaseenv}{
    \def\arraystretch{2}
    \begin{tabular}{p{3cm}p{10cm}}\hline
}{
    \hline\end{tabular}
    \def\arraystretch{1}
}

\newenvironment{characteristicsEnv}{
    \def\arraystretch{2}
    \begin{tabular}{lp{8cm}}\hline
}{
    \hline\end{tabular}
    \def\arraystretch{1}
}

\newcommand\addheading[1]{
    \multicolumn{2}{c}{\textbf{\textit{#1}}}\\ \hline
}

\newcommand\addrow[2]{
    \textbf{#1}
    &\begin{minipage}[t][][t]{10cm}
       #2
    \end{minipage}\\
}

\newcommand\addrowservice[2]{
    \textbf{#1}
    &\begin{minipage}[t][][t]{8cm}
       #2
    \end{minipage}\\
}

% The actual command definition
\let\oldFigureName\figurename %save the old definition of the caption's figure name
\newcommand{\usecase}[5]{
    \vspace*{0.5cm} % adds a bit of padding to make it look nicer
    \renewcommand{\figurename}{Use case} %call figure name "Use case" instead
    \begin{figure}[htbp]
        \begin{center}
            \begin{usecaseenv}
                \addheading{#1} 
                \addrow{Use case:}{#2}
                \addrow{Soggetti:}{#3}
                \addrow{Obiettivi:}{#4}
            \end{usecaseenv}
        \end{center}
        \caption{#5}
    \end{figure}
    \renewcommand{\figurename}{\oldFigureName} %reset caption figure name
}

\let\oldFigureName\figurename %save the old definition of the caption's figure name
\newcommand{\serviceCharacteristics}[6]{
    \vspace*{0.5cm} % adds a bit of padding to make it look nicer
    \renewcommand{\figurename}{} %call figure name "Use case" instead
    \begin{figure}[H]
        \begin{center}
            \begin{characteristicsEnv}
                \addheading{Caratteristiche}
                \addrowservice{Partecipanti:}{#1}
                \addrowservice{Architettura software:}{#2}
                \addrowservice{Architettura hardware:}{#3}
                \addrowservice{Tipo di dato condiviso:}{#4}
                \addrowservice{Licenza:}{#5}
            \end{characteristicsEnv}
        \end{center}
        %\caption{}
    \end{figure}
    \renewcommand{\figurename}{\oldFigureName} %reset caption figure name
}

\raggedbottom

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\newgeometry{centering}
% Frontespizio
\pagenumbering{Roman}
\begin{titlepage}
    \begin{center}
        \includegraphics[width=\textwidth]{images/Logo.jpg}\\
        {\large{\em Corso di Laurea in Informatica per la comunicazione digitale}}
    \end{center}
    \vspace{12mm}
    \begin{center}
        {\huge{\bf Streaming decentralizzato di}}\\
        \vspace{4mm}
        {\huge{\bf contenuti audiovisivi}}\\
    \end{center}
    \vspace{12mm}
    \begin{flushleft}
        {\large{\bf Relatore:}}
        {\large{Trentini Andrea}}\\
        %{\large{\bf Correlatore:}}
        %{\large{...}}\\
    \end{flushleft}
    \vfill
    \begin{flushright}
        \parbox{1.7in}{
        {\large{\bf Tesi di Laurea di:}}\\
        {\large{Mirko Milovanovic}}\\
        {\large{\bf Matricola: \normalfont 870671}}
        }
    \end{flushright}
    \vfill
    \begin{center}
        {\large{\bf Anno Accademico 2024-2025}}
    \end{center}
\end{titlepage}

\tableofcontents
\thispagestyle{empty}

\chapter{Introduzione}
\pagenumbering{arabic}
\setcounter{page}{1}

Fin dai suoi albori Internet, nato da ARPAnet, svolge un ruolo importantissimo nella vita di tutti noi, che sia condividere informazioni militari, utilizzare servizi erogati via Web, o più recentemente guardare contenuti audiovisivi ``on-the-go'', ovvero quello di connettere le persone intorno al globo nei più svariati modi possibili attraverso l'utilizzo di calcolatori come computer e/o dispositivi mobili ``connessi''.

Negli anni e per come è stato concepito Internet stesso architetturalmente, si sono venuti a formare veri metodi di comunicazione tra gli utilizzatori e gli erogatori di servizi Internet, più o meno sicuri, efficaci o resilienti rispetto a tematiche come la privacy dei dati, la centralizzazione e costi di operazione.

Il modello Client/Server è certamente il più diffuso, reso famoso dall'imponente World Wide Web, il modo più intuitivo di utilizzare Internet ma certamente non l'unico.\cite[]{w3c} Questa architettura, specialmente nell'ambito della trasmissione di contenuti audiovisivi in streaming, presenta notevoli sfide tecniche ed economiche. L'infrastruttura centralizzata richiede server potenti e costosi che devono gestire simultaneamente migliaia di connessioni, con un consumo di banda che cresce linearmente con il numero di spettatori.

Negli ultimi anni, diverse piattaforme hanno cercato di risolvere questo problema attraverso l'adozione di tecnologie peer-to-peer (P2P) per la distribuzione dei contenuti. Tra queste, PeerTube si distingue come una delle soluzioni più promettenti, combinando una struttura federata con tecnologie di streaming P2P che promettono di ridurre significativamente il carico sui server centrali.

Questa tesi si propone di analizzare criticamente le affermazioni fatte dagli sviluppatori di PeerTube riguardo l'efficienza e l'efficacia del loro approccio P2P nel contesto dello streaming video. Partiremo da un'analisi del panorama attuale dello streaming centralizzato, ne evidenzieremo i limiti, per poi esplorare le alternative decentralizzate e concentrarci su PeerTube, ricreando e ampliando i test condotti dai suoi sviluppatori per verificarne empiricamente le prestazioni.

\section{Il problema dello streaming centralizzato}

Un sistema Client/Server tradizionale per lo streaming video presenta diverse problematiche critiche:

\begin{itemize}
    \item \textbf{Scalabilità limitata}: I server centrali devono gestire tutto il traffico in uscita, con costi di banda che crescono linearmente con il numero di spettatori.
    \item \textbf{Single Point of Failure}: Se il server centrale subisce un'interruzione, tutti i client perdono l'accesso al servizio.
    \item \textbf{Costi infrastrutturali elevati}: Mantenere server capaci di gestire picchi di traffico richiede investimenti significativi.
    \item \textbf{Centralizzazione del controllo}: Poche entità controllano le piattaforme più popolari, con potenziali implicazioni per la libertà di espressione e la privacy.
\end{itemize}

\section{Le alternative decentralizzate e P2P}

Le tecnologie peer-to-peer offrono un approccio alternativo che potrebbe risolvere molti di questi problemi:

\begin{itemize}
    \item \textbf{Distribuzione del carico}: Ogni client può anche fungere da distributore per altri client, riducendo il carico sul server originale.
    \item \textbf{Maggiore resilienza}: L'assenza di un punto centrale di fallimento rende il sistema più robusto.
    \item \textbf{Riduzione dei costi}: I costi di banda vengono distribuiti tra i partecipanti anziché essere sostenuti da un unico fornitore.
    \item \textbf{Decentralizzazione del controllo}: Nessuna entità singola può controllare completamente il flusso di informazioni.
\end{itemize}

Tra le varie piattaforme che utilizzano questo approccio, PeerTube ha attirato la nostra attenzione per la sua architettura ibrida che combina federazione e P2P, e per le affermazioni dei suoi sviluppatori riguardo l'efficienza di questo approccio. In particolare, un articolo pubblicato dal team di PeerTube sostiene che la loro implementazione P2P può ridurre il carico sul server di origine fino all'80%, una cifra che merita un'analisi approfondita e una verifica indipendente.

\chapter{Stato dell'arte}
\epigraph{In questo capitolo analizzeremo il panorama attuale delle tecnologie di streaming, confrontando approcci centralizzati e decentralizzati per comprendere i loro punti di forza e debolezza.}{}

\section{Modelli di comunicazione in rete}

\subsection{Client/Server e il Web 2.0}

Un sistema Client/Server è un tipo di computazione distribuita in cui i clienti effettuano delle richieste verso un server che a sua volta risponde con i dati/servizi richiesti restando in attesa. I client possono essere di vario tipo e trovarsi ovunque nel globo e in generale integrano una parte hardware (smartphone, PCs, \dots) ad una software (applicazioni GUI, web browser, \dots). I server, invece, sono delle macchine specializzate spesso raggruppate assieme in grandi data center, interconnesse tra di loro per fornire uno o più servizi a molteplici client contemporaneamente.

\begin{figure}[H]
    \centering
    \includegraphics[scale=0.3]{images/client-server.png}
    \caption{Modello Client/Server tradizionale}
\end{figure}

Questo modello ha dominato l'era del Web 2.0, caratterizzata da:

\begin{itemize}
    \item Piattaforme centralizzate con contenuti generati dagli utenti
    \item Elevata interattività e social networking
    \item Controllo dei dati da parte delle grandi aziende tecnologiche
    \item Monetizzazione tramite pubblicità e raccolta dati
\end{itemize}

Nonostante i vantaggi in termini di semplicità d'uso e accessibilità, questo modello ha portato a:

\begin{itemize}
    \item Forte centralizzazione del potere da parte di poche "Big Tech"
    \item Elevati costi di infrastruttura
    \item Problemi di privacy e controllo dei dati personali
    \item Vulnerabilità a censura e manipolazione dei contenuti
\end{itemize}

\subsection{Peer-to-Peer e Web 3.0}

Il modello peer-to-peer rappresenta un approccio alternativo in cui ogni nodo della rete può fungere sia da client che da server, eliminando la necessità di un'infrastruttura centralizzata. Questo modello è alla base di molte tecnologie del cosiddetto Web 3.0, caratterizzato da:

\begin{itemize}
    \item Decentralizzazione del controllo e distribuzione del carico
    \item Maggiore privacy e sovranità sui dati personali
    \item Resilienza a censura e fallimenti di singoli nodi
    \item Riduzione dei costi infrastrutturali
\end{itemize}

Tuttavia, le soluzioni P2P presentano anche alcune sfide:

\begin{itemize}
    \item Maggiore complessità tecnica
    \item Possibili problemi di latenza e qualità del servizio
    \item Difficoltà nel garantire contenuti legali e moderazione
    \item Sfide tecniche come il NAT traversal e la connettività tra peer
\end{itemize}

\break

\section{Casi d'uso per lo streaming decentralizzato}

Vediamo degli esempi di come questa interazione potrebbe essere svolta:

\usecase{Esempio d'interazione ``one to many''}{Un utente davanti al proprio computer vorrebbe condividere quello che vede sullo schermo con i propri amici o followers}{Utente principale, viewers, computer, connessione internet}{Condivisione in live streaming di un contenuto a schermo via internet con TCP/IP}{}

\usecase{Esempio d'interazione ``many to many''}{Più utenti al proprio computer vorrebbero comunicare e interagire tra di loro contemporaneamente simil conference-call}{Utenti multipli, computer, connessione internet, microfono, telecamera}{Live streaming e interazione real-time tra utenti via internet con TCP/IP}{}

\usecase{Esempio d'interazione ``one to many''}{Un’azienda per questioni legate alla sicurezza sul lavoro si ritrova con la necessitò di dover fare dei ``workshop'' in diretta ai propri dipendenti con diverse locazioni sparse per il nel mondo senza utilizzare però grandi servizi cloud dato l’elevato costo di banda e di noleggio del servizio per singolo utente finale, in questo caso il singolo dipendente}{Dipendenti, azienda}{Video streaming dei ``workshop'' per i dipendenti sparsi per il mondo}{}

\usecase{Esempio d'interazione ``one to many''}{Un gruppo di amici deve svolgere un progetto universitario assieme e quindi interagire tra di loro facendo pair programming condividendo lo schermo gli uni con gli altri. Per questioni di privacy e sicurezza non vuole utilizzare un servizio pubblico come Discord in quanto vorrebbero tenere tutto segreto fino al giorno della presentazione}{Studenti}{Pair programming}{}

\usecase{Esempio d'interazione ``one to many''}{Una casa produttrice di film emergente vuole condividere i nuovi film in produzione con dei trailer ma a causa di dispute legate ai DRM, copyright e content strike di altre aziende più grandi non vuole utilizzare dei servizi già esistenti con EULA molto restringenti ma vuole avere il controllo dei propri diritti sul contenuto creato da essa stessa}{Filmmakers, appassionati di film}{Condivisione degli ultimi trailer per i film prodotti dalla casa}{}

\usecase{Esempio d'interazione ``one to many''}{Un gruppo di amici vuole fare una serata di gioco online e vuole condividere il proprio schermo con gli altri giocatori per poter giocare assieme}{Gamer}{Condivisione dello schermo per giocare assieme}{}

\break

In sintesi, l'analisi dei casi d'uso evidenzia la necessità di una soluzione di streaming decentralizzata e a licenza libera, capace di operare in modalità uno-a-molti o molti-a-molti, senza affidarsi a servizi cloud proprietari e senza richiedere il deploy di una complessa infrastruttura hardware globale. I requisiti fondamentali, soprattutto in relazione all'elevato fabbisogno di banda tipico dei contenuti video, si declinano nei seguenti scenari applicativi:

\hfill\break
\textbf{Commerciale:}
\begin{itemize}
    \item Streaming di eventi o riunioni interne,
    \item Assistenza remota,
    \item Conference calls,
    \item Possibilità di operare sia come utente che come provider/distributore,
    \item Ottimizzazione dei costi e del consumo della banda.
\end{itemize}

\hfill\break
\textbf{Educazionale:}
\begin{itemize}
    \item Trasmissione in diretta di corsi e lezioni.
\end{itemize}

\hfill\break
\textbf{Sociale:}
\begin{itemize}
    \item Organizzazione di lan party,
    \item Supporto per streaming di gaming e attività live da parte di streamer,
    \item Conference calls in piccoli gruppi,
    \item Impiego per telecamere di sicurezza,
    \item Moderazione dei contenuti online.
\end{itemize}

\hfill\break
\textbf{Istituzionale:}
\begin{itemize}
    \item Comunicazioni video in situazioni di emergenza.
\end{itemize}

\section{Panoramica delle piattaforme di streaming esistenti}

\subsection{Soluzioni centralizzate}

\subsubsection{Twitch}

Twitch è una piattaforma di live streaming di proprietà di Amazon lanciata nel 2011, originariamente specializzata nella trasmissione in diretta di videogiochi, eSports ed eventi riguardanti il mondo videoludico.

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/twitchHome.png}
    \caption{Home page di Twitch.}
\end{figure}

Una delle più famose e grandi, la piattaforma è stata originariamente sviluppata come una controparte di streaming per Justin.tv, una piattaforma di streaming generale. Tuttavia, Twitch si è concentrata esclusivamente sui contenuti di videogiochi e di eSports, anche se oggi rimane tutt'ora la scelta "de-facto" per molti utenti non solo per lo streaming di contenuti videoludici ma anche per lo "streaming general purpose" come ad esempio lo streaming di musica, arte, cucina e di varie attività creative.

Negli anni successivi, ha visto una rapida crescita e ha attirato una vasta gamma di creatori di contenuti, dalle grandi organizzazioni di esports ai singoli streamer indipendenti, fino ad oggi con una user base di circa 3 milioni di viewers e 1.5 milioni di broadcaster giornalieri rispettivamente.

Twitch offre molti servizi sotto un unico sito web accessibile con un semplice browser:

\serviceCharacteristics{Chiunque con un account può condividere e guardare}
{Centralizzata}
{Servizio accessibile via browser o applicazione mobile}
{Stream video e testo per funzionalità di live chat}
{Proprietaria con contratto di utilizzo `EULA'}

\subsubsection{YouTube}

Youtube è una piattaforma di sharing online di video statici, di proprietà di Google, specializzata nella condivisione globale di video generici con funzionalità aggiuntive di social media, monetizzazione e live streaming.

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/youtubeHome.png}
    \caption{Home page di Youtube.}
\end{figure}

La compagnia è stata lanciata nel febbraio 2005 come indipendente ed è poi stata successivamente acquisita da Google. Al momento viene considerata la piattaforma più grande e longeva di questo segmento, con più di 2.5 miliardi di utenti mensili e milioni di ore di video condivisi ogni giorno. Dall'acquisizione, YouTube ha espanso la propria offerta al di fuori della sola condivisione di video "amatoriali", includendo contenuti come film di produzione professionale, video musicali ufficiali, documentari, news, ecc. Ha anche integrato la piattaforma pubblicitaria AdSense, sempre di proprietà di Google, permettendo a tutti gli utenti amatoriali o professionali approvati di poter ricevere un ricavo economico dalle pubblicità e dal marketing presenti sul sito.

\serviceCharacteristics{Chiunque sul web}{Servizio accessibile via browser o applicazione mobile}{Centralizzata con utilizzo di CDN}{Video statici, live stream}{Proprietaria con contratto di utilizzo `EULA'}

\subsection{Soluzioni decentralizzate e P2P}

\subsubsection{Tahoe-LAFS}

Tahoe-LAFS è un sistema di file distribuito, open source, decentralizzato e sicuro che permette agli utenti di memorizzare e condividere file in un ambiente di rete distribuita chiamata `Grid'. Sviluppato da un gruppo di ricercatori dell'Università di Maryland, dal 2007 ed è stato rilasciato come software open source sotto licenza GPL. Tahoe-LAFS è stato progettato per essere un sistema di file distribuito sicuro, affidabile e scalabile, in modo da poter essere utilizzato in ambienti di rete distribuita, dato che promette di essere un sistema `provider-independent', ovvero che i fornitori dei server intermediari non hanno mai la possibilità di accedere o modificare i dati memorizzati dagli utenti finali perché che non sono loro a garantire la confidenzialità, l'integrità o l'assoluta disponibilità dei dati, ma sono i client finali a farlo. 

Alla base, Tahoe-LAFS è essenzialmente un sistema di archiviazione chiave-valore. L'archivio utilizza delle corte stringhe, circa 100 byte, chiamate `capabilities' come chiavi e dati arbitrari come valori.

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/tahoe-LAFS.logo.png}
    \caption{Tahoe-LAFS logo.}
\end{figure}

Si possono condividere queste `capabilities' per dare agli altri accesso a determinati valori sulla `Grid'. Ad esempio, si può dare la possibilità di lettura ad un amico e conservare il permesso di scrittura per te stessi.
Per eliminare un valore, basta dimenticare (cioè eliminare) la chiave della `capability', e, una volta fatto sarà impossibile recuperare i dati. I server di archiviazione però hanno un modo per fare `garbage-collection' da condivisioni non referenziate.


In aggiunta al sistema chiave-valore, viene affiancato un livello i file-storage classico, che consente di condividere, con altri utenti, sotto-directory senza, ad esempio, rivelare l'esistenza o il contenuto delle directory principali.

Come detto prima, sono i clienti a garantire l'integrità e la confidenzialità dei dati, e questo viene realizzato grazie alla crittografia che viene eseguita su ogni `capability' prima di essere caricata sul `Grid'. Ogni valore viene prima crittografato con una chiave asimmetrica e poi spezzettato in parti più piccole, e più maneggiabili. Questi segmenti diventano poi effettivamente gli `share' che verranno memorizzati nei noti della rete, che ricordiamo, svolgono solo la funzione di memorizzazione dei dati, gli utenti non si affidano a loro per altro. \cite{tahoelafsAbouttahoerstTrunkdocs} \cite{torprojectHeartTahoeLAFS}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/tahoe-simple-data-flow.png}
    \caption{Tahoe-LAFS simple data flow.}
\end{figure}

\serviceCharacteristics{Utenti e server di terze parti}{Software client lato utente}{Decentralizzata e `provider-indipendent'}{Qualsiasi tipo di file binario}{GPL}

\subsubsection{IPFS}
IPFS o `InterPlanetary File System' è una suite di protocolli e librerie open source per la condivisione di file in un ambiente di rete distribuita utilizzando meccanismi di `content-addressing'. IPFS è stato sviluppato da Protocol Labs, un'azienda di ricerca e sviluppo nel 2014.

IPFS punta a creare un file system condiviso da una rete di nodi decentralizzata che comunica attraverso P2P, dove i singoli file sono organizzati come blocchi indipendentemente individuabili ed immutabili (ovvero che non possono essere modificati ma solo aggiunti o eliminati) con degli identificatori chiamati `CID (Content identifiers)' memorizzati in un database distribuito chiamato `DHT (Distributed Hash Table)' che viene condiviso con ogni singolo nodo della rete al fine di facilitare il routing dei dati attraverso essa stessa.

Uno dei problemi di IPFS è che per design stesso, ogni singolo file è visibile a tutti i nodi della rete e quindi non è possibile creare un sistema di condivisione di file privati, ma solo di file pubblici, che però volendo possono essere crittografati, impedendo la lettura dei dati da parte di attori terzi. \cite{ipfsWhatIPFS} \cite{ipfsIPFSWhitepaper}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/Data-sharing-on-IPFS-by-owner.png}
    \caption{IPFS data flow. \cite{ResearchBasedDataRightsManagementUsingBlockchainOverEthereumNetwork}}
\end{figure}

\serviceCharacteristics{Nodi della rete}{Protocolli e software lato client}{Decentralizzata simil Blockchain}{Qualsiasi tipo di file binario}{MIT}

\subsubsection{PeerTube}
PeerTube è un servizio di video sharing open source, federalizzato e decentralizzato (lato client), basato su protocolli peer-to-peer come `WebTorrent', `WebRTC' e altre tecnologie web standard.
Fa parte del cosiddetto `Fediverse', un insieme di server interconnessi che comunicano tramite ActivityPub, un protocollo di comunicazione aperto per creare reti federate.
Inizialmente creato come una piattaforma di video sharing per i creatori di contenuti indipendenti, è stato progettato per essere estensibile e adattabile a qualsiasi tipo di contenuto video che rispetti i termini delle singole istanze che vengono messe a disposizione pubblicamente.

Il funzionamento è del tutto simile ad altre piattaforme video tipo (YouTube, Vimeo, Dailymotion, ecc.) con supporto per video statici e livestream, ma con la differenza che i video possono essere memorizzati e condivisi non solo dalle singole istanze della federazione attraverso il normale HTTP ma anche tra i client finali usando P2P per alleggerire il carico di banda.
PeerTube è iniziato come progetto indipendente da un singolo sviluppatore che poi è stato affiancato dalla no-profit Framasoft. \cite{peertubeAbout} \cite{wiki:ActivityPub} \cite{activitypubActivityPubRocks}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/peerTubeHome.png}
    \caption{PeerTube.}
\end{figure}

\serviceCharacteristics{Utenti registrati e non delle singole istanze}{Browser web e server indipendenti}{Federalizzata e decentralizzata P2P}{Video statici e livestream}{AGPLv3+}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/peerTubeItalia.png}
    \caption{Una istanza di PeerTube Italiana.}
\end{figure}

\subsubsection{Ace Stream}
Ace Stream è un software proprietario di video streaming basato su P2P, sviluppato da un gruppo di sviluppatori russi, che permette agli utenti di trasmettere in diretta video e audio, riprodurre file multimediali, e ricevere e condividere contenuti in tempo reale. Il software è stato rilasciato per la prima volta nel 2013 e da allora è stato scaricato più di 100 milioni di volte. Ace Stream offre una vasta gamma di funzionalità che lo rendono popolare tra gli utenti che desiderano guardare contenuti in streaming. Utilizzando la tecnologia P2P, il software consente agli utenti di trasmettere video e audio in tempo reale, senza dover attendere il completamento del download. Questo significa che gli utenti possono godere di una riproduzione fluida e senza interruzioni, anche con connessioni internet più lente.

\begin{figure}[htb]
    \centering
    \includegraphics[width=\textwidth]{images/Ace_Stream_logo.png}
    \caption{PeerTube.}
\end{figure}

Inoltre, Ace Stream supporta la riproduzione di file multimediali locali, consentendo agli utenti di guardare i propri film, serie TV e altri contenuti salvati sul proprio dispositivo. Il software supporta una vasta gamma di formati video e audio, garantendo un'alta compatibilità.

Un'altra caratteristica interessante di Ace Stream è la possibilità di ricevere e condividere contenuti in tempo reale. Gli utenti possono creare i propri canali di streaming e condividere i propri contenuti con altri utenti. Questo rende il software ideale per gli appassionati di sport, che possono trasmettere eventi sportivi in diretta e condividerli con altri appassionati.

Ace Stream è disponibile per diverse piattaforme, tra cui Windows, Mac, Linux e Android, il che lo rende accessibile a un vasto pubblico. Inoltre, il software è gratuito da scaricare e utilizzare, rendendolo ancora più attraente per gli utenti.

In conclusione, Ace Stream è un software potente e versatile per lo streaming di video e audio. Grazie alla sua tecnologia P2P, offre una riproduzione fluida e senza interruzioni, consentendo agli utenti di godersi i propri contenuti preferiti in tempo reale. Con la possibilità di condividere contenuti e creare canali di streaming, Ace Stream offre un'esperienza di streaming interattiva e coinvolgente. \cite{acestreamAnnouncementStream} \cite{archiveStream}

\serviceCharacteristics{Utenti registrati e non delle singole istanze}{Browser web e server indipendenti}{Federalizzata e decentralizzata P2P}{Video statici e livestream}{AGPLv3+}

\chapter{PeerTube: architettura e tecnologie}

\section{Storia e evoluzione del progetto}

PeerTube è nato nel 2017 come progetto dell'organizzazione non profit francese Framasoft, con l'obiettivo di creare un'alternativa libera e decentralizzata a piattaforme come YouTube. Da allora, ha visto una crescita costante sia in termini di funzionalità che di adozione, con oltre 1000 istanze attive in tutto il mondo nel 2023.

Le principali tappe evolutive del progetto includono:
\begin{itemize}
    \item 2017: Prima versione beta con supporto per video statici
    \item 2018: Rilascio della versione 1.0 con supporto per la federazione via ActivityPub
    \item 2019: Introduzione del supporto per lo streaming live
    \item 2020-2021: Miglioramenti dell'interfaccia utente e del sistema di raccomandazione
    \item 2022: Ottimizzazione del protocollo P2P e introduzione di OpenTelemetry per il monitoraggio
    \item 2023: Rilascio della versione 6.0 con significative migliorie al sistema P2P
\end{itemize}

\section{Stack tecnologico}

\subsection{Architettura generale}

PeerTube utilizza un'architettura ibrida che combina:
\begin{itemize}
    \item Un backend basato su Node.js e TypeScript
    \item Un frontend realizzato con Angular
    \item Un sistema di storage per i video (locale o distribuito)
    \item Un database PostgreSQL per la persistenza dei dati
    \item Un sistema di federazione basato su ActivityPub
    \item Tecnologie P2P per la distribuzione dei contenuti
\end{itemize}

\subsection{Streaming video con HLS}

Per lo streaming video, PeerTube utilizza il protocollo HTTP Live Streaming (HLS), sviluppato da Apple. Questo protocollo:
\begin{itemize}
    \item Divide il video in piccoli segmenti (tipicamente di 2-10 secondi)
    \item Crea un file manifest (.m3u8) che elenca i segmenti disponibili
    \item Permette la selezione automatica della qualità in base alla connessione
    \item È compatibile con la maggior parte dei browser e dispositivi moderni
\end{itemize}

\subsection{P2P Media Loader e WebRTC}

Il cuore del sistema P2P di PeerTube è costituito da:

\begin{itemize}
    \item \textbf{P2P Media Loader}: Una libreria JavaScript che integra il P2P nel player video
    \item \textbf{WebRTC}: Una tecnologia standard per la comunicazione peer-to-peer diretta tra browser
    \item \textbf{WebTorrent Tracker}: Utilizzato come sistema di signaling per connettere i peer
\end{itemize}

\section{Signaling e NAT Traversal}

Un aspetto critico del sistema P2P è il processo di signaling, che permette ai peer di scoprirsi e connettersi tra loro. PeerTube utilizza:

\begin{itemize}
    \item \textbf{WebTorrent Tracker}: Per la scoperta dei peer che stanno guardando lo stesso contenuto
    \item \textbf{Server STUN}: Per facilitare il NAT traversal, permettendo ai peer di stabilire connessioni anche quando si trovano dietro router NAT
    \item \textbf{Server TURN} (opzionale): Come fallback quando la connessione diretta non è possibile
\end{itemize}

\section{Algoritmo di selezione dei peer}

L'efficienza del sistema P2P dipende in modo cruciale dall'algoritmo utilizzato per selezionare i peer da cui scaricare i dati. PeerTube utilizza un algoritmo simile a quello di BitTorrent, che considera:

\begin{itemize}
    \item \textbf{Disponibilità dei segmenti}: Priorità ai peer che hanno i segmenti richiesti
    \item \textbf{Velocità di download}: Preferenza per i peer che offrono migliori prestazioni
    \item \textbf{Rarità dei segmenti}: Priorità allo scaricamento dei segmenti meno diffusi nella rete
    \item \textbf{Reciprocità}: Tendenza a favorire i peer che a loro volta condividono dati
\end{itemize}

\section{Sistema di monitoraggio integrato con OpenTelemetry}

PeerTube integra OpenTelemetry per il monitoraggio delle prestazioni del sistema P2P, raccogliendo metriche come:

\begin{itemize}
    \item \textbf{Percentuale di dati condivisi via P2P}
    \item \textbf{Numero di peer connessi}
    \item \textbf{Latenza delle connessioni}
    \item \textbf{Utilizzo della banda del server}
    \item \textbf{Errori e disconnessioni}
\end{itemize}

Queste metriche possono essere visualizzate attraverso dashboard Grafana o altri sistemi di monitoraggio compatibili con OpenTelemetry.

\chapter{Verifica empirica delle prestazioni P2P di PeerTube}

A dicembre 2023, il team di PeerTube ha pubblicato un articolo in cui va ad analizzarne le prestazioni facendo degli `stress test' per verificare se la tecnologia P2P integrata nel sistema sia effettivamente in grado di ridurre il carico sui server con circa 1000 utenti connessi contemporaneamente, in quanto, secondo i dati raccolti da Twitch nel 2022, coprivano il 99\% dei casi di utilizzo della piattaforma.

\

Per realizzare test veritieri, il team ha simulato 1.000 spettatori simultanei utilizzando 1.000 browser Chrome, ciascuno con un indirizzo IP pubblico IPv6 dedicato. Questo è stato realizzato tramite `Selenium grid', un software di automazione e testing per i browser, affiancato da Docker su cloud Hetzner e successivamente con un potente server fornito da Octopuce.

La scelta di 1.000 spettatori è significativa poiché copre la stragrande maggioranza delle dirette streaming su piattaforme importanti come Twitch, suggerendo che PeerTube può essere adeguato per un'ampia gamma di casi d'uso.
In condizioni ottimali, l'aspetto P2P di PeerTube dovrebbe ridurre la larghezza di banda necessaria per trasmettere un video in diretta di un fattore da 3 a 4, standa quanto detto degli sviluppatori di PeerTube.

\

Sono stati condotti 4 scenari di test principali:
\begin{itemize}
    \item Live streaming con impostazione `Normal Latency'
    \item Live streaming con impostazione `High Latency'
    \item Live streaming con impostazione `High Latency' e 50\% dei peer con P2P disabilitato
    \item Un normale video `on-demand'
\end{itemize}

su una macchina virtuale con:
\begin{itemize}
    \item 4 vCore i7-8700 CPU @ 3.20GHz
    \item 4 GB di RAM
    \item 1 Gbps di banda
\end{itemize}

I dati dei test sono stati raccolti tramite OpenTelemetry e Grafana, con metriche come:
\begin{itemize}
    \item Percentuale di dati trasferiti via P2P vs. dal server
    \item Utilizzo di CPU
    \item Comportamento in condizioni di rete variabili
    \item Numero di spettatori
\end{itemize}

con i quali, infine, sono stati in grado di dimostrare che PeerTube è in grado di gestire 1.000 spettatori simultanei con un carico minimo sui server, grazie alla tecnologia P2P integrata in quanto la quantità di dati trasferiti via P2P è progressivamente aumentata con il tempo fino a raggiungere un rapporto del 75\% dei dati totali trasferiti per i video in diretta e del 98\% per i video `on-demand'.

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/chrome_Mqt9TamrBT.png}
    \caption{PeerTube conclusioni sullo stress test.}
\end{figure}

Tuttavia, l'articolo non fornisce dettagli sufficienti sulla metodologia utilizzata né rilascia gli strumenti specifici per riprodurre i test in modo indipendente. \cite{joinpeertubePeerTubeStress}

\

Perciò abbiamo deciso di creare un sistema di test automatizzato che possa riprodurre i test descritti nell'articolo originale.

\section{Metodologia per la verifica empirica}

Per verificare le affermazioni degli sviluppatori di PeerTube, abbiamo deciso di:

\begin{itemize}
    \item Creare un'automazione per riprodurre indipendentemente i test descritti nell'articolo
    \item Raccogliere metriche più dettagliate rispetto a quelle presentate nell'articolo originale
    \item Analizzare i dati raccolti per valutare le prestazioni del sistema P2P di PeerTube
\end{itemize}

\section{Stack tecnologico per i test}

Per i nostri test abbiamo utilizzato una combinazione di tecnologie open source per creare un sistema di test automatizzato che sfrutta le seguenti tecnologie:

\begin{itemize}
    \item \textbf{Docker}: Per creare ambienti isolati e facilmente riproducibili
    \item \textbf{Telegraf}: Per la raccolta di metriche di sistema e di rete
    \item \textbf{MongoDB}: Per l'archiviazione strutturata dei dati raccolti
    \item \textbf{Python}: Come linguaggio principale per l'automazione
    \item \textbf{Selenium}: Per simulare browser reali che guardano lo stream
    \item \textbf{webrtc-internals-exporter}: Una estensione del browser creata per raccogliere metriche dettagliate sulle connessioni WebRTC
    \item \textbf{Hetzner Cloud}: Per distribuire i test su macchine virtuali in diverse regioni geografiche
\end{itemize}

\subsection{Docker}

Docker è una piattaforma open source che semplifica la creazione, la distribuzione e l'esecuzione di applicazioni in contenitori. I contenitori Docker sono degli ambienti isolati che simulano un sistema operativo completo, come le macchine virtuali, consentendo di eseguire applicazioni in modo consistente su qualsiasi ambiente.

La differeneza tra docker e una macchina virtuale è che i container Docker condividono il kernel del sistema operativo host, riducendo l'overhead e migliorando le prestazioni, senza dover ricorrere ad un `Hypervisor' per la virtualizzazione.

\begin{figure}[H]
    \centering
    \includegraphics[width=350pt]{images/docker-engine.png}
    \caption{Docker Engine.}
\end{figure}

In se Docker è composto da 4 componenti principali:
\begin{itemize}
    \item \textbf{Docker Engine}: Il core del sistema, responsabile della creazione e gestione dei container nonché il pricesso demone eseguito sulla macchina host. Fornisce l'accesso a tutte le funzionalità e i
    servizi messi a disposizione da Docker. Mette a disposizione un insieme di comandi per la gestione dei container, delle immagini e dei volumi.
    \item \textbf{Docker Client}: Interfaccia da riga di comando e `API' per interagire con Docker Engine. 
    \item \textbf{Docker Image}: Un `template' di sola lettura che contiene e definisce i parametri di una applicazione da eseguire in un container a runtime. Le immagini vengono create e organizzate per livelli `stateless' e immutabil. 
    \item \textbf{Docker Container}: Un'istanza in esecuzione di un'immagine Docker. Un container è un ambiente isolato che esegue un'applicazione specifica e include tutto il necessario per eseguire l'applicazione, come il codice, le librerie, le variabili d'ambiente e le dipendenze. Il `filesystem' del container è l'ultimo livello che viene aggiunto al quale vi è possibile accedere sia in lettura che in scrittura. I contenitori, inoltre, possono essere associati a dei volumi per la persistenza dei dati, i quali fornisono un metodo semplice e immediato per condivuidere dati tra i container e l'host.\\La comunicazione tra container avviene tramite la creazione di `network' o reti separate che vengono connesse ai singoli container, abilitando così una sorta di LAN interna tra un insieme di container. Per far, invece, comunicare i container con il mondo esterno bisogna invece utilizzare i `port mapping' tra una porta della macchina host e una porta del container.
\end{itemize}

\begin{figure}[H]
    \centering
    \includegraphics[width=200pt]{images/0_ukWqRD74ltfb5Uaz.png}
    \caption{Docker Overview.}
\end{figure}

Approfondendo il discordo del `networking', Docker mette a disposizione varti tipi di `network' per la comunicazione tra container, i 3 principali sono:
\begin{itemize}
    \item \textbf{Bridge}: È il `network' di default che viene creato quando si installa Docker. I container connessi a questo `network' possono comunicare tra loro e con il host, ma non possono comunicare con i container in altri `network'.
    \item \textbf{Host}: I container connessi a questo `network' condividono la rete dell'host, quindi non hanno bisogno di fare il `port mapping' per comunicare con il mondo esterno.
    \item \textbf{None}: I container connessi a questo `network' non hanno accesso alla rete, quindi non possono comunicare con altri container o con l'esterno.
\end{itemize}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/Docker-network-1.png}
    \caption{Docker Networking.}
\end{figure}
\cite{AzureFunctions} \cite{geeksforgeeksContainerizationUsing} \cite{geeksforgeeksDockerNetworking}

\subsection{Telegraf}

Telegraf è un agente di raccolta di metriche open source sviluppato da InfluxData. È progettato per raccogliere, elaborare e inviare metriche da una varietà di sorgenti, tra cui sistemi operativi, database, applicazioni e dispositivi di rete.

\begin{figure}[H]
    \centering
    \includegraphics[width=300pt]{images/telegraf-architecture-diagram.png}
    \caption{Architettura Telegraf.}
\end{figure}

Scritto in `Go', Telegraf è dodato di oltre 300 plugin di input, trasformazione e output di dati, che consentono di raccogliere metriche da una vasta gamma di sorgenti. Per sua natura, funziona come un pipeline di dati che può essere instradata attraverso diversi plugin per elaborare e aggregare le informazioni prima di raggiungere l'output finale.

Alcuni componenti principali di Telegraf includono:
\begin{itemize}
    \item \textbf{Agent}: Il core del sistema, responsabile della raccolta e dell'elaborazione delle metriche dai plugin di input definiti e le invia ai plugin di output specificati, in base alla configurazione fornita.
    \item \textbf{Input Plugins}: Raccolgono metriche da sorgenti come sistemi operativi, database, applicazioni e dispositivi di rete.
    \item \textbf{Processor Plugins}: Elaborano e trasformano le metriche raccolte prima di inviarle all'output.
    \item \textbf{Output Plugins}: Inoltrano le metriche elaborate a un sistema di monitoraggio o di archiviazione.
    \item \textbf{Aggregator Plugins}: Aggregano le metriche raccolte per ridurre il volume dei dati.
\end{itemize}

La configurazione di Telegraf è definita da un file di configurazione `TOML' che definisce i plugin di input, processore e output da utilizzare, insieme a eventuali parametri aggiuntivi necessari per la raccolta e l'elaborazione delle metriche.

Viene spesso utilizzato affianco ad un database di tipo `time-series' come InfluxDB per l'archiviazione e la visualizzazione delle metriche raccolte, ma può essere integrato con una vasta gamma di sistemi di monitoraggio e analisi dei dati.\\
Una metrica `time-series' è una serie di dati indicizzati in sequenza rispetto al tempo. Un esempio è una sequenza di osservazioni o rilevazioni registrate allo scorrere del tempo. Vi sono due macrocategorie di time series:
\begin{itemize}
    \item \textbf{univariate time series}: le osservazioni sono monodimensionali, ovvero: viene registrato un solo valore numerico allo scorrere del tempo.
    \item \textbf{multivariate time series}: le osservazioni sono multidimensionali, ovvero, si registrano più valori numerici per un singolo istante di tempo.
\end{itemize}
Tipicamente, un `time-series' viene rappresentato con una struttura dati che registri un timestamp, che può essere di qualche tipo specifico per date, oppure un interocontenente uno `Unix timestamp'; oltre a questo contiene dati addizionali, che nella versione più semplice possono essere un unico valore numerico, ovvero l’osservazione registrata allo scorrere del tempo.
\cite{githubGitHubInfluxdatatelegraf} \cite{noauthor_telegraf_nodate} \cite{aiknowTimeSeries}

\section{Architettura del sistema di test}

Il nostro sistema di test è composto da:

\begin{itemize}
    \item Un server centrale che esegue un'istanza di PeerTube e raccoglie le metriche
    \item Multiple macchine virtuali distribuite geograficamente che simulano gli spettatori
    \item Un sistema di orchestrazione che coordina l'esecuzione dei test
    \item Un database centralizzato per la raccolta e l'analisi dei dati
\end{itemize}

\subsection{Difficoltà incontrate e soluzioni}

Durante lo sviluppo del sistema di test abbiamo affrontato diverse sfide:

\begin{itemize}
    \item \textbf{Accesso alle metriche WebRTC}: Risolto sviluppando un'estensione Chrome personalizzata
    \item \textbf{Limitazioni delle API di Peertube}: Superato utilizzando tecniche di scraping con Selenium e Python
    \item \textbf{Gestione delle variabili d'ambiente nell'estensione Chrome}: Risolto attraverso webpack e sostituzione dinamica
    \item \textbf{Raccolta dei dati dei test su macchine virtuali distribuite}: Risolto utilizzando Telegraf e MongoDB
\end{itemize}

\section{Casi d'uso e scenari di test riprodotti}

Abbiamo riprodotto i due principali scenari descritti nell'articolo di PeerTube:

\begin{itemize}
    \item \textbf{Live streaming con impostazione Normal Latency}: Il setup standard di PeerTube
    \item \textbf{Live streaming con impostazione High Latency}: Una configurazione che privilegia l'efficienza P2P a scapito della latenza
\end{itemize}

Per ciascuno scenario, abbiamo variato il numero di spettatori (10, 30, 50, 100) e misurato:

\begin{itemize}
    \item Percentuale di dati trasferiti via P2P vs. dal server
    \item Latenza media e picchi
    \item Utilizzo di CPU e memoria sui client
    \item Qualità dell'esperienza utente (buffering, interruzioni)
    \item Comportamento in condizioni di rete variabili
\end{itemize}

\chapter{Analisi dei dati e risultati}

[Questa sezione sarà completata la prossima settimana con i risultati dei test]

\chapter{Conclusioni}

[Questa sezione sarà completata dopo l'analisi dei dati]

\nocite{*}
\printbibliography
\sloppy
\addcontentsline{toc}{chapter}{Bibliografia}

\end{document}