feat: enhance test scenarios description and update statistics collected for PeerTube use cases

Tesi.tex

@@ -1020,6 +1020,11 @@ Nello specifico il \textit{collector} è composto da 3 parti principali:
 
 Selenium e WebRTC Internals Exporter li abbiamo già descritti in precedenza, mentre il Python script è il cuore del sistema, che si occupa di coordinare le altre componenti, di avviare e fermare i test, di raccogliere i dati, aggregarli e di inviarli a Telegraf per l'invio al database.
 
+L'intero progetto è disponibile qui:
+\begin{itemize}
+    \item \url{https://gitea.kobim.cloud/kobim/peertube-collector}
+\end{itemize}
+
 \subsection{Difficoltà incontrate e soluzioni}
 
 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:
@@ -1091,7 +1096,7 @@ I passaggi presenti in figura \ref{fig:architettura-collector} possono essere ri
     \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. 
+    \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.
 \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.
@@ -1170,21 +1175,20 @@ Il diagramma finale dell'architettura del nostro sistema è il seguente:
 
 \section{Casi d'uso e scenari di test riprodotti}
 
-Abbiamo riprodotto i due principali scenari descritti nell'articolo di PeerTube:
+Come descritto in precedenza, abbiamo riprodotto due scenari di test principali dei 4 casi d'uso descritti nell'articolo di PeerTube per motivi di tempo e risorse. Questi sono:
 
 \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
+    \item Live streaming con impostazione \textit{Normal Latency}: Il setup standard di PeerTube
+    \item Live streaming con impostazione \textit{High Latency}: La configurazione che privilegia il P2P a scapito della latenza
 \end{itemize}
 
-Per ciascuno scenario, abbiamo variato il numero di spettatori (10, 30, 50, 100) e misurato:
+Per ciascun scenario, abbiamo impostato il numero di spettatori/utenti a 5 (limite di Hetzner Cloud per account nuovi) e racolto le seguenti statistiche:
 
 \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
+    \item Statistiche del player web (risoluzione, bitrate, buffering, latenza, ecc.)
+    \item Statistiche WebRTC (peer connection, ICE candidates, ICE connection state, ecc.)
+    \item Informazioni identificative dei singoli peer (url del video, ID sessione, ID peer)
+    \item Timestamp di raccolta
 \end{itemize}
 
 \chapter{Analisi dei dati e risultati}
@@ -1197,7 +1201,6 @@ Per ciascuno scenario, abbiamo variato il numero di spettatori (10, 30, 50, 100)
 
 \nocite{*}
 \printbibliography
-\sloppy
 \addcontentsline{toc}{chapter}{Bibliografia}
 
 \end{document}