chore: fixed mispellings, added small peertube plugin section, color formatted code
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m7s
All checks were successful
Build LaTeX Document / build_latex (push) Successful in 3m7s
This commit is contained in:
311
Tesi.tex
311
Tesi.tex
@@ -37,17 +37,62 @@
|
||||
|
||||
\usepackage{lipsum} % Per inserire testo a caso in attesa di realizzare i capitoli
|
||||
|
||||
\usepackage{listings} % Per inserire codice formattato
|
||||
%\usepackage{minted}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{listings}
|
||||
\lstset{
|
||||
language=Python, % choose the language of the code
|
||||
basicstyle=\fontfamily{pcr}\selectfont\footnotesize\color{red},
|
||||
keywordstyle=\color{blue}\bfseries, % style for keywords
|
||||
numbers=none, % where to put the line-numbers
|
||||
numberstyle=\tiny, % the size of the fonts that are used for the line-numbers
|
||||
%backgroundcolor=\color{darkgray},
|
||||
showspaces=false, % show spaces adding particular underscores
|
||||
showstringspaces=false, % underline spaces within strings
|
||||
showtabs=false, % show tabs within strings adding particular underscores
|
||||
frame=single, % adds a frame around the code
|
||||
tabsize=2, % sets default tabsize to 2 spaces
|
||||
%rulesepcolor=\color{gray},
|
||||
%rulecolor=\color{black},
|
||||
captionpos=b, % sets the caption-position to bottom
|
||||
breaklines=true, % sets automatic line breaking
|
||||
breakatwhitespace=false,
|
||||
stringstyle=\color{green!50!black},
|
||||
emph={StatsSetupPlugin,StatsDownloadPlugin,DefaultStatsSetupPlugin,__init__},
|
||||
emphstyle=\color{red!70!black},
|
||||
}
|
||||
|
||||
%\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
|
||||
%}
|
||||
\lstdefinelanguage{json}{
|
||||
basicstyle=\normalfont\ttfamily,
|
||||
numbers=none,
|
||||
numberstyle=\scriptsize,
|
||||
breaklines=true,
|
||||
frame=single,
|
||||
%backgroundcolor=\color{gray!10},
|
||||
showstringspaces=false,
|
||||
string=[db]{"},
|
||||
stringstyle=\color{green!50!black},
|
||||
morestring=[s][\color{black}]{\ \ "}{":},
|
||||
keywordstyle=\color{blue},
|
||||
keywords={true,false,null},
|
||||
literate=
|
||||
*{0}{{{\color{red}0}}}{1}
|
||||
{1}{{{\color{red}1}}}{1}
|
||||
{2}{{{\color{red}2}}}{1}
|
||||
{3}{{{\color{red}3}}}{1}
|
||||
{4}{{{\color{red}4}}}{1}
|
||||
{5}{{{\color{red}5}}}{1}
|
||||
{6}{{{\color{red}6}}}{1}
|
||||
{7}{{{\color{red}7}}}{1}
|
||||
{8}{{{\color{red}8}}}{1}
|
||||
{9}{{{\color{red}9}}}{1}
|
||||
{.}{{{\color{red}.}}}{1}
|
||||
{:}{{{\color{gray}{:}}}}{1}
|
||||
{,}{{{\color{gray}{,}}}}{1}
|
||||
{\{}{{{\color{gray}{\{}}}}{1}
|
||||
{\}}{{{\color{gray}{\}}}}}{1}
|
||||
{[}{{{\color{gray}{[}}}}{1}
|
||||
{]}{{{\color{gray}{]}}}}{1},
|
||||
}
|
||||
|
||||
\usepackage{csquotes}
|
||||
|
||||
@@ -483,9 +528,14 @@ Alcune tappe importanti nella storia di PeerTube includono:
|
||||
|
||||
\section{Stack tecnologico}
|
||||
|
||||
Fino alla versione 6.0.0, PeerTube supportava sia HLS su WebRTC-P2P (noto anche come `HLS con P2P') sia WebTorrent.
|
||||
PeerTube è combina diverse tecnologie per fornire una piattaforma di streaming video decentralizzata e federata. La sua architettura si basa su un mix di tecnologie web moderne, tra cui Node.js, PostgreSQL, WebRTC etc.
|
||||
|
||||
WebTorrent è una reimplementazione del protocollo BitTorrent su WebRTC. Ogni server PeerTube funge da tracker torrent, mentre i browser degli utenti che visualizzano un video partecipano attivamente alla sua distribuzione.
|
||||
Interessante caratteristica è che PeerTube è progettato per essere estensibile consentendo agli sviluppatori e admin di aggiungere nuove funzionalità e miglioramenti senza dover modificare il codice sorgente principale. Questo approccio facilita la creazione di plugin e moduli personalizzati, che possono essere utilizzati per estendere le funzionalità della piattaforma.
|
||||
Per esempio, di default, PeerTube non ha alcun supporto integrato per le chat room in diretta, ma è possibile installare un plugin molto popolare che consente di integrare un sistema di chat in tempo reale durante le dirette streaming. \cite{wiki:PeerTube}
|
||||
|
||||
Riguardo invece la parte di distribuzione dei video, fino alla versione 6.0.0, PeerTube supportava sia HLS su WebRTC-P2P (noto anche come `HLS con P2P') sia WebTorrent.
|
||||
|
||||
WebTorrent è una re-implementazione del protocollo BitTorrent su WebRTC. Ogni server PeerTube funge da tracker torrent, mentre i browser degli utenti che visualizzano un video partecipano attivamente alla sua distribuzione.
|
||||
|
||||
\
|
||||
|
||||
@@ -584,7 +634,7 @@ Requisiti del browser per P2P Media Loader:
|
||||
Il funzionamento di P2P Media Loader è il seguente:
|
||||
Un browser web esegue un lettore video integrato con la libreria P2P Media Loader. Un'istanza di P2P Media Loader è chiamata peer. Molti peer formano una rete P2P.
|
||||
|
||||
P2P Media Loader inizia a scaricare i segmenti iniziali dei media tramite HTTP(S) dal server di origine o CDN. Questo consente di avviare la riproduzione dei video più velocemente. In caso di assenza di peer, il video viene scaricato traduzionalmente HTTP.
|
||||
P2P Media Loader inizia a scaricare i segmenti iniziali dei media tramite HTTP(S) dal server di origine o CDN. Questo consente di avviare la riproduzione dei video più velocemente. In caso di assenza di peer, il video viene scaricato tradizionalmente con HTTP.
|
||||
|
||||
Successivamente, P2P Media Loader invia i dettagli dello stream e i dettagli della sua connessione (candidati ICE) ai tracker di WebTorrent e ottiene da loro l'elenco di altri peer che stanno scaricando lo stesso stream di media.
|
||||
|
||||
@@ -662,7 +712,7 @@ WebRTC utilizza il protocollo ICE (Interactive Connectivity Establishment) menzi
|
||||
|
||||
\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, e di conseguenza Novage P2P Media loader utilizza come menzionato prima un WebTorrent Tracker some sistemma di signaling che utilizza un algoritmo del tutto simile a quello di BitTorrent dato che il protocollo funziona esattamente come il protocollo BitTorrent, ma utilizza WebRTC invece di TCP/uTP come protocollo di trasporto.
|
||||
L'efficienza del sistema P2P dipende in modo cruciale dall'algoritmo utilizzato per selezionare i peer da cui scaricare i dati. PeerTube, e di conseguenza Novage P2P Media loader utilizza come menzionato prima un WebTorrent Tracker some sistema di signaling che utilizza un algoritmo del tutto simile a quello di BitTorrent dato che il protocollo funziona esattamente come il protocollo BitTorrent, ma utilizza WebRTC invece di TCP/uTP come protocollo di trasporto.
|
||||
|
||||
La specifica BitTorrent, versione 1.0, definisce vari algoritmi per la selezione dei peer; i peer vengono selezionati attraverso una combinazione di azioni da parte del tracker e dei singoli client.
|
||||
Dalla parte del tracker:
|
||||
@@ -687,7 +737,7 @@ Questo processo determina quali peer il client utilizzerà attivamente per scari
|
||||
\section{Sistema di monitoraggio integrato con OpenTelemetry}
|
||||
|
||||
OpenTelemetry è un framework e un toolkit open-source per l'osservabilità. Standardizza la generazione, l'esportazione e la raccolta di dati di telemetria, come tracce, metriche e log, ed è progettato per essere indipendente dai fornitori e dagli strumenti stessi.
|
||||
Affronta la sfida delle pratiche di osservabilità frammentate tra diversi linguaggi, infrastrutture e fornitori, offrendo un unico set di API, specifiche e strumenti per l'instrumentazione. Questo elimina così il \textit{vendor lock-in} e la necessità di adattarsi a più sistemi proprietari.\cite{opentelemetryWhatOpenTelemetry}
|
||||
Affronta la sfida delle pratiche di osservabilità frammentate tra diversi linguaggi, infrastrutture e fornitori, offrendo un unico set di API, specifiche e strumenti per l'istrumentazióne. Questo elimina così il \textit{vendor lock-in} e la necessità di adattarsi a più sistemi proprietari.\cite{opentelemetryWhatOpenTelemetry}
|
||||
|
||||
PeerTube integra OpenTelemetry, per il monitoraggio delle prestazioni complessive del server, raccogliendo metriche come:
|
||||
|
||||
@@ -710,7 +760,7 @@ A dicembre 2023, il team di PeerTube ha pubblicato un articolo in cui va ad anal
|
||||
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.
|
||||
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, stando quanto detto degli sviluppatori di PeerTube.
|
||||
|
||||
\
|
||||
|
||||
@@ -780,7 +830,7 @@ Per i nostri test abbiamo utilizzato una combinazione di tecnologie open source
|
||||
|
||||
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 \footnote{Hypervisor: Software che consente di eseguire più sistemi operativi su singolo hardware.}\textit{Hypervisor} per la virtualizzazione.
|
||||
La differenza 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 \footnote{Hypervisor: Software che consente di eseguire più sistemi operativi su singolo hardware.}\textit{Hypervisor} per la virtualizzazione.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -790,11 +840,11 @@ La differeneza tra docker e una macchina virtuale è che i container Docker cond
|
||||
|
||||
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
|
||||
\item \textbf{Docker Engine}: Il core del sistema, responsabile della creazione e gestione dei container nonché il processo 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 \footnote{API: sinonimo di Application Programming Interface.} \textit{API} per interagire con Docker Engine.
|
||||
\item \textbf{Docker Image}: Un \textit{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 \textit{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 \textit{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 \textit{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.
|
||||
\item \textbf{Docker Image}: Un \textit{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 \textit{stateless} e immutabili.
|
||||
\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 \textit{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 forniscono un metodo semplice e immediato per condividere dati tra i container e l'host.\\La comunicazione tra container avviene tramite la creazione di \textit{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]
|
||||
@@ -803,11 +853,11 @@ In se Docker è composto da 4 componenti principali:
|
||||
\caption{Docker Overview.}
|
||||
\end{figure}
|
||||
|
||||
Approfondendo il discorso del networking, Docker mette a disposizione varti tipi di reti per la comunicazione tra container, i 3 principali sono:
|
||||
Approfondendo il discorso del networking, Docker mette a disposizione vari tipi di reti per la comunicazione tra container, i 3 principali sono:
|
||||
\begin{itemize}
|
||||
\item \textbf{Bridge}: È la rete di default che viene creata quando si installa Docker. I container connessi a questa rete possono comunicare tra loro e con il host, ma non possono comunicare con i container in altre reti.
|
||||
\item \textbf{Host}: I container connessi a questa rete, condividono la rete dell'host, quindi non hanno bisogno di fare \textit{port mapping} per comunicare con il mondo esterno.
|
||||
\item \textbf{None}: I container connessi a questa rete non hanno accesso ad acluna rete, quindi non possono comunicare con altri container o con l'esterno.
|
||||
\item \textbf{None}: I container connessi a questa rete non hanno accesso ad alcuna rete, quindi non possono comunicare con altri container o con l'esterno.
|
||||
\end{itemize}
|
||||
|
||||
\begin{figure}[H]
|
||||
@@ -827,7 +877,7 @@ Telegraf è un agente di raccolta di metriche open source sviluppato da InfluxDa
|
||||
\caption{Architettura Telegraf.}
|
||||
\end{figure}
|
||||
|
||||
Scritto in \textit{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.
|
||||
Scritto in \textit{Go}, Telegraf è dotato 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}
|
||||
@@ -857,14 +907,14 @@ Combina la capacità di scalare orizzontalmente con funzionalità come indici se
|
||||
Un database orientato ai documenti sostituisce il concetto di `riga' con un modello più flessibile, il `documento'. Grazie alla possibilità di includere documenti incorporati e array, l’approccio orientato ai documenti permette di rappresentare relazioni gerarchiche complesse all'interno di un singolo record.
|
||||
Non ci sono schemi predefiniti: le chiavi e i valori di un documento non hanno tipi o dimensioni fisse. L'assenza di uno schema rigido rende più semplice aggiungere o rimuovere campi secondo necessità. In generale, questo accelera lo sviluppo, permettendo agli sviluppatori di iterare rapidamente e sperimentare con facilità rendendo possibile testare diversi modelli di dati e scegliere quello più adatto alle proprie esigenze.
|
||||
|
||||
MongoDB è progettato per essere un database generi co, quindi, oltre alle operazioni di interimento, lettura, aggiornamento e eliminazione dei dati (\textit{CRUD}), offre alcune funzionalità uniche in più, tra cui:
|
||||
MongoDB è progettato per essere un database generi co, quindi, oltre alle operazioni di inserimento, lettura, aggiornamento e eliminazione dei dati (\textit{CRUD}), offre alcune funzionalità uniche in più, tra cui:
|
||||
\begin{itemize}
|
||||
\item \textbf{Indicizzazioni}: Indici di diversi tipi, tra cui indici singoli, composti, geospaziali e testuali. Gli indici possono essere creati per qualsiasi campo all'interno di un documento, consentendo di ottimizzare le query per le prestazioni.
|
||||
\item \textbf{Aggregazioni}: Un'ampia gamma di operazioni di aggregazione, come \textit{group}, \textit{match}, \textit{project} e \textit{sort}, che consentono di eseguire query complesse e analisi dei dati direttamente nel database.
|
||||
\item \textbf{Collezioni speciali}: Collezioni speciali come le collezioni\textit{time-series} e le collezioni \textit{time-to-live}, che semplificano la gestione di dati temporali e di dati che devono essere eliminati dopo un certo periodo di tempo come ad esempio le sessioni utente.
|
||||
\end{itemize}
|
||||
|
||||
MongoDB memorizza i record di dati come documenti (nello specifigo documenti \textit{BSON}, ovvero una rappresentazione binaria di documenti in formato \textit{JSON}), che sono raggruppati in collezioni. Un database contiene una o più collezioni di documenti.
|
||||
MongoDB memorizza i record di dati come documenti (nello specifico documenti \textit{BSON}, ovvero una rappresentazione binaria di documenti in formato \textit{JSON}), che sono raggruppati in collezioni. Un database contiene una o più collezioni di documenti.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
@@ -888,9 +938,9 @@ Infine, il MongoDB Query Language Aggregation Framework, è un set di processi c
|
||||
|
||||
Python è un linguaggio di programmazione ad alto livello, interpretato, orientato agli oggetti e con semantica dinamica. È progettato per essere facile da leggere e scrivere, con una sintassi pulita e chiara che favorisce la leggibilità del codice. Python è noto per la sua facilità d'uso e la sua versatilità, che lo rendono adatto a una vasta gamma di applicazioni, dallo sviluppo web alla data science, all'automazione dei processi.
|
||||
|
||||
Essendo un linguaggio interpretato, Python non richiede una fase di compilazione, ma viene eseguito direttamente da un \textit{interpreter}. Questo lo rende particolarmente adatto per lo sviluppo rapido di applicazioni e per l'iterazione veloce durante lo sviluppo. Python è anche noto per la sua vasta libreria standard, che fornisce un'ampia gamma di moduli e pacchetti pronti all'uso per svolgere una varietà di compiti comuni e per auesto viene utilizzato spesso per fare `data science'.\cite{10.5555/1593511}
|
||||
Essendo un linguaggio interpretato, Python non richiede una fase di compilazione, ma viene eseguito direttamente da un \textit{interpreter}. Questo lo rende particolarmente adatto per lo sviluppo rapido di applicazioni e per l'iterazione veloce durante lo sviluppo. Python è anche noto per la sua vasta libreria standard, che fornisce un'ampia gamma di moduli e pacchetti pronti all'uso per svolgere una varietà di compiti comuni e per questo viene utilizzato spesso per fare `data science'.\cite{10.5555/1593511}
|
||||
|
||||
L'indentazione è parte fontamentale in quanto, a differenza di altri linguaggi di programmazione dove l'indentazione è solo una convenzione, in Python è obbligatoria e definisce la struttura del codice. Questo rende il codice più leggibile e coerente, ma richiede anche attenzione per mantenere una corretta struttura del codice.
|
||||
L'indentazione è parte fondamentale in quanto, a differenza di altri linguaggi di programmazione dove l'indentazione è solo una convenzione, in Python è obbligatoria e definisce la struttura del codice. Questo rende il codice più leggibile e coerente, ma richiede anche attenzione per mantenere una corretta struttura del codice.
|
||||
|
||||
\break
|
||||
|
||||
@@ -966,9 +1016,9 @@ Il funzionamento dei WebDriver può essere riassunto in alcuni passaggi chiave:
|
||||
\item Dopo l'esecuzione di tutte le azioni, il browser si chiude e il driver comunica i risultati al client.
|
||||
\end{itemize}
|
||||
|
||||
Affinché il driver possa comunicare correttamente con il browser, è fondamentale che il browser stessso sia installato sul sistema, e che il sistema e il suo ambiente sia configurato correttamente, con tutti i prerequisiti necessari per l'esecuzione dei test.
|
||||
Affinché il driver possa comunicare correttamente con il browser, è fondamentale che il browser stesso sia installato sul sistema, e che il sistema e il suo ambiente sia configurato correttamente, con tutti i prerequisiti necessari per l'esecuzione dei test.
|
||||
|
||||
Un altro componente messo a dispoizione da Selenium è, \textit{Selenium Grid}, che permette di eseguire test su più macchine e browser remoti contemporaneamente, riducendo i tempi di esecuzione e migliorando l'efficienza dei test, instradando i comandi inviati dal client alle istanze remote dei browser ed è composto da 2 componenti principali:
|
||||
Un altro componente messo a disposizione da Selenium è, \textit{Selenium Grid}, che permette di eseguire test su più macchine e browser remoti contemporaneamente, riducendo i tempi di esecuzione e migliorando l'efficienza dei test, instradando i comandi inviati dal client alle istanze remote dei browser ed è composto da 2 componenti principali:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Hub}: Il server principale che funge da punto di ingresso per i test. Riceve i comandi dai client e li instrada alle istanze dei browser remote.
|
||||
@@ -1012,7 +1062,7 @@ L'uso di webrtc-internals con il processo di creazione/caricamento dei dump pres
|
||||
WebRTC Internals Exporter risolve questi problemi abilitando l'esportazione delle metriche verso un servizio chiamato \textit{Prometheus PushGateway}.
|
||||
Prometheus PushGateway è un servizio progettato per permettere a lavori effimeri e batch di esporre le proprie metriche a Prometheus. Poiché questi processi potrebbero non esistere abbastanza a lungo da essere interrogati direttamente, possono invece inviare le loro metriche al PushGateway, garantendo così la raccolta dei dati.
|
||||
|
||||
Tecnicamente l'estensione funziona in questo modo: viene precaricato un codice JavaScript che sovrascrive la classe globale \textit{RTCPeerConnection}.
|
||||
Tecnicamente l'estensione funziona in questo modo: viene pre-caricato un codice JavaScript che sovrascrive la classe globale \textit{RTCPeerConnection}.
|
||||
|
||||
La nuova classe assegna un ID casuale a tutti gli oggetti peer connection creati e li memorizza all'interno dell'oggetto \textit{webrtcInternalExporter}. L'utente può abilitare l'estensione per la scheda attualmente aperta facendo clic sull'icona dell'estensione e attivando la relativa checkbox.
|
||||
|
||||
@@ -1022,7 +1072,7 @@ Il metodo \textit{getStats} è un metodo standardizzato definito nell'API WebRTC
|
||||
|
||||
\
|
||||
|
||||
Questo progetto fa uso di una \footnote{Disponibile qui: \url{https://gitea.kobim.cloud/kobim/peertube-collector/src/branch/main/webrtc-internals-exporter}} \textbf{versione altamente modificata} di WebRTC Internals Exporter, per adattarsi alle nostre esigenze di test e automazione. In particolare, abbiamo modificato le funzionalità:
|
||||
Questo progetto fa uso di una \footnote{Disponibile qui: \url{https://gitlab.di.unimi.it/mirko.milovanovic/peertube-collector/-/tree/main/webrtc-internals-exporter}} \textbf{versione altamente modificata} di WebRTC Internals Exporter, per adattarsi alle nostre esigenze di test e automazione. In particolare, abbiamo modificato le funzionalità:
|
||||
|
||||
\begin{itemize}
|
||||
\item Abilitare l'esportazione delle metriche WebRTC verso un \textit{endpoint HTTP RESTful} al posto di Prometheus PushGateway, con una formattazione dei dati personalizzata, ma sempre basata su JSON.
|
||||
@@ -1032,100 +1082,101 @@ Questo progetto fa uso di una \footnote{Disponibile qui: \url{https://gitea.kobi
|
||||
\end{itemize}
|
||||
|
||||
\newpage
|
||||
\lstset{language=json}
|
||||
\begin{lstlisting}[caption={Esempio di dati JSON con le metriche esportate da WebRTC Internals Exporter}, captionpos=b, basicstyle=\scriptsize]
|
||||
{
|
||||
_id: ObjectId('67cf2a286904313f4e5ad32c'),
|
||||
player: {
|
||||
Codecs: {
|
||||
Audio: 'mp4a.40.2',
|
||||
Video: 'avc1.64002a'
|
||||
"_id": "67cf2a286904313f4e5ad32c",
|
||||
"player": {
|
||||
"Codecs": {
|
||||
"Audio": "mp4a.40.2",
|
||||
"Video": "avc1.64002a"
|
||||
},
|
||||
"Connection Speed": {
|
||||
"Granularity": "s",
|
||||
"Speed": 16777216
|
||||
},
|
||||
"Download Breakdown": {
|
||||
"Peers": 0,
|
||||
"Server": 11534336
|
||||
},
|
||||
"Live Latency": {
|
||||
"Edge": 0,
|
||||
"Latency": 21
|
||||
},
|
||||
"Network Activity": {
|
||||
"Down": 7340032,
|
||||
"Up": 0
|
||||
},
|
||||
"P2P": "enabled",
|
||||
"Player mode": "p2p-media-loader",
|
||||
"Resolution": "1080p",
|
||||
"Total Transfered": {
|
||||
"Down": 11534336,
|
||||
"Up": 0
|
||||
},
|
||||
"Video UUID": "70663bee-df65-4080-84bb-eefc5a11ab75",
|
||||
...
|
||||
},
|
||||
'Connection Speed': {
|
||||
Granularity: 's',
|
||||
Speed: 16777216
|
||||
"peers": [
|
||||
{
|
||||
"connectionState": "new",
|
||||
"iceCandidateErrors": [
|
||||
{
|
||||
"errorCode": 701,
|
||||
"errorText": "STUN host lookup received error.",
|
||||
"timestamp": 1741629977060,
|
||||
"url": "stun:stunserver2024.stunprotocol.org:3478"
|
||||
},
|
||||
...
|
||||
],
|
||||
"iceCandidates": [
|
||||
{
|
||||
"candidate": "candidate: 3130924284 1 udp 2113937151 172.17.0.2 43668...",
|
||||
"component": "rtp",
|
||||
"foundation": "3130924284",
|
||||
"port": 43668,
|
||||
"priority": 2113937151,
|
||||
"protocol": "udp",
|
||||
"relatedAddress": null,
|
||||
"relatedPort": null,
|
||||
"sdpMLineIndex": 0,
|
||||
"sdpMid": "0",
|
||||
"tcpType": null,
|
||||
"timestamp": 1741629977042,
|
||||
"type": "host",
|
||||
"usernameFragment": "6V/z"
|
||||
},
|
||||
...
|
||||
],
|
||||
"iceConnectionState": "new",
|
||||
"iceGatheringState": "complete",
|
||||
"id": "0dfd00af-518b-46c3-a2de-bc3330da9312",
|
||||
"signalingState": "have-local-offer",
|
||||
"url": "https://tube.kobim.cloud/w/eT1NZibmwMy6bx6N2YGLwr",
|
||||
"values": [
|
||||
{
|
||||
"bytesReceived": 0,
|
||||
"bytesSent": 0,
|
||||
"id": "D1",
|
||||
"label": "01e722a46bc1440994d511d27e86171d976d105a",
|
||||
"messagesReceived": 0,
|
||||
"messagesSent": 0,
|
||||
"protocol": "",
|
||||
"state": "connecting",
|
||||
"timestamp": 1741629979445.746,
|
||||
"type": "data-channel"
|
||||
},
|
||||
...
|
||||
]
|
||||
}
|
||||
],
|
||||
"tags": {
|
||||
"host": "selenium-nbg1-node-5-instance-1",
|
||||
"session": "64001538ac0eb86fafc5ed531b96ff7c",
|
||||
"url": "https://tube.kobim.cloud/w/eT1NZibmwMy6bx6N2YGLwr"
|
||||
},
|
||||
'Download Breakdown': {
|
||||
Peers: 0,
|
||||
Server: 11534336
|
||||
},
|
||||
'Live Latency': {
|
||||
Edge: 0,
|
||||
Latency: 21
|
||||
},
|
||||
'Network Activity': {
|
||||
Down: 7340032,
|
||||
Up: 0
|
||||
},
|
||||
P2P: 'enabled',
|
||||
'Player mode': 'p2p-media-loader',
|
||||
Resolution: '1080p',
|
||||
'Total Transfered': {
|
||||
Down: 11534336,
|
||||
Up: 0
|
||||
},
|
||||
'Video UUID': '70663bee-df65-4080-84bb-eefc5a11ab75',
|
||||
...
|
||||
},
|
||||
peers: [
|
||||
{
|
||||
connectionState: 'new',
|
||||
iceCandidateErrors: [
|
||||
{
|
||||
errorCode: 701,
|
||||
errorText: 'STUN host lookup received error.',
|
||||
timestamp: 1741629977060,
|
||||
url: 'stun:stunserver2024.stunprotocol.org:3478'
|
||||
},
|
||||
...
|
||||
],
|
||||
iceCandidates: [
|
||||
{
|
||||
candidate: 'candidate:3130924284 1 udp 2113937151 172.17.0.2 43668...',
|
||||
component: 'rtp',
|
||||
foundation: '3130924284',
|
||||
port: 43668,
|
||||
priority: 2113937151,
|
||||
protocol: 'udp',
|
||||
relatedAddress: null,
|
||||
relatedPort: null,
|
||||
sdpMLineIndex: 0,
|
||||
sdpMid: '0',
|
||||
tcpType: null,
|
||||
timestamp: 1741629977042,
|
||||
type: 'host',
|
||||
usernameFragment: '6V/z'
|
||||
},
|
||||
...
|
||||
],
|
||||
iceConnectionState: 'new',
|
||||
iceGatheringState: 'complete',
|
||||
id: '0dfd00af-518b-46c3-a2de-bc3330da9312',
|
||||
signalingState: 'have-local-offer',
|
||||
url: 'https://tube.kobim.cloud/w/eT1NZibmwMy6bx6N2YGLwr',
|
||||
values: [
|
||||
{
|
||||
bytesReceived: 0,
|
||||
bytesSent: 0,
|
||||
id: 'D1',
|
||||
label: '01e722a46bc1440994d511d27e86171d976d105a',
|
||||
messagesReceived: 0,
|
||||
messagesSent: 0,
|
||||
protocol: '',
|
||||
state: 'connecting',
|
||||
timestamp: 1741629979445.746,
|
||||
type: 'data-channel'
|
||||
},
|
||||
...
|
||||
]
|
||||
}
|
||||
],
|
||||
tags: {
|
||||
host: 'selenium-nbg1-node-5-instance-1',
|
||||
session: '64001538ac0eb86fafc5ed531b96ff7c',
|
||||
url: 'https://tube.kobim.cloud/w/eT1NZibmwMy6bx6N2YGLwr'
|
||||
},
|
||||
timestamp: ISODate('2025-03-10T18:06:19.496Z')
|
||||
}
|
||||
"timestamp": "2025-03-10T18:06:19.496Z"
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\subsection{Webpack}
|
||||
@@ -1148,7 +1199,7 @@ Sulla base di quello che è stato fatto da PeerTube, abbiamo deciso di utilizzar
|
||||
|
||||
Gli script fanno utilizzo della \footnote{CLI: sinonimo di Command-line interface} \textit{CLI}, di Hetzner Cloud, che consente di gestire le risorse cloud direttamente dalla riga di comando, e sono formati da 2 parti principali: uno script per la creazione delle macchine virtuali e uno script per l'avvio dei test.
|
||||
|
||||
Rispetto a quelli originali, li abbiamo modificati per far utilizzo delle varibili d'ambiente per la configurazione del nostro sistema di test, e per sostituire Selenium Grid, con l'immagine Docker monolitica standalone che abbiamo creato.\cite{githubGitHubHetznercloudcli} \cite{framagitFramasoftPeerTube}
|
||||
Rispetto a quelli originali, li abbiamo modificati per far utilizzo delle variabili d'ambiente per la configurazione del nostro sistema di test, e per sostituire Selenium Grid, con l'immagine Docker monolitica standalone che abbiamo creato.\cite{githubGitHubHetznercloudcli} \cite{framagitFramasoftPeerTube}
|
||||
|
||||
\vfill \break
|
||||
\section{Architettura del sistema di test}
|
||||
@@ -1181,7 +1232,7 @@ Selenium e WebRTC Internals Exporter li abbiamo già descritti in precedenza, me
|
||||
|
||||
L'intero progetto è disponibile qui:
|
||||
\begin{itemize}
|
||||
\item \url{https://gitea.kobim.cloud/kobim/peertube-collector}
|
||||
\item \url{https://gitlab.di.unimi.it/mirko.milovanovic/peertube-collector}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Difficoltà incontrate e soluzioni}
|
||||
@@ -1189,9 +1240,9 @@ L'intero progetto è disponibile qui:
|
||||
Durante la creazione del sistema, abbiamo incontrato diverse difficoltà, per lo più sistemistiche, che hanno richiesto soluzioni creative per superarle. Alcune delle principali sfide sono state:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Accesso agli indirizzi IP forniti da WebRTC}: WebRTC dalle ultime versioni come misura di sicurezza e privacy, non permette più l'accesso e la visualizzazione degli indirizzi IP locali delle macchine coinvolte nella connessione grazie a tecniche di offuscazione, rendendo difficile la raccolta di queste informazioni. Per ovviare a questo problema ci siamo avvalsi di 2 soluzioni: la prima consiste nell'utilizzare una versione vecchia di Chromium, nello specifico una versone anteriore o uguale alla 129.0, in quanto in queste versioni l'offuscazione è presente ma è possibile disabilitarla tramite un flag da interfaccia grafica; la seconda soluzione invece consiste proprio nel disabilitarequesta funzionalità ma da riga di comando tramite un altro flag, all'avvio del browser.
|
||||
\item \textbf{Limitazioni delle API di Peertube}: PeerTube fornisce delle API per la gestione della piattaforma, moderazione dei video, e altro ancora, ma non fornisce API per la raccolta delle metriche dei video. Alcune metriche generiche sono esposte via OpenTelemetry ma non sono specifiche per un singolo utente o video. Per ovviare a questo problema, abbiamo utilizzato il data scraping per estrarre le metriche direttamente dalla pagina web.
|
||||
\item \textbf{Gestione delle variabili d'ambiente nell'estensione Chrome}: WebRTC Internals Exporter è un'estensione per Chromium che consente di esportare le metriche WebRTC da un browser in un formato leggibile e analizzabile. Tuttavia, l'estensione non supporta la sostituzione delle variabili d'ambiente nel codice JavaScript, in quanto viene caricata ed eseguita runtime in un ambiente isolato, rendendo difficile la configurazione dinamica dell'estensione. L'utilizzo di WebPack ci consente di configurare l'estensione in fase di complilazione, sostituendo le variabili d'ambiente con i valori corretti prima di caricarla nel browser.
|
||||
\item \textbf{Accesso agli indirizzi IP forniti da WebRTC}: WebRTC dalle ultime versioni come misura di sicurezza e privacy, non permette più l'accesso e la visualizzazione degli indirizzi IP locali delle macchine coinvolte nella connessione grazie a tecniche di offuscazione, rendendo difficile la raccolta di queste informazioni. Per ovviare a questo problema ci siamo avvalsi di 2 soluzioni: la prima consiste nell'utilizzare una versione vecchia di Chromium, nello specifico una versione anteriore o uguale alla 129.0, in quanto in queste versioni l'offuscazione è presente ma è possibile disabilitarla tramite un flag da interfaccia grafica; la seconda soluzione invece consiste proprio nel disabilitare questa funzionalità ma da riga di comando tramite un altro flag, all'avvio del browser.
|
||||
\item \textbf{Limitazioni delle API di PeerTube}: PeerTube fornisce delle API per la gestione della piattaforma, moderazione dei video, e altro ancora, ma non fornisce API per la raccolta delle metriche dei video. Alcune metriche generiche sono esposte via OpenTelemetry ma non sono specifiche per un singolo utente o video. Per ovviare a questo problema, abbiamo utilizzato il data scraping per estrarre le metriche direttamente dalla pagina web.
|
||||
\item \textbf{Gestione delle variabili d'ambiente nell'estensione Chrome}: WebRTC Internals Exporter è un'estensione per Chromium che consente di esportare le metriche WebRTC da un browser in un formato leggibile e analizzabile. Tuttavia, l'estensione non supporta la sostituzione delle variabili d'ambiente nel codice JavaScript, in quanto viene caricata ed eseguita runtime in un ambiente isolato, rendendo difficile la configurazione dinamica dell'estensione. L'utilizzo di WebPack ci consente di configurare l'estensione in fase di compilazione, sostituendo le variabili d'ambiente con i valori corretti prima di caricarla nel browser.
|
||||
\item \textbf{Raccolta dei dati dei test su macchine virtuali distribuite}: Data la distribuzione geografica delle nostre macchine virtuali di test, abbiamo dovuto affrontare la sfida di raccogliere ed aggregare i dati in modo efficiente e coordinato. Questa sfida l'abbiamo risolta utilizzando Telegraf come agente di raccolta dati su ogni VM, configurandolo per inviare le metriche ad un'istanza centrale di MongoDB. MongoDB è stato scelto per il suo supporto nativo a documenti JSON e per la capacità di gestire grandi volumi di dati time-series provenienti da fonti eterogenee.Le API di Hetzner Cloud ci hanno permesso di automatizzare il deployment e la configurazione di tutte queste componenti su macchine distribuite in diverse regioni geografiche.
|
||||
\end{itemize}
|
||||
|
||||
@@ -1204,8 +1255,10 @@ Il funzionamento dello script è relativamente semplice; vengono eseguiti dei pa
|
||||
Importante particolarità dello script è la possibilità di creare e caricare plugin personalizzati che permettono di estrarre metriche di vario tipo da potenzialmente qualsiasi pagina web e non solo da PeerTube. Questo potenzialmente permette di estendere il sistema di test a qualsiasi altra piattaforma di video streaming, o di qualsiasi altro tipo, semplicemente creando un plugin personalizzato.
|
||||
Questa funzionalità è stata implementata utilizzando le \textit{Abstract Base Classes} di Python, che permettono di definire delle classi base che devono essere implementate dalle classi derivate, e che permettono di definire delle interfacce comuni.
|
||||
|
||||
\break
|
||||
\lstset{language=Python}
|
||||
\begin{lstlisting}[caption={Abstract Base Classes}, captionpos=b, basicstyle=\scriptsize]
|
||||
# Abstract Base Classes for Plugins
|
||||
# Abstract Base Classes for Plugins
|
||||
class StatsSetupPlugin(abc.ABC):
|
||||
@abc.abstractmethod
|
||||
def setup_stats(
|
||||
@@ -1254,8 +1307,8 @@ I passaggi presenti in figura \ref{fig:architettura-collector} possono essere ri
|
||||
\item \textbf{Avvio del browser}: Viene avviato il browser ed aperta la pagina del video specificato tramite Selenium, con l'estensione di WebRTC Internals Exporter installata ed abilitata. Viene anche avviato in ascolto un server HTTP in background per ricevere le metriche WebRTC tramite un endpoint locale POST dedicato.
|
||||
\item \textbf{Avvio del test}: Viene caricata la pagina del video e tramite Selenium viene controllato che il video sia in riproduzione tramite il controllo dell'esistenza del bottone play.
|
||||
\item \textbf{Raccolta delle metriche WebRTC}: L'estensione per WebRTC inizia a raccogliere le metriche e ogni 2 secondi circa le invia allo script principale. Viene quindi di fatto instaurato un ciclo che viene usato dallo script come sorgente di clock per la raccolta delle altre metriche.
|
||||
\item \textbf{Raccolta delle metriche video di PeerTube}: Utilizzando BeautifulSoup, vengono trasformate e raccolte le metriche del player video di PeerTube, come la qualità del video, il buffering, quantità di dati trasferiti, la latenza, e altro ancora. Il tutto viee convertito in un formato JSON.
|
||||
\item \textbf{Invio delle metriche a Telegraf}: Le metriche raccolte, vengono inviate a Telegraf tramite una socket di sistema, per l'elaborazione e l'invio al database finale, nel nostro caso MongoDB. C'è un passaggio fondamentale però che Telegraf esegue, ed è quello di fare \textit{string-join} dei dati JSON, ovvero di `appiattire' e trasformare i dati in una stringa, per poi inviarli al database. Questo viene fatto in quanto Telegraf, utilizzando il plugin di input per il formato JSON, converte gli array \textbf{in singole metriche separate}, e non come un unico documento, perdendo quindi la struttura originale dei dati. In se qusto non è un problema, ma per la nostra analisi, è fondamentale mantenere la struttura originale dei dati per facilitarci il lavoro. Infine per ricavare i documenti interi, un ulteriore passaggio finale va effettuato nel database, in differita, per convertirli da stringhe ad oggetti JSON validi.
|
||||
\item \textbf{Raccolta delle metriche video di PeerTube}: Utilizzando BeautifulSoup, vengono trasformate e raccolte le metriche del player video di PeerTube, come la qualità del video, il buffering, quantità di dati trasferiti, la latenza, e altro ancora. Il tutto viene convertito in un formato JSON.
|
||||
\item \textbf{Invio delle metriche a Telegraf}: Le metriche raccolte, vengono inviate a Telegraf tramite una socket di sistema, per l'elaborazione e l'invio al database finale, nel nostro caso MongoDB. C'è un passaggio fondamentale però che Telegraf esegue, ed è quello di fare \textit{string-join} dei dati JSON, ovvero di `appiattire' e trasformare i dati in una stringa, per poi inviarli al database. Questo viene fatto in quanto Telegraf, utilizzando il plugin di input per il formato JSON, converte gli array \textbf{in singole metriche separate}, e non come un unico documento, perdendo quindi la struttura originale dei dati. In se questo non è un problema, ma per la nostra analisi, è fondamentale mantenere la struttura originale dei dati per facilitarci il lavoro. Infine per ricavare i documenti interi, un ulteriore passaggio finale va effettuato nel database, in differita, per convertirli da stringhe ad oggetti JSON validi.
|
||||
\end{itemize}
|
||||
|
||||
Va inoltre evidenziata la scelta di utilizzare un solo script Python per coordinare il tutto, sia l'inizializzazione che raccolta delle metriche dalle pagine web e dalla estensione esterna, in quanto questo ha semplificato la gestione e soprattutto la creazione del sistema e permette come bonus di avere un unico punto di controllo per l'intero processo.
|
||||
|
Reference in New Issue
Block a user