Mirko Milovanovic
c37719b88f
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 2m39s
636 lines
35 KiB
TeX
636 lines
35 KiB
TeX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\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{biblatex}
|
||
\bibliography{Biblio.bib}
|
||
|
||
\usepackage{hyperref}
|
||
\hypersetup{
|
||
colorlinks,
|
||
linkcolor={black!100!black},
|
||
citecolor={blue!100!black},
|
||
urlcolor={blue!100!black}
|
||
}
|
||
|
||
\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}
|
||
\setcounter{secnumdepth}{3}
|
||
\setcounter{tocdepth}{3}
|
||
|
||
\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}
|
||
|
||
Nel novembre 2023, il team di PeerTube ha pubblicato un articolo in cui sostiene che la loro implementazione P2P può ridurre il carico sul server fino all'80% in condizioni ottimali. L'articolo presenta i risultati di test condotti con diversi numeri di peer e configurazioni.
|
||
|
||
Principali affermazioni dell'articolo:
|
||
\begin{itemize}
|
||
\item Con 10 peer, il carico sul server viene ridotto del 30-50%
|
||
\item Con 50 peer, la riduzione raggiunge il 60-70%
|
||
\item Con 100+ peer, si può arrivare all'80% di riduzione
|
||
\item L'impostazione "High Latency" migliora ulteriormente l'efficienza P2P
|
||
\end{itemize}
|
||
|
||
Tuttavia, l'articolo non fornisce dettagli sufficienti sulla metodologia utilizzata né rilascia gli strumenti per riprodurre i test in modo indipendente.
|
||
|
||
\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 i test descritti nell'articolo
|
||
\item Raccogliere metriche più dettagliate rispetto a quelle presentate nell'articolo originale
|
||
\item Analizzare aspetti non considerati, come latenza, qualità dell'esperienza utente e comportamento in condizioni di rete non ideali
|
||
\end{itemize}
|
||
|
||
\subsection{Stack tecnologico per i test}
|
||
|
||
Per i nostri test abbiamo utilizzato:
|
||
|
||
\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}: 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{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}
|
||
|
||
\section{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{Sincronizzazione dei test}: Implementato un sistema di coordinamento basato su messaggi
|
||
\item \textbf{Limitazioni delle API di WebRTC}: Superato utilizzando tecniche di scraping avanzate
|
||
\item \textbf{Gestione delle variabili d'ambiente nell'estensione Chrome}: Risolto attraverso webpack e sostituzione dinamica
|
||
\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
|
||
\addcontentsline{toc}{chapter}{Bibliografia}
|
||
|
||
\end{document} |