universit¬ degli studi di napoli federico analisi a livello pacchetto del

Transcript

81,9(56,7¬'(*/,678',',1$32/,)('(5,&2,,
)$&2/7¬',,1*(*1(5,$
&2562',/$85($,1
,1*(*1(5,$,1)250$7,&$
&/$66('(//(/$85((,1,1*(*1(5,$'(//¶,1)250$=,21(1
',3$57,0(172',,1)250$7,&$(6,67(0,67,&$
(/$%25$72',/$85($
$1$/,6,$/,9(//23$&&+(772
'(/75$)),&2',
08/7,3/$<(51(7:25.*$0(6
5(/$725( &+02352)$1721,23(6&$3(¶
3,(7520$5&+(77$
&25(/$725(
&$1','$72
0$75
,1*$/%(572'$,1277,
$112$&&$'(0,&2
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea
Analisi a livello pacchetto del traffico di Multiplayer
Network Games
Anno Accademico 2006/2007
relatore
Ch.mo prof. Antonio Pescapè
correlatore
Ing. Alberto Dainotti
candidato
Pietro Marchetta
matr. 534/1475
Ai miei genitori
e a Giusi
Ringraziamenti
E’ proprio vero, la vita è costellata di tappe e il prossimo traguardo, a quanto pare, è
molto vicino. Sebbene ogni arrivo nasconda una nuova partenza, nulla può impedirmi
di assaporare fino in fondo questo momento ricordando cosa sono stati per me questi
anni trascorsi all’università: i sacrifici, le delusioni, le soddisfazioni; l’ansia prima di
ogni esame, il mal di testa che seguiva immediatamente dopo; le corse per l’ultimo treno sempre puntuale nel partire ma mai ad arrivare; i panini divorati di fronte la facoltà;
le 6:35 del mattino; i voti sudati; i professori buoni e quelli indisponenti; i 5 minuti di
pausa concessi e quelli non concessi; le risate grasse in cortile; le aule studio sempre
piene; le materie che mi hanno fatto luccicare gli occhi; la passione dei professori;
l’Alifana, amica e nemica in tante ore di viaggio.
Tante sono le persone che voglio ringraziare qui, nero su bianco, sperando di non
dimenticare nessuno. Sarà difficile ricordarle tutte, ancor più difficile sarà ringraziarle
adeguatamente.
Grazie mamma, per il tuo volermi un bene sincero, per ogni caffè che hai preparato per me alle 6 del mattino, per tutte le volte che sei venuta in camera mia a sederti
accanto a me a chiacchierare del più e del meno, perché cerchi sempre di capire il mio
mondo cosı̀ distante dal tuo.
Grazie papà, perché ci sei sempre e so che in qualsiasi momento posso contare sul
tuo appoggio. Mi dai sicurezza nell’affrontare questa vita piena di insidie.
ii
Grazie Giusi, per avermi fatto maturare in fretta col dialogo, il confronto e a volte
lo scontro, sono sempre stato affascinato e un po’ invidioso del tuo talento, spero che
la vita possa riservare per te tutte le soddisfazioni che meriti e per cui stai lottando.
Grazie Valeria, perché il tuo semplice sorridere mi fa dimenticare tutti i problemi
e in un attimo torno in pace con il mondo. La tua spensieratezza e allegria sono stati il
propellente in questi anni. Ti prego non smettere mai di sorridermi.
Grazie alle nonne per l’affetto che mi dimostrano, spero di poterle rendere sempre
orgogliose di me. Un grazie a tutta la famiglia, che mi ha incoraggiato anche quando
ero io stesso a non avere fiducia nelle mie possibilità.
Grazie Marco, prima collega poi compagno e infine amico sincero. E’ stato un
piacere studiare, viaggiare, mangiare, giocare con te. Ne abbiamo passate tante e non
smetterò mai di ringraziarti per aver condiviso con me i momenti belli e brutti di questi
anni.
Grazie agli amici storici, Luca Leo e Dario, compagni di indimenticabili avventure
nel mare dell’adolescenza. La vostra amicizia è un caldo focolare sempre pronto a
dare conforto in tempi freddi.
Grazie a Giampaolo, perché è un generatore di buon umore, riesce a tirar fuori la
parte migliore delle persone che lo circondano. Non dimenticherò mai la prima volta
che suonammo insieme in quel garage. Grazie Teresa, perché persone speciali non
possono che attirare persone speciali.
Grazie a Carlo Francesco Luca e Michele, perché è come se fossimo amici da
sempre. La nostra è un’amicizia pura e sincera, di quelle che non devi dire di averne
bisogno per ricevere una mano.
iii
Grazie ai ragazzi del gruppo e soprattutto ad Antonio, perché è per me un piacere
e un privilegio condividere la stessa passione per la musica.
Grazie al prof. Pescapè, ad Alberto e ad Alessio che mi hanno accompagnato in
questo sprint finale, perché in un clima informale mi hanno dato la possibilità di crescere a livello professionale e personale.
Grazie ancora a Mario, a Matteo, a Francesco, a Sandro Nicola e Paolo, a Daniele,
a Claudio, ai compagni di classe del liceo, ai ragazzi del laboratorio e a tutti quelli che
hanno creduto in me e che mi sono stati vicini nei momenti difficili.
E’ mio desiderio ringraziarvi dal profondo del cuore perché tutto quello che c’è di
buono in me è merito vostro, il resto è un difetto di fabbrica...
Ancora grazie...
Pietro.
iv
Sommario
Una percentuale sempre più significativa del traffico che circola sui backbone Internet
è generato da applicazioni realtime a carattere ludico. Alcuni studiosi prevedono per
il 2008 che un pacchetto su quattro possa essere ricondotto a questo tipo di applicazioni. Le infrastrutture di rete attualmente non sono in grado di supportare al meglio
il traffico interattivo. Con il proposito di aggiudicarsi una fetta del nuovo bacino di
utenti-giocatori i maggiori ISP stanno investendo nel potenziamento delle reti. Soluzioni mirate, tuttavia, non possono prescindere da uno studio approfondito del traffico
interattivo soprattutto per la sua particolare natura. In questo lavoro di tesi si è realizzato uno studio del traffico generato dal client di Counter-Strike, il più diffuso gioco
in rete della cosiddetta categoria degli “sparatutto”. Scelta l’applicazione, in seguito
a uno studio dei lavori prodotti dalla comunità scientifica sull’argomento, si è provveduto a ricreare in laboratorio tipiche situazioni di gioco: LAN party wired e wireless
e sessioni via Internet con connessioni a banda larga ADSL. Collezionando le tracce
di traffico in uscita dai client, si è realizzata una caratterizzazione statistica in termini
di interpartenze (IPT) e dimensione (PS) dei pacchetti generati dal giocatore tipo, frutto del comportamento medio di tutti i client, che ha evidenziato stabilità e invarianza
nel traffico indipendentemente dallo scenario o dal livello di attività del giocatore. Lo
studio, inoltre, evidenzia la presenza di due fasi di gioco diverse che influenzano il traffico esclusivamente in termini di PS. Attuando un procedimento che prende il nome
di fitting, è stato possibile individuare la distribuzione analitica che tra un insieme di
possibili candidate approssima meglio la distribuzione empirica, quella, cioè, osserva-
v
ta attraverso le misurazioni ripetute. A volte è stato necessario approfondire eventuali
anomalie nel comportamento di singoli client. Oltre alla caratterizzazione del traffico
generato dal client a livello pacchetto in ogni scenario e fase di gioco, si sono confermati e smentiti risultati documentati in taluni articoli accademici facendo chiarezza su
punti oggetto di teorie contrastanti. Counter-Strike è stato scelto perché rappresentativo dell’intero genere degli sparatutto, secondo quanto riportato da alcuni studiosi. La
caratterizzazione proposta potrà essere oggetto di studio per future implementazioni
in simulatori e generatori di traffico sintetico che testeranno l’effettiva capacità della
rete di supportare traffico interattivo. Inoltre, futuri studi sul traffico permetteranno di
individuare eventuali elementi comuni a giochi in rete appartenenti allo stesso genere
e a generi diversi, alla luce dei quali, potranno essere progettate soluzioni efficienti in
grado di supportare le applicazioni ludiche indipendentemente dal genere a cui esse
appartengono.
In particolare, la tesi contiene riflessioni e risultati maturati durante l’attività sperimentale condotta nel laboratorio ARCLAB della Facoltà di Ingegneria dell’Università
degli Studi di Napoli Federico II sito a via Claudio dove sono stati realizzati sia gli
esperimenti che le analisi dell’ingente quantità di materiale raccolto col supporto pratico e morale dei dottorandi. A tal proposito, è mio desiderio ringraziare gli ingg.
Dainotti e Botta e il professore Perscapè per la disponibilità e la professionalità che
hanno dimostrato nei miei confronti.
vi
Indice
Introduzione
1
2
3
4
1
Descrizione del problema . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Obiettivo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Panoramica dei videogiochi on-line . . . . . . . . . . . . . . . . . . . . . .
3
Organizzazione della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Background
7
1.1
Raccolta del materiale . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2
Sintesi del materiale raccolto . . . . . . . . . . . . . . . . . . . . . .
7
1.3
Riflessioni conclusive: scelta dell’applicazione. . . . . . . . . . . . .
22
Counter-Strike
24
2.1
Il segreto di un successo . . . . . . . . . . . . . . . . . . . . . . . .
24
2.2
Counter-Strike in letteratura . . . . . . . . . . . . . . . . . . . . . .
25
Strumenti
29
3.1
Analisi a livello pacchetto . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
Testbed degli esperimenti . . . . . . . . . . . . . . . . . . . . . . . .
30
3.3
Analisi statistica . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Analisi delle Tracce
44
4.1
LAN party: wired 4 giocatori . . . . . . . . . . . . . . . . . . . . . .
44
4.1.1
Fitting della fase attiva . . . . . . . . . . . . . . . . . . . . .
50
4.1.2
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
vii
4.2
4.3
4.4
4.1.3
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1.4
Fitting della fase inattiva . . . . . . . . . . . . . . . . . . . .
54
4.1.5
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.1.6
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.1.7
Conclusioni sullo scenario wired a 4 giocatori . . . . . . . . .
59
LAN party: wired 8 giocatori . . . . . . . . . . . . . . . . . . . . . .
60
4.2.1
62
4.2.2
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.2.3
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.2.4
Conclusioni sullo scenario wired a 8 giocatori . . . . . . . . .
66
LAN party: wireless 4 giocatori . . . . . . . . . . . . . . . . . . . .
67
4.3.1
68
4.3.2
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
4.3.3
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.3.4
Fitting della fase inattiva . . . . . . . . . . . . . . . . . . . .
73
4.3.5
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
4.3.6
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.3.7
Conclusioni sullo scenario wireless a 4 giocatori . . . . . . .
76
ADSL: 4 giocatori . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1
1 Sessione di gioco - Lato client . . . . . . . . . . . . . . .
77
77
4.4.2
78
4.4.3
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Il caso Roberto
4.4.4
4.4.5
4.5
. . . . . . . . . . . . . . . . . . . . . .
79
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
1 Sessione di gioco - Lato server . . . . . . . . . . . . . . .
84
4.4.6
2 Sessione di gioco - Lato server . . . . . . . . . . . . . . .
4.4.7
IPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
4.4.8
PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
4.4.9
Conclusione sullo scenario ADSL . . . . . . . . . . . . . . .
88
Scenari a confronto . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
viii
85
5
4.5.1
Fase Attiva . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.5.2
Fase inattiva . . . . . . . . . . . . . . . . . . . . . . . . . .
92
Conclusioni e Futuri Sviluppi
95
5.1
Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.2
Futuri sviluppi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Bibliografia
98
ix
Elenco delle figure
1
Passato e presente: a sinistra Pong (1972), a destra World of Worcraft
(2004). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1
Screenshot del videogioco Counter-Strike . . . . . . . . . . . . . . .
25
2.2
Grafici riportati negli articoli di Feng. . . . . . . . . . . . . . . . . .
26
2.3
Funzione densità di probabilità per packet-size e inter-arrival time. . .
28
3.1
I parametri IDT e PS . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.2
Testbed dello scenario wireless . . . . . . . . . . . . . . . . . . . . .
34
3.3
Testbed dello scenario ADSL . . . . . . . . . . . . . . . . . . . . . .
35
3.4
Help Inline dello script scott.m . . . . . . . . . . . . . . . . . . . . .
38
3.5
Help Inline dello script lambda-square.m . . . . . . . . . . . . . . . .
40
3.6
Help Inline dello script normmix2.m . . . . . . . . . . . . . . . . . .
41
4.1
Report.txt dello scenario wired a 4 giocatori . . . . . . . . . . . . . .
45
4.2
Wired 4pl - traffico in uscita dai client: Byterate . . . . . . . . . . . .
46
4.3
Wired 4pl - traffico in uscita dai client: Packetrate . . . . . . . . . . .
47
4.4
Wired 4pl - traffico in uscita dai client: PS Sequence . . . . . . . . .
48
4.5
Wired 4pl - PS: distribuzioni empiriche a confronto. . . . . . . . . . .
49
4.6
Wired 4pl - Fase attiva: IPT distribuzioni empiriche . . . . . . . . . .
50
4.7
TLSRND: generatore di numeri casuali secondo la Student’s T locationscale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.8
Wired 4pl - Fase attiva: Fitting IPT . . . . . . . . . . . . . . . . . . .
52
4.9
Wired 4pl - Fase attiva: PS distribuzioni empiriche . . . . . . . . . .
53
x
4.10 Wired 4pl - Fase attiva: Fitting PS . . . . . . . . . . . . . . . . . . .
54
4.11 Wired 4pl - Fase inattiva: IPT distribuzioni empiriche . . . . . . . . .
55
4.12 Wired 4pl - Fase inattiva: Fitting IPT . . . . . . . . . . . . . . . . . .
57
4.13 Wired 4pl - Fase inattiva: PS distribuzioni empiriche . . . . . . . . .
58
4.14 Wired 4pl - Fase inattiva: Fitting PS . . . . . . . . . . . . . . . . . .
58
4.15 Report.txt dello scenario wired a 8 giocatori . . . . . . . . . . . . . .
60
4.16 Wired 8pl - traffico in uscita dai client: Byterate . . . . . . . . . . . .
61
4.17 Wired 8pl - Fase attiva: IPT distribuzioni empiriche . . . . . . . . . .
62
4.18 Wired 8pl - Fase attiva: Fitting IPT . . . . . . . . . . . . . . . . . . .
64
4.19 Wired 8pl - Fase attiva: PS distribuzioni empiriche . . . . . . . . . .
65
4.20 Wired 8pl - Fitting PS: Normmix2 e Gammix a confronto. . . . . . .
66
4.21 Report.txt dello scenario wireless a 4 giocatori . . . . . . . . . . . . .
67
4.22 Wireless 4pl- traffico in uscita dai client: Byterate . . . . . . . . . . .
68
4.23 Wireless 4pl- Fase attiva: IPT distribuzioni empiriche . . . . . . . . .
69
4.24 Wireless 4pl - Fase attiva: Fitting IPT . . . . . . . . . . . . . . . . .
70
4.25 Wireless 4pl - Fase attiva: PS distribuzioni empiriche . . . . . . . . .
71
4.26 Wireless 4pl - Fase attiva: Fitting PS . . . . . . . . . . . . . . . . . .
72
4.27 Wireless 4pl - Fase inattiva: IPT distribuzioni empiriche . . . . . . .
74
4.28 Wireless 4pl - Fase inattiva: Fitting IPT . . . . . . . . . . . . . . . .
74
4.29 Wireless 4pl - Fase inattiva: PS distribuzioni empiriche . . . . . . . .
75
4.30 Wireless 4pl - Fase inattiva: Fitting PS . . . . . . . . . . . . . . . . .
76
4.31 1 Sessione ADSL - traffico in uscita dai client: Byterate . . . . . . .
4.32 1 Sessione ADSL (client)- Fase attiva: IPT distribuzioni empiriche .
4.33
4.34
4.35
4.36
4.37
4.38
4.39
4.40
1 Sessione ADSL (client)- Fase attiva: IPT in DownStream . . .
1 Sessione ADSL(server) - Fase attiva: IPT in UpStream . . . . .
1 Sessione ADSL(client) - Tracerouter del giocatore Roberto . .
1 Sessione ADSL(client)- Fase attiva: PS distribuzioni empiriche
1 Sessione ADSL(client) - Fase attiva: Fitting PS . . . . . . . . .
1 Sessione ADSL(server) - IPT distribuzioni empiriche . . . . . .
1 Sessione ADSL(server) - PS distribuzioni empiriche . . . . . .
2 Sessione ADSL(server) - traffico in uscita dai client: Byterate .
xi
78
79
. .
80
. .
80
. .
81
. .
83
. .
83
. .
84
. .
84
. .
85
4.41 2 Sessione ADSL(server) - Fase attiva: IPT distribuzioni empiriche .
4.42 2 Sessione ADSL(server) - Fase attiva: Fitting IPT . . . . . . . . . .
4.43 2 Sessione ADSL(server) - Fase attiva: PS distribuzioni empiriche . .
4.44 2 Sessione ADSL(server) - Fase attiva: Fitting PS . . . . . . . . . .
86
87
87
88
4.45 IPT - Distribuzioni empiriche in ogni scenario (Fase attiva) . . . . . .
91
4.46 PS - Distribuzioni empiriche in ogni scenario (Fase Attiva) . . . . . .
92
4.47 IPT - Distribuzioni empiriche a confronto (Fase inattiva) . . . . . . .
93
4.48 PS - Distribuzioni empiriche a confronto (Fase inattiva) . . . . . . . .
94
xii
Elenco delle tabelle
3.1
Dichiarazioni dei giocatori prima degli esperimenti. A - Areonautica I
- Ingegneria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2
Dettagli sulle macchine utilizzate dai vari giocatori . . . . . . . . . .
32
3.3
Configurazione dello switch CISCO per gli scenari LAN. . . . . . . .
33
3.4
Configurazione dello switch ENTERASYS per gli scenari ADSL. . .
35
3.5
Indirizzi IP e provider nello scenario ADSL . . . . . . . . . . . . . .
35
4.1
Dfittool: Student’s T location-scale - Fitting IPT [Wired 4pl Attiva] . .
51
4.2
Dfittool: Student’s T location-scale - Fitting IPT [Wired 4pl Inattiva] .
56
tentativo)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
tentativo)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
4.5
Dfittool: Student’s T location-scale - Fitting IPT [Wireless 4pl Attiva]
70
4.6
Dfittool: Student’s T location-scale - Fitting IPT [Wireless 4pl Inattiva]
74
Attiva] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
Attiva] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
Fase attiva - Inter-Deparute-Time: Student’s T location scale (us) . . .
90
4.10 Fase attiva - Packet Size: mix di due gaussiane (byte) . . . . . . . . .
91
4.11 Fase inattiva - Inter-Deparute-Time: Student’s T location scale (us)
.
92
4.12 Fase inattiva - Packet Size: distribuzione discreta (byte) . . . . . . . .
93
4.3 Dfittool: Student’s T location-scale - Fitting IPT [Wired 8pl Attiva (1
4.4
Dfittool: Student’s T location-scale - Fitting IPT [Wired 8pl Attiva (2
4.7 Dfittool: Student’s T location-scale - Fitting IPT [ADSL 1 Ses.(C)
4.8
4.9
Dfittool: Student’s T location-scale - Fitting IPT [ADSL 2 Ses.(S)
xiii
Introduzione
Recenti studi affermano che una fetta significativa del traffico che oggi viaggia sulla
Rete è generato da applicazioni realtime. Tra le più diffuse si vuole ricordare quelle
a carattere ludico. Si stima, infatti, che oltre il 3% di tutti i pacchetti che transitano sui backbone, le cosidette autostrade della rete, possono essere associati a solo 6
videogiochi[1]. Alcuni studiosi prevedono un aumento drammatico di questa percentuale: fino al 25% nel 2008[2]. Per capire l’entità del fenomeno basti ricordare che nel
solo 2001 Forrester Research stimava in 18 milioni di unità i videogiocatori on-line pari a un utente Internet su cinque. E’ prevedibile, inoltre, un aumento sempre maggiore
di questo numero, legato al lancio di Microsoft’s Xbox on-line e Sony’s Playstation
2 on-line e più in generale alla nuova generazione di consolle che supporteranno la
connessione ad Internet. La passione per i giochi in rete è alimentata da diversi fattori:
dalla grafica accattivante, dal realismo delle animazioni, dall’elevato coinvolgimento
che sono in grado di creare nel navigatore, dalla possibilità del cosiddetto “multiplayer” per sfidare amici e “nemici” in partite via Internet e soprattutto dalla sempre
maggiore diffusione delle connessioni a banda larga che le rendono possibili.
Descrizione del problema
E’ facile, a questo punto, intuire come milioni di videogiocatori rappresentino per gli
Internet Service Provider una opportunità di profitto consistente. Il forte interesse economico sorto intorno a questo nuovo bacino di utenza ha spinto i fornitori di servizi
a potenziare le reti che attualmente non riescono a offrire gli alti livelli di interattività richiesti. Infatti, dobbiamo registrare che, nonostante gli sforzi a supporto della
1
Quality of Service (QoS) da parte dell’IETF (Internet Engineering Task Force) come
l’identificazione di flussi di traffico privilegiato, ad oggi il traffico interattivo raggiunge
prestazioni lievemente superiori a quelle del traffico ordinario.
Tuttavia, progettare soluzioni mirate a sostegno dell’applicazioni ludiche realtime
non può prescindere da uno studio approfondito del traffico interattivo, soprattutto a
causa della sua profonda diversità sia dal canonico traffico Web (e più in generale da
quello TCP-based) sia dall’ormai affermato Peer-to-Peer. Diversi ricercatori hanno potuto constatare come la maggior parte di videogiochi on-line genera con alto tasso di
periodicità piccoli pacchetti UDP. I pacchetti sono piccoli in quanto le applicazioni richiedono che la latenza sia estremamente bassa. La periodicità è frutto della dinamica
dell’applicazione che tipicamente prevede frequenti aggiornamenti dello stato globale di gioco. Infine, i pacchetti vengono inviati attraverso il protocollo UDP perché i
client hanno la necessità di spedire pacchetti a intervalli di gran lunga inferiori rispetto
al tempo necessario a ritrasmettere i pacchetti perduti[3] senza contare il proibitivo
overhead introdotto dall’header TCP. Inoltre, la trasmissione non è influenzata dal livello di congestione della rete in quanto il protocollo non prevede alcun controllo in
tal senso.
La periodica inondazione di questi piccoli pacchetti UDP mette in crisi le reti, progettate, inizialmente, per smaltire pacchetti più grandi generati a intervalli più lunghi.
Si vengono a determinare cosı̀ ritardi e perdite che possono portare, in casi estremi,
anche al fallimento dell’applicazione realtime.
Obiettivo della tesi
In sintesi, dunque, una conoscenza approfondita del traffico generato da queste particolari applicazioni può rappresentare un buon punto di partenza per la progettazione di
soluzioni efficienti che mirino a privilegiare il traffico interattivo, ad esempio, attraverso l’adozione di nuove politiche di selezione nelle code dei nodi della rete che facilitino il passaggio di pacchetti interattivi a scapito del traffico ordinario[4]. La tesi vuole
contribuire in questo senso, studiando il comportamento del client di un’applicazione
interattiva largamente diffusa e dunque particolarmente rappresentativa. Nello specifi2
co si vuole fornire una caratterizzazione statistica e modelli analitici approssimanti del
traffico generato dal client analizzato a livello pacchetto.
Panoramica dei videogiochi on-line
I videogiochi fanno ormai parte della vita di milioni di persone e possono essere considerati un vero e proprio fenomeno culturale di massa. Sembra incredibile, eppure oggi
negli Stati Uniti si vendono più videogiochi che biglietti per il cinema. Dalla creazione del primo Pong è passato molto tempo e i videogiochi si sono evoluti di pari passo
con la tecnologia fino a diventare complessi sistemi software. Il salto di qualità si è
avuto negli anni novanta con l’avvento di Internet che ha permesso a giocatori di tutto
il mondo di superare le barriere geografiche e di allargare a livello planetario quelle
che, fino ad allora, erano state sfide a cui partecipavano poche persone, tipicamente
attraverso piccole reti locali. Non è possibile indicare in modo assoluto l’età di chi
si dedica a queste applicazioni ludiche. Esistono, infatti, videogiochi di ogni genere
capaci di destare l’attenzione anche degli utenti più smaliziati.
Figura 1: Passato e presente: a sinistra Pong (1972), a destra World of Worcraft (2004).
Tra i videogiochi che danno la possibilità agli utenti di cimentarsi in partite via
Internet ricordiamo le categorie di maggior successo:
Massive Multiplayer On-line Role Playing Games: [MMORPG]
Molto comune in questo tipo di giochi è l’ambientazione fantasy. Il giocatore,
proiettato in un mondo spesso popolato da diverse razze fantastiche (elfi, orchi, nani,
3
umani, ecc) o anche personaggi vicini alla realtà (Habbohotel per esempio), costruisce
il proprio alter ego a volte scegliendo una delle tante fazioni contrapposte (World of
Warcraft). L’eterna guerra tra bene e male è rappresentata principalmente dalla lotta
dei giocatori contro mostri, ma in ogni MMORPG c’è sempre un obiettivo che va al di
là del semplice player versus monster (PvM): i mostri in effetti rappresentano il mezzo
per far crescere di livello il proprio personaggio, in modo che possa poi essere più
forte per l’obiettivo finale, ad esempio conquistare un castello e mantenerne il possesso
contro gli attacchi degli altri giocatori oppure combattere contro la fazione nemica e
ottenere punteggi. Sono decine di migliaia le persone che ogni giorno dedicano il loro
tempo a questo tipo di attività su Internet, il cui successo è dovuto soprattutto alla
presenza delle comunità on-line. In ogni MMORPG la società di giocatori è spesso
organizzata in “clan” o in “gilde” favorendo quindi il gioco di gruppo ed il senso di
appartenenza, creando un legame fra le persone anche per mesi o anni a prescindere
dal MMORPG. Spesso accade infatti che i clan si trasferiscano in massa su altri giochi.
Simulatori:[SIM]
In questa categoria si annoverano tutti i videogiochi di simulazione sportiva che
vanno dall’automobilismo (Toca2, Trackmania, Grand Prix) in cui il divertimento dipende dal numero di giocatori che partecipano alla gara, a simulatori di calcio tra cui
Pro Evolution Soccer e FIFA a molti altri generi di sport.
Realtime Strategy Games:[RTS]
Si basano sul fascino della guerra e della sua gestione nei minimi particolari, l’azione inoltre non è suddivisa in “turni” come nei wargame tradizionali [TBSG], bensı̀
fluisce in modo continuo, lasciando ai giocatori la possibilità di agire in qualsiasi istante. Il termine strategia in questo contesto si riferisce al fatto che il giocatore controlla
interi eserciti e non singole unità o personaggi.
Sparatutto in prima persona:[FPS]
Ogni giocatore controlla un solo personaggio e, in visione soggettiva, si aggira per
la mappa alla ricerca di avversari da uccidere utilizzando una delle tante armi normalmente a disposizione. Tra i più famosi sicuramente Doom, Unreal Tournament, Quake,
4
Half Life. Non di rado si assiste a partite con 32 giocatori. Alcuni sparatutto sempre
più popolari prevedono la possibilità di aggiungere un aspetto strategico: i giocatori
sono parte di due squadre una delle due con un obiettivo da compiere e l’altra che tenta
di impedirne il successo. Hanno generalmente un’ambientazione realistica (forze speciali e terroristi ai giorni nostri o ambientate durante una guerra).
Attualmente la categoria più diffusa è quella degli sparatutto. Il successo di queste applicazioni, però, richiede un livello di interattività spinta che, come abbiamo già
detto, le reti spesso non sono in grado di fornire. La qualità del servizio offerta dalla
rete viene percepita dall’utente in termini di una serie di parametri resi disponibili dall’applicazione stessa. Tra questi, quello a cui i giocatori statisticamente tendono a dare
maggior peso è il cosiddetto ping time, inteso come il tempo che impiega un pacchetto
a raggiungere il server e a tornare al client. Ad esempio, per la maggior parte degli
utenti degli sparatutto in prima persona, il ping non deve superare i 100ms. Per capire quanto peso venga dato a tale parametro basti considerare che nella maggior parte
dei casi l’utente tende ad associare un’eventuale performance scarsa principalmente a
questo fattore[4].
Organizzazione della tesi
Per modellare analiticamente il traffico generato dal client di un applicazione interattiva sarà necessario innanzitutto raccogliere il materiale che la comunità scientifica ha
prodotto in questi anni sull’argomento. Solo dopo un’attenta riflessione verrà scelta
l’applicazione ritenuta più significativa. A questo punto si procederà ad esaminare in
dettaglio gli articoli accademici dei ricercatori che eventualmente hanno già studiato
questa particolare applicazione. Raggiunto, dunque, un buon punto di partenza si potrà
testare l’applicazione in vari scenari collezionando diverse tracce di traffico.
Il materiale raccolto, durante gli esperimenti, sarà oggetto di attenta analisi a livello
pacchetto. In particolare si cercherà di ottenere una modellazione analitica del traffico
generato da un client in termini di packet size e di inter-departure time, parametri che
verranno descritti ampiamente nei prossimi capitoli. Nei modelli ottenuti si cerche5
ranno caratteri comuni in quanto una possibile invarianza potrebbe rappresentare un
elemento di partenza fondamentale per la progettazione delle reti del futuro.
Come vedremo, per la particolare applicazione scelta, l’analisi evidenzierà due
fasi diverse di gioco. La caratterizzazione statistica e la ricerca di invarianza saranno
applicate ad entrambe.
Inoltre, per la modellazione analitica si è adottato un metodo affermato nella comunità scientifica che si basa sul fitting. Sarà dunque necessario fare riferimento brevemente agli elementi chiave che hanno permesso di individuare le distribuzioni matematiche che nel migliore dei modi rappresentano la dispersione dei campioni del
packet size e dell’inter-departure time.
6
Capitolo 1
Background
1.1
Raccolta del materiale
Per poter affrontare al meglio l’argomento si è ritenuto opportuno analizzare gli studi
che la comunità scientifica ha prodotto in questi anni sulla caratterizzazione e modellazione del traffico generato dai videogiochi on-line. In particolare, sfruttando portali di organizzazioni scientifiche di portata internazionale quali ACM e IEEE, è stato
possibile consultare diversi articoli accademici che hanno trattato l’argomento. Si è
deciso, inoltre, di schematizzare le informazioni contenute negli articoli ritenuti più
interessanti.
1.2
Sintesi del materiale raccolto
Questa sezione contiene il resoconto stilato al termine dell’attività di analisi degli articoli accademici. Ad ognuno di essi si è dedicato un paragrafo in cui si è specificato
il nome dell’articolo, gli autori, il metodo utilizzato per effettuare le misure (Metodologia) e una sintesi critica dei principali risultati prodotti e alcune riflessioni utili in
funzione della scelta della particolare applicazione che sarà oggetto di studio (Note).
In aggiunta, una tabella fornisce ulteriori informazioni, quali:
1. Il gioco trattato (Gioco)
7
2. Il genere a cui appartiene (Tipo)
3. Il protocollo utilizzato dall’applicazione (Prot.)
4. Il paradigma di gioco (Paradigma)
C/S – Client / Server
P2P – Peer to Peer
5. I parametri studiati (Parametri)
PS – packet size: dimensione dei pacchetti
IAT – inter-arrival time: tempo che intercorre nell’arrivo di due pacchetti consecutivi
IPT – inter-packet time: tempo che intercorre nella partenza di due pacchetti consecutivi
Latenza – ritardo introdotto dalla rete
RTT – round trip time: tempo impiegato da un pacchetto per arrivare a destinazione e
tornare
Bandwidth – banda
6. Se si è giunti a una modellazione matematica del traffico (C.A.)
* - viene fornita una descrizione analitica delle cdf e pdf che modellano i parametri
o - vengono mostrati i grafici delle distribuzioni insieme a valori quali media e deviazione
standard ma non l’espressione analitica.
# - vengono menzionate media e deviazione standard ma non vengono forniti grafici
esplicativi.
7. Se sono disponibili le tracce analizzate (Tracce)
Traffic Modelling for Fast Action Network Games[5]
Autore: Joannes Faerber.
Gioco
Counter-Strike
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
*
Non presenti
PS IAT
Metodologia: Tcpdump su un server dedicato per tutto il mese di Maggio 2001.
Note: Lato Server: PS - il 99% dei pacchetti è più piccolo di 300 byte; una frazione raggiunge dimensioni di circa 1000 byte ed è dovuta alla fine di una sessione di gioco; la dimensione media è di 119 byte
con coefficiente di variazione pari a 0.67 ma dipende dal numero di giocatori (in media alla sessione
8
partecipano 10 giocatori). Best fit: Extreme(81,44).
IAT – il 70% dei pacchetti sono spediti uno dopo l’altro, il 25% a distanza di 20 ms e meno dell’1%
dopo 60 ms. Best fit: Extreme(60,1.1).
Lato Client: PS - andamento abbastanza costante, in media 42 byte con un coefficiente di variazione pari a 0.15. Dei pacchetti il 99.9% ha una dimensione compresa tra 30 e 70 byte. Solo una minima
parte ha una dimensione di 100 o più byte. Best fit: Extreme(41,6).
IAT – si concentra principalmente tra i 30 e 60 ms. Alcuni client presentano picchi altri manifestano
un andamento dell’IAT più dolce. Tale differenza è dovuta alle diverse prestazioni dell’hardware dei
client. L’IAT medio è 51ms con un coefficiente di variazione medio di 0.4. Best fit: Extreme(41,12).
Al crescere dei partecipanti sia per il client che per il server il packet rate medio rimane approssimativamente costante. Il data rate medio invece rimane costante per il client ma non per il server, per il
quale cresce in maniera lineare.
Provisioning on-line games: a traffic analysis of a busy Counter-strike server[3]
Autore:Wu-chan Feng, Francis Chang, Wu-chi Feng, J. Walpole.
Gioco
Counter-Strike
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
o
Su richiesta
PS
Metodologia: Analizzato il traffico in ingresso e in uscita a un server saturo (massimo 22 giocatori)
per una settimana.
Note: Tipicamente i costruttori di router assumono per i pacchetti dimensioni dell’ordine di 125-250
byte (traffico TCP di applicazioni Web e Peer-to-Peer). I nodi di routing di una rete che non sono realizzati per inoltrare tipici pacchetti dei videogiochi (in media i pacchetti di Counter-Strike sono di 40byte)
introducono ritardi e perdite significative degradando cosı̀ le prestazioni del server. Inoltre, il sincronismo tipico della logica del gioco determina, fissato il numero di giocatori, un andamento periodico del
traffico generato che si dimostra quindi prevedibile. Queste caratteristiche possono essere sfruttate per
supportare al meglio tale traffico.
9
Network Analysis of Counter-Strike and Starcraft[6]
Autore: Mark Claypool, David LaPoint, Josh Winslow.
Gioco
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
Counter – Strike
Starcraft
FPS
RTS
UDP
C/S
P2P
o
http://perform.
wpi.edu./
downloads/
#net-game
PS
Metodologia: Sniffer Commview in ingresso e in uscita a due server.
Note: PS – Counter-Strike(CS) risulta fortemente influenzato dall’azione di gioco. Starcraft all’aumentare della banda richiesta trasmette più pacchetti, tale comportamento è assunto anche dal client di
CS. Tuttavia CS lato server incrementa la dimensione dei pacchetti quando sono richiesti più dati dal
client. Il server di CS genera un elevato numero di pacchetti (circa il 30%) in un singolo burst che si
ripresenta con una certa periodicità.
Game Traffic Analysis: An MMORPG Perspective[7]
Autore: Kuan-Ta Chen, Polly Huang, Chin Laung Lei.
Gioco
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
ShenZhou Online
MMO
RPG
TCP
C/S
o
Non disponibili.
PS, Bandwith, IAT
Metodologia: Due tracce per 2 e 3 game set diversi da 8 e 12 ore rispettivamente. Le tracce sono
state collezionate grazie a Tcpdump.
Note: PS (payload) - Non vengono considerati gli ack. I pacchetti del client e del server sono profondamente diversi per dimensione; infatti, quelli del client contengono i comandi di un solo giocatore
mentre quelli server contengono i comandi di tutti i personaggi nelle vicinanze del giocatore. Il 98%
dei pacchetti client ha un payload minore di 32 byte e la maggior parte ha dimensione 23 e 27 byte, che
corrispondono ai comandi più utilizzati (cammina e attacca). Per il server la dimensione media del payload è 114 byte e la distribuzione è molto più estesa. Se si considera il traffico aggregato la dimensione
media di un pacchetto è 84 byte.
IAT - Molti valori dell’ IAT sono compresi tra 0 e 600 ms. La distribuzione che meglio rappresenta
10
quella trovata sperimentalmente è quella esponenziale con un rate di 8 pkt/s. E’ comunque presente uno
scostamento dovuto al diverso comportamento degli utenti.
Al contrario di molti altri generi, l’MMORPG può presentare situazioni in cui l’utente non fa nulla, è
in attesa di un evento. Si possono considerare 3 scenari: sessione attiva, di attesa e regolare. La distribuzione rappresentante la sessione attiva è molto simile all’esponenziale, mentre quella relativa alla
sessione di attesa è molto lontana da essa. Si tratta di un ibrido tra un uniforme è una deterministica.
Ovviamente la pdf relativa a una sessione regolare è una via di mezzo tra i 2 estremi.
La diversità del comportamento dei giocatori rende difficile, se non impossibile, definire il giocatore tipico e dunque modellare il comportamento del giocatore risulta essere molto impegnativo.
Per quanto riguarda il lato server l’IAT è molto più regolare, circa il 50% dei valori si trova intorno ai
200ms. Ciò mette in evidenza il fatto che il server manda informazioni in broadcast ai client ad intervalli
di tempo regolari. Le CCDF dell’IAT di map session e game session con una scala lineare logaritmica
si avvicinano alla distribuzione esponenziale.[...]
The Effect of Latency on User Performance in Real-Time Strategy Games[8]
Autore: Mark Claypool.
Gioco
Warcraft III
AoM
C&C:Generals
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
Tutti
RTS
TCP
UDP
UDP
C/S
C/S
C/S
o
http://perform.wpi
.edu/downloads/
Latenza
PS
IPT
Metodologia: I PC sono connessi a una rete privata. La versione utilizzata di Warcraft è la 1.04 per
tutti i test LAN e la 1.05 per le tracce di rete a causa dei requisiti di Battle.net. Per catturare i pacchetti
si è utilizzato lo sniffer Ethereal.
Note: Tipicamente un gioco RTS utilizza un server centralizzato in un’architettura C/S con al più 10
partecipanti, sia su Internet che su LAN.
WIII PS (payload)- Le dimensioni più comuni sono 6 e 9 byte. Meno dell’ 1% va oltre i 40 byte.
Si fa notare come per Starcraft la dimensione tipica dei pacchetti va da 122 a 132 byte, mentre per WIII
varia tra 46 e 49 (compresi gli header). Il numero di giocatori non ha un effetto significativo sulla
dimensione dei pacchetti, cosı̀ come le azioni svolte durante il gioco.
IPT - WIII spedisce pacchetti a intervalli di tempo regolari. L’IPT si mantiene praticamente immutato
11
all’interno della LAN in cui è stato testato; in pratica dal client viene spedito o ricevuto un pacchetto
ogni decimo di secondo. Se invece si testa su un server esterno il valore si porta a un pacchetto ogni 200
ms in entrata e uno ogni 160ms in uscita.
AoM e C&C PS (payload)- Solo il 5% del payload è superiore ai 100 byte. La dimensione aumenta
all’aumentare della latenza.
IPT - Sia AoM che C&C hanno un packet rate molto diverso da WIII. L’IDT per AoM è indipendente
dalla latenza della rete mentre per C&C cresce al crescere di essa. Per C&C il decrescere della dimensione del payload con il crescere dell’IPT mostra il decrescere del bitrate all’aumentare della latenza.
Dalle tracce collezionate si evince che i client comunicano solo con il server ma non direttamente
con gli altri client. Ogni macchina mantiene una copia completa dello stato di gioco.
The Effect of Loss and Latency on User Performance in Unreal Tournament
2003[9]
Autore: T. Beigbeder, R. Coughlan, C. Lusher, J. Plunkett, E. Agu, and M. Claypool.
Gioco
UT 2003
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
o
http://perform.wpi
.edu/downloads
/#ut2003.
Latenza
PS
IPT
Metodologia: 4 client connessi a uno switch 10 Mbps alternativamente si connettono con una di
tre schede di rete all’interfaccia di una LinuxBox. Una seconda scheda di rete connette direttamente a
un altro computer UT2003 server. La terza scheda connette a una macchina configurata per agire da
gateway per una rete WPI e Internet. I programmi utilizzati sono Ethereal, NIST Net e All Seeing Eye.
Note: PS - In generale la dimensione dei pacchetti è significativamente più grande di quella dei giochi
RTS ma paragonabile a quella di altri giochi FPS. Ancora una volta, però, si afferma come tale dimensione sia considerevolmente più piccola del tipico traffico di Internet, che ha una dimensione media per
pacchetto di 400 byte.
IPT - sia “da” che “verso” il server. Il client non è molto coerente e genera pacchetti ogni 10-20 ms,
in relazione alla frequenza delle azioni dell’utente, mentre il server è coerente e spedisce pacchetti ogni
50 ms.
12
Source Models of Network Game Traffic[10]
Autore: M. Borella.
Gioco
Quake 1
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
*
Non disponibili.
IAT
PS
Autocorr.
Metodologia: Tutte le macchina hanno configurazioni diverse fra loro. Due tracce:
1a
traccia (3 client, 1 server); 2a traccia (4 client, 1 server).
Note: Dai risultati empirici al modello matematico si giunge utilizzando la misura di discrepanza λ2 .
1a Traccia PS - La media dei 3 client è rispettivamente 23.93, 23.91 e 23.89 byte, per il server
109.76 byte. Allo stesso modo i valori della deviazione standard sono 1.02, 1.18 e 1.18 per i client,
42.61 per il server. IAT - Le medie sono 15.72, 23.39 e 26.08 ms per i client, 49.66 ms per il server. I
valori della deviazione standard sono 4.31, 6.61 e 6.85 per i client, 12.04 per il server.
2a Traccia PS - La media dei 4 client è rispettivamente 23.89, 23.95, 23.91 e 23.95 byte, per il
server 77.43 byte. I valori della deviazione standard sono 1.33, 0.91, 1.17 e 0.86 per i client, 29.44 per il
server. IAT - Le medie sono 41.37, 18.25, 34.35 e 16.15 ms per i client, 26.58 ms per il server. I valori
della deviazione standard sono 9.86, 5.02, 8.76 e 4.04 per i client, 8.42 per il server.
Il PS del client viene modellato bene con una deterministica, il PS del server con la distribuzione Extreme. L’IAT sia per il client che per il server sono ben modellate dalla distribuzione Extreme.
Poiché il server spedisce pacchetti separati a tutti i client senza o con piccole pause, l’IAT assoluto
del server si avvicina molto a 0 ms. Nella prima traccia, mentre per i client 2 e 3 la scelta della distribuzione Extreme risulta essere buona, per il client 1 si sceglie una distribuzione sı̀ fatta: la metà che
riguarda i valori più bassi può essere approssimata da una distribuzione deterministica centrata in 13
ms, mentre il 50% superiore da una Esponenziale con media 19.61 ms. I parametri delle distribuzioni
relative all’IAT sono fortemente legati alla velocità delle CPU degli host. Gli host più lenti hanno un
IAT significativamente più alto e più variabile, mentre gli host più veloci trasmettono la maggior parte
dei pacchetti in intervalli di 13 o 14 ms.
13
A traffic characterization of popular on-line games[11]
Autore: Wu-chang Feng Francis Chang Wu-chi Feng Walpole
Gioco
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
Counter-Strike
The Day of Defeat
MoH: Allied Assault
UT2003
Tutti
FPS
Tutti
UDP
Tutti C/S
o
mshmro.com
Bandwidth
PS
Number of
players
Metodologia: Sniffing in ingresso e in uscita al server mshmro.com
Note: Il traffico generato è altamente prevedibile e le tracce mostrano la presenza di picchi periodici
nella generazione dei pacchetti lato server, tipicamente l’aggiornamento dello stato del gioco. Non
si assicura, però, che la periodicità riscontrata possa essere assunta stabile anche per altri server. Per
quanto concerne il PS viene considerato il payload (senza UDP IP ethernet header).
Counter-Strike, confrontato con studi non approfonditi (tracce di 3 ore su busy server) su tracce di
altri tre on-line games (Day of Defeat -dd , Medal of honor: Allied Assault - mohaa, UT2003) manifesta
caratteristiche tipiche degli FPS (in termini di total packet load, pdf of incoming and outgoing PS,
periodic burst ). Tuttavia sono state rilevate alcune differenze sulla periodicità dei picchi di traffico
generato con UT2003 (100ms mentre per gli altri si assesta intorno ai 50ms). Viene fatto notare, inoltre,
che Medal of honor: allied assault presenta una variabilità maggiore nell’occupazione di banda lato
client.
L’alto grado di variabilità del numero di giocatori, che partecipano a una sessione di gioco, influenza il traffico aggregato. Un altro aspetto emergente è che mentre i piccoli pacchetti dei giochi on-line
hanno il potenziale di paralizzare l’infrastrutture di routing, la periodicità e la predicibilità della dimensione dei pacchetti permette una significativa ottimizzazione delle prestazioni dei dispositivi di rete.
14
Measurement and characterization of Internet gaming traffic[12]
Autore: J. Lakkakorpi, A. Heiner and J. Ruutu.
Gioco
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
Quake 2
Grand Prix 3
AoK: Age of
Kings
Panzer General
3D
FPS
SIM
RTS
TBSG
Tutti
UDP
Tutti C/S
*
Non disponibili.
PS
(UDP
header incluso)
IAT
bitrate (IPv4
header
incluso)
Metodologia: 2 macchine collegate da un ethernet hub 10/100, una terza analizza il traffico che
attraversa l’hub con il software Shomiti Advanced Test System.
Note: Il traffico generato da giochi appartenenti a diversi generi è, com’era prevedibile, decisamente
diverso. In generale il PS generato dai client assume precisi valori quindi può essere descritto meglio
con una pdf discreta. Per l’IAT si può assumere una distribuzione multimodale che a volte assume la
forma della Extreme. Viene riportata una chiara descrizione del procedimento da seguire nel determinare la distribuzione più corretta.
Quake 2: il numero di pacchetti inviati dal client è 2,5 volte più grande del numero dei pacchetti
ricevuti. PS (client) si distribuisce discretamente tra precisi valori, PS(server) invece come una Extreme.
Grand Prix 3: il client invia e riceve lo stesso numero di pacchetti, anche le dimensioni sono le
stesse. I pacchetti generati dal client assumono solo due valori distinti, quelli più piccoli vengono
generati solo all’inizio o alla fine di una sessione di gioco. Per l’IAT può essere usato un misto tra Extreme, Esponenziale e Deterministica (potrebbe essere interessante appurare se tale comportamento,
quello dei client che generano pacchetti a dimensione fissa, sia tipico per tutti i simulatori.)
AoK: il PS assume prevalentemente due valori, l’indipendenza non può essere assunta. Quest’ultima può essere assunta per l’IAT modellabile con un mix di Esponenziale e Normale.
Panzer General 3D: viene utilizzato il protocollo UDP anche se il gioco non evolve in tempo reale
essendo a turni. Client e server generano pacchetti che assumono 7 precisi valori con probabilità diverse; l’IAT può essere modellata da una semplice Esponenziale.
15
The effect of latency on user performance in Warcraft 3[13]
Autore: Nathan Sheldon, Eric Girard, Seth Borg, Mark Claypool, Emmanuel Agu.
Gioco
Warcraft III
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
RTS
TCP
C/S
o
Non disponibili.
Latenza
PS (payload)
IAT
Metodologia: I test riguardano sia un incontro 1vs1 in LAN che 2vs2 su server battle.net.
Note: Osservando il traffico generato dai client:
PS – il payload entrante si concentra intorno a 0, 6 e da 33 a 35 byte per la 1vs1 in LAN, che corrispondono ai TCP acks (0 byte, non piggybacked) e a eventi come nessun comando immesso (6 byte).
Inoltre, sembra che all’aumentare dei giocatori il numero dei pacchetti che assumono dimensioni diverse da quelle canoniche si riduce. Il payload uscente ha un andamento simile concentrato però su valori
diversi ( 0, 9, 30/32byte per la 1vs1 in LAN).
IAT – i risultati mostrano come nella sessione Internet i campioni dell’inter-arrival-time si disperdano
maggiormente intorno al valore medio, comportamento che non si riscontra nella sessione LAN dove
evidentemente la rete influisce meno sulla sessione di gioco.
Traffic Characteristics of a Massively Multi-player Online Role Playing Game[14]
Autore: T. Kwon, J. Kim, J. Choi, D. Chang, Y. Choi, E. Yuk
Gioco
Lineage II
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
MMO
RPG
TCP
C/S
o
Non disponibili.
PS
IAT
Bandwith
RTT
Metodologia: i dati collezionati ammontano a circa 1 terabyte e corrispondono a misurazioni effettuate in 4 giorni consecutivi. Lo sniffer utilizzato è Tcpdump su una Linux Box. Il traffico è stato
analizzato da due punti di vista diversi: singolo e aggregato.
Note: La dimensione media del payload dei pacchetti client è 19 byte, mentre per il server è circa 318
byte. Ciò è dovuto al fatto che il server trasmette tutte le informazioni che consentono al client di ricostruire l’ambiente virtuale in cui si muovono i giocatori. Di conseguenza la banda occupata dal traffico
16
server è circa 10 volte maggiore di quella utilizzata dal client. Si è trovata una relazione lineare tra la
banda usata e il numero di utenti tranne nel caso in cui il numero di utenti raggiunge le 5000 unità. Lineage II è supportato da 30 server. La banda utilizzata da ogni server varia tra 20 e 140 Mbps a seconda
del numero di utenti. Se si considera la diffusione del genere, le misure effettuate possono essere un
buon punto di partenza per capire come supportare al meglio il traffico di un MMORPG.
Le riflessioni riguardano il traffico aggregato. PS - Vengono esclusi i pacchetti che non trasportano dati. Il packet-size fa riferimento al payload. La dimensione media dei pacchetti in upstream è
19.06 byte, che è relativamente maggiore di quella di Lineage I. Ciò è dovuto al fatto che quest’ultimo
è 2D, mentre Lineage II è 3D. Tuttavia il valore è molto piccolo. La metà dei pacchetti del client ha una
dimensione minore di 20 byte e il 99% minore di 50 byte. La distribuzione relativa alla dimensione dei
pacchetti in downstream mostra un andamento differente, è molto più larga della precedente. La media
in questo caso è 318.39 byte, che è un valore circa 9 volte più grande di quello rilevato per Lineage I.
Anche la distribuzione è molto diversa: circa il 5% dei pacchetti totali in downstream hanno dimensioni
pari all’MTU; tale fenomeno è dovuto alla segmentazione (pacchetti molto grandi vengono suddivisi e
ricostruiti a destinazione). IAT - L’IAT aggregato dipende dal numero di giocatori. La media totale è
58.08 us. Il 99% dei pacchetti arrivano in 270 us, valore molto più piccolo dei 2 ms di Lineage I. La
differenza è causata dall’aumento del numero di giocatori e dalla diversa struttura di gioco.
A Synthetic Traffic Model for Quake3[15]
Autore: T.Lang, P.Branch, G. Armitage
Gioco
Quake III
Tipo
Prot.
Paradigma Parametri
FPS
UDP
C/S
C. A.
PS(datagram) *
IAT
Tracce
Non disponibili.
Metodologia:Partite disputate nell’arco di 2 mesi, con un numero di giocatori variabile (da 2 a 8).
Il ciclo di mappa è cambiato 3 volte. In totale sono state osservate 8 differenti mappe e le riflessioni
presenti nel paper sono valide per tutti i match, indipendentemente dal ciclo di mappa.
La rete è una LAN universitaria. Le macchine dei client sono distanti al massimo un hop dal server, il
che comporta un RTT minore di 10 ms. Sul server è in esecuzione Pkthisto, che crea istogrammi relativi
al PS e all’IAT per ogni flusso UDP/IP tra client e server ogni 2000 pacchetti.
Note: Server to Individual Client. PS - Il PS è fortemente influenzato dal numero di giocatori. Ogni
17
giocatore in più sulla mappa crea una certa quantità di attività che comporta un complessivo aumento
della dimensione dei pacchetti generati dal server. Infatti, attraverso SPSS si è notato che ogni giocatore
in più aumenta di 12 o 13 byte la dimensione media dei pacchetti. L’inclinazione della distribuzione indica che il PS tende a diventare gaussiano all’aumentare del numero di client. Si tratta di un’indicazione
del fatto che ogni distribuzione relativa al PS è la somma di una distribuzione di base e di una seconda
che modella l’incremento del PS per client aggiunto.
IAT - L’IAT è molto regolare. Il server spedisce un pacchetto di aggiornamento approssimativamente
ogni 50 ms ad ogni client. Questo comportamento è indipendente dal numero di client. Se L client sono
connessi al server durante un match particolare, il server spedisce un burst di L pacchetti ogni 50 ms.
Pertanto (100*(L-1)/L)% dell’IAT aggregato è vicino a 0 ms e il resto è concentrato intorno a 50 ms.
Best fit: Gamma.
Client to Server. PS - Il PS è indipendente dal tipo di mappa o dal numero dei giocatori e si distribuisce in un range molto più limitato (50-70byte) di quello relativo ai pacchetti che vanno dal server al
client. La distribuzione analitica è difficile da determinare. Si è deciso per una distribuzione normale
con media pari a 64.15 e deviazione standard pari a 3.20.
IAT - L’IAT dei client dipende da variabili come la scheda grafica e la mappa di gioco utilizzata. Durante le prove sono state utilizzate 3 schede grafiche diverse. Le macchine con schede grafiche più moderne
spediscono più pacchetti in un secondo.
Network Game Traffic Modelling[16]
Autore: Johannes Faerber
Gioco
Counter Strike
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
*
Non disponibili.
PS
IAT
Metodologia: LAN party di 36 ore con 50 partecipanti. Sono stati osservati match da 8 a 30 giocatori attivi e partite da 30 a 90 minuti ognuna (in totale 6h30m).
Note: E’ stato verificato che il modello di traffico proposto da Borella è valido.
Lato server: la caratteristica principale del traffico del server, oltre alla leggera variazione del packet rate, è la sua natura “bursty”. In ogni ciclo di trasmissione il server genera un burst di pacchetti (un
18
pacchetto per ogni client attivo). Di conseguenza, il data rate totale dipende dal numero di client attivi.
Ha senso, quindi, considerare il traffico server per client invece che il traffico totale. Il traffico del server
può fermarsi per un tempo breve, in corrispondenza ad esempio di cambiamenti di scenario. Tali pause
non sono prese in considerazione, il che significa che sono stati considerati IAT minori di 1 secondo.
Nella pdf riportata sono rappresentati solo 8 client su 27. Tranne 3 client che hanno un IAT più piccolo,
gli altri 24 mostrano in generale la stessa pdf. Il picco massimo si ha in corrispondenza di 55 ms, la
media è 62 ms, il coefficiente di variazione è circa 0.5. C’è una probabilità abbastanza consistente di
avere valori di IAT molto maggiori della media.
Il PS nel traffico generato dal server è fortemente variabile. In media è 127 byte con un coefficiente
di variazione di 0.73. I pacchetti, nel 99% dei casi, sono più piccoli di 250 byte. Alcuni raggiungono
dimensioni di circa 1000 byte e sono attribuibili alle interruzioni di gioco dovute alla fine di un turno o
al cambiamento di uno scenario.
Lato client: il traffico del client è caratterizzato da un data rate e un packet rate abbastanza costanti. Anche in questo caso non si considerano occorrenze superiori a 1 secondo. Si riportano le figure
relative a PDF e CCDF per l’IAT e il PS associati a 8 client su 27 attivi. Si riscontrano picchi per l’IAT
e andamenti diversi per ogni client. La differenza è dovuta alle diverse prestazioni dell’hardware dei
client e dalle diverse impostazioni. In media l’ IAT è 41.7 ms e il coefficiente di variazione è 0.24. I
picchi significativi si trovano in corrispondenza di 34, 42, 50 e 60 ms. Si suggerisce dunque l’utilizzo
di una distribuzione deterministica centrate in tali valori per l’IAT.
Il PS varia intorno a una media di 82 byte con un coefficiente di variazione di 0.12. La pdf dei vari
client è molto simile. Si nota un picco intorno a 80 byte. Il 99% dei pacchetti ha dimensioni tra i 60 e i
110 byte. Sia per IAT che per il PS l’approssimazione migliore è rappresentata da una Extreme. Altre
approssimazioni buone si ottengono attraverso distribuzioni LogNormal e Weibull.
A Synthetic Traffic Model for Half-Life [17]
Autore: Tanja Lang, Grenville Armitage, Phillip Branch, Hwan-Yi Choo
Gioco
Half-Life
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
UDP
C/S
*
Non disponibili.
PS IAT
19
Metodologia: Numero di giocatori variabile (da 3 a 7), 4 mappe diverse: xflight, chilDM, rats3
e odyssey. Ogni match dura 10 minuti. Il software SPSS statistics package ha analizzato il traffico e
calcolato la distribuzione “best fit”.
Note: Il numero di giocatori o eventi come l’entrata o l’uscita di un giocatore dal match non sono riscontrabili nelle tracce.
Server to individual client: PS - si considera il livello datagram (il payload è 28 byte più piccolo).
L’andamento del packet-size dipende dalla particolare mappa. In generale la lunghezza dei pacchetti si
distribuisce dolcemente tra i 60 e 300 byte, ma la forma varia a seconda della mappa [...]. La maggior
parte dei pacchetti si concentra tra i 140 e 180byte. La distribuzione analitica che descrive meglio il PS
è la LogNormal anche se differisce dalla empirica per pacchetti di dimensioni superiori a 400byte. Tuttavia, poiché la probabilità con cui vengono generati questi pacchetti è molto bassa (0.1%), il modello
li può trascurare anche se la varianza ne sarà ovviamente influenzata. Best Fit: LogNormal. (si noti
come Faerber con riferimento a Counter-Strike avesse indicato proprio la LogNormal come alternativa
rispetto alla Extreme).
IAT - Risulta decisamente regolare, per tutte le mappe (tranne per rats3) il server invia un pacchetto di
update ogni 60 ms (per rats una metà ogni 50ms l’altra ogni 70ms). Best Fit: a seconda della mappa
risulta appropriata un’unica deterministica a 60ms o due deterministiche a 50ms e a 70ms.
Individual client to Server: PS - La maggior parte dei pacchetti (93%) ricade all’interno di un
determinato range (tra 60 e 90 byte) tranne che per alcuni picchi casuali. Il modello a cui si giunge
tralascia i picchi che si presentano in modo casuale e si concentra su quella che sembra essere un comportamento assodato del client. Infatti, indipendentemente dalla macchina utilizzata, la sovrapposizione
del traffico generato dai vari client evidenzia un tratto comune definito “corridoio”. Best fit: Normal.
IAT - E’ fortemente dipendente dal graphic rendering software montato sulla macchina. In particolare,
i client OpenGL generano pacchetti periodicamente a intervalli di 33 ms e 50 ms, mentre per i software client tipicamente ogni 41 ms. Una sola macchina usa Direct3D ma genera pacchetti ad intervalli
davvero molto casuali, si è deciso pertanto, data anche la relativa limitata diffusione di questo metodo,
di tralasciare la modellazione del traffico generato da client che montino Direct3D. Best Fit: OpenGL:
deterministiche ( 50% 33ms, 50% 50ms). Software Rendering: deterministica (41ms).
20
Modeling Multi-Player Games Traffic[18]
Autore: Ricky A. Bangun and E. Dutkiewicz
Gioco
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
Starsiege Tribes
FPS
UDP
C/S
*
Non disponibili.
PS
IAT
Autocorr.
Metodologia: 5 tracce per ogni client. Il paper si concentra sul traffico generato dai client in una
rete locale. 16 macchine sono connesse ad un dumb hub, una macchina monitor colleziona il traffico
tramite Tcpdump. Il traffico è oggetto di filtraggi che mirano a isolare i pacchetti prodotti dal singolo
client.
Note: L’andamento generale del PS è simile per tutti i giocatori ma le distribuzioni individuali sono
diverse. Questo fatto rende difficile la selezione casuale di un giocatore come base per costruire un modello analitico. Si cerca di trovare un giocatore tipico realizzando la media delle distribuzioni dei singoli
giocatori; ovviamente, il giocatore tipico sarà diverso se diverso è il numero di giocatori coinvolti e se
diversa è la sessione di gioco. Nel caso del traffico di Starsiege Tribes , la distribuzione relativa al PS è
unimodale, per l’IAT è bimodale. L’utilizzo della distribuzione Esponenziale produce buoni risultati.
An analysis of multi-player network games trafficcite[19]
Autore: Ricky A. Bangun, E. Dutkiewicz, and G. J. Anido
Gioco
Quakeworld
Starcraft
Tipo
Prot.
Paradigma Parametri
C. A.
Tracce
FPS
RTS
UDP
IPX
C/S
P2P
o
Non disponibili.
PS
IAT
Metodologia: I test si sono tenuti all’interno di un Internet point. A una tipica sessione partecipano
fino ad un massimo di 16 giocatori collegati a un dumb hub su 10BaseT Ethernet LAN. Il traffico viene
collezionato tramite Tcpdump. Non sono prese in considerazione le caratteristiche dei singoli computer
assumendo che il PS e l’IAT ne siano poco influenzati.
Note: PS - Il payload generato da un peer di Starcraft non sembra legato al numero di giocatori: il 90%
risiede tra 43 e 46byte approssimabile con un picco a 45byte. In Quakeworld, invece, la distribuzione
21
del PS cambia leggermente al variare del numero di giocatori. In particolare all’aumentare di tale
numero i pacchetti “piccoli” diminuiscono; si ipotizza che tale comportamento sia legato alla maggiore
interattività e al consenguente maggior numero di informazioni da dover trasmettere.
IAT - Poichè il tempo di risoluzione è di 10ms per pacchetti che arrivano a distanza inferiore ai 10ms
si assume che siano arrivati simultaneamente. Per i peer di Starcraft l’IAT diminuisce all’aumentare del
numero di giocatori; ciò si spiega se si tiene conto che adesso ogni peer deve inviare lo stesso pacchetto
di update a un numero maggiore di macchine. In questo senso si ottengono benefici se la rete supporta il
multicasting in modo efficiente. Per i client di Quakeworld l’IAT non ha legami col numero di giocatori.
1.3
Riflessioni conclusive: scelta dell’applicazione.
La comunità scientifica si è concentrata, dunque, su un insieme di giochi variegato.
Sono stati trattati simulatori, giochi di ruolo on-line, di strategia e sparatutto.
Non è semplice scegliere quale particolare videogioco sarà oggetto della caratterizzazione statistica. Infatti, da un lato si è interessati a un’applicazione molto diffusa
che sia stata già trattata in parte al fine di confermarne i risultati e di aggiungerne dei
nuovi, dall’altro, però, il videogioco dovrebbe assumere un comportamento quanto più
vicino possibile all’intera classe a cui appartiene per poter poi estendere le conclusioni,
con la dovuta cautela, all’intero genere.
Statistiche alla mano, i simulatori non hanno avuto molto successo tra i multiplayer
gamers[20]. Un successo enorme si riscontra invece per i giochi di ruolo on-line che
stanno facendo proseliti in tutto il mondo, ma proprio perché la loro diffusione è aumentata vertiginosamente solo negli ultimi anni sono ancora poco studiati dalla comunità, inoltre gli articoli che li hanno trattati hanno evidenziato come sia difficile
caratterizzarne il traffico a causa della forte dipendenza dall’azione intrapresa dall’utente. Per quanto riguarda i giochi di strategia, essi hanno avuto un buon successo ma
dobbiamo registrare una certa differenza di comportamento tra quelli studiati dai diversi ricercatori (ad esempio si è accertato che Warcraft 3 e Starcraft generano traffico
sostanzialmente diverso[8]).
La decisione, dunque, non può che riguardare uno degli sparatutto. Il successo di
questo genere, infatti, è consolidato da diversi anni. Tra questi, il videogioco forse più
22
diffuso in assoluto è Counter-Strike, già trattato, parzialmente da alcuni ricercatori a
detta dei quali il gioco manifesterebbe un comportamento abbastanza comune tra gli
FPS [11]. Nel prossimo capitolo verrà descritto il gioco e verranno forniti i dati circa
la sua diffusione.
23
Capitolo 2
Counter-Strike
Counter-strike(CS) è un mod1 del popolare sparatutto Half-Life ed è distribuito gratuitamente in rete solo per proprietari di quest’ultimo, gli altri possono comunque
acquistarlo al dettaglio.
CS offre un orientamento di gioco realistico, sia per ambientazione sia per resa
del combattimento: il giocatore viene catapultato nel mezzo di un’azione antiterroristica e può scegliere se schierarsi dalla parte dei corpi speciali della polizia o da quella
dei sequestratori di turno. Inoltre, può decidere che tipologia di combattente impersonare, con tanto di armi specifiche. Sempre all’insegna della verosimiglianza ogni
pistola o fucile presente nel gioco esiste davvero e si presume riproduca con buona
approssimazione pregi e difetti dell’originale.
2.1
Il segreto di un successo
Rimane incredibile come dalla costola di un gioco nemmeno pensato specificamente per il multiplayer come Half-Life, sia poi nato un titolo del calibro di CounterStrike, capace di catalizzare l’attenzione di migliaia e migliaia di utenti in tutto il mondo. Per la precisione, ad oggi si contano ben 32000 server attivi con oltre centomila
giocatori[21][22].
1 Mod
(abbreviazione dell’inglese modification) è il nome con cui vengono normalmente chiamate
le modifiche estetiche e funzionali ai videogiochi
24
Figura 2.1: Screenshot del videogioco Counter-Strike
La chiave di questo successo si deve ricercare nell’originalità del titolo. Infatti, si
discosta nettamente da altri videogiochi dello stesso genere come Unreal Tournment
e Quake 3 rispetto ai quali CS presenta una meccanica di gioco marcatamente diversa
puntando sull’azione di gruppo e sul realismo. Che si tratti di disinnescare una bomba
o di salvare degli ostaggi, non è quello individuale il punto di vista da tenere in considerazione, bensı̀ quello di squadra: non si vince singolarmente ma si contribuisce
alla vittoria della propria squadra agendo di conseguenza. Counter-Strike è, dunque,
pensato per premiare l’azione intelligente e coesa.
Il videogioco è stato realizzato secondo il paradigma client-server. Gli utenti che
intendono partecipare a una sessione di gioco devono collegarsi a un server centrale.
Ogni sessione viene disputata su una mappa pre-caricata e termina quando una delle
due squadre ha raggiunto tutti i suoi obiettivi. Tipicamente i server dispongono di un
set di mappe che in ciclo vengono caricate per ospitare le sessioni di gioco.
2.2
Counter-Strike in letteratura
I ricercatori che hanno già avuto modo di studiare questa applicazione hanno scoperto
che buona parte del traffico scambiato tra il server e i client è legato all’aggiornamento
della posizione dei vari giocatori, all’azione che intraprendono nonché alla possibilità
di comunicare tramite microfono. In particolare il server colleziona i dati provenienti
dai singoli utenti e periodicamente genera un burst2 che notifica ad ogni client lo stato
2 Periodicamente
il server genera in un colpo solo tanti pacchetti quanti sono i giocatori per
aggiornarli sullo stato del gioco
25
globale del gioco.
Tra tutti gli articoli accademici che hanno trattato Counter-Strike i più interessanti
sono Provisioning On-line Games: A Traffic Analysis of a Busy Counter-Strike Server
e A Traffic Characterization of Popular On-line Games di W. Feng, Network Analysis
of Counter-Strike and Starcraft di L. Claypool e Network game traffic modelling di J.
Faerber.
Feng pubblica nei sui articoli i risultati dell’analisi di una mole di dati davvero impressionante: 500 milioni di pacchetti. Le tracce, però, riguardano il traffico entrante e
uscente da un server molto famoso (mshmro.com). Sebbene non sembri direttamente
collegato all’obiettivo di questa tesi, conoscere in che modo agisce il server potrebbe
rilevarsi utile per capire a fondo il comportamento del client.
(a) CDF
(b) players
Figura 2.2: Grafici riportati negli articoli di Feng.
Tra i risultati più interessanti apprendiamo che il traffico di Counter-Strike appare,
fissato il numero di giocatori, altamente stabile e quindi prevedibile. La CDF riportata
in figura 2.2(a) mostra come i pacchetti prodotti dal client (inbound) abbiano dimensione media pari a 40byte e in generale non superino mai i 60, quelli generati dal server,
invece, si concentrano in un intervallo più ampio fino ai 300byte. Inoltre, in base al
numero di giocatori collegati, il server genera burst ad intervalli piuttosto regolari. Gli
articoli riportano anche uno studio originale sulla provenienza dei giocatori che si collegano abitualmente al server a testimonianza della diffusione a livello planetario di
questo videogame. A tal proposito si faccia riferimento alla figura 2.2(b).
26
Claypool confronta, in termini di traffico generato, Counter-Strike e Starcraft, un
popolare RTS. Alla luce delle differenze riscontrate si ottengono nuove informazioni
sul comportamento del client di CS: il traffico generato non dipende dal numero di
giocatori ma la dimensione dei pacchetti risulta fortemente influenzata dall’azione di
gioco. Nella fasi di analisi si dovrà, dunque, tenere conto di questa forte dipendenza,
cercando, se possibile, di individuare delle vere e proprio fasi di gioco.
Gli articoli di Faerber, invece, contengono finalmente una prima caratterizzazione
statistica del traffico. Per questo motivo vale la pena approfondirne i risultati:
L’analisi si è concentrata sul traffico generato dai client e dal server separatamente.
Si è scoperto che il traffico generato durante una sessione di gioco presenta un elevato
tasso di regolarità. I pacchetti UDP generati sono piccoli, il packetrate (il numero di
pacchetti inviati per secondo) si mantiene pressocchè invariato per tutta la sessione di
gioco e il server genera burst a intervalli regolari (60ms). In particolare, poiché siamo
interessati a studiarne il comportamento, notiamo come le tracce di traffico analizzate
da Faerber mostrino per il client le seguenti caratteristiche:
la dimensione dei pacchetti generati (considerando solo il payload di livello trasporto) si distribuisce tra i 60 e i 110 byte (in media 82 byte). In questo contrasta
con le indicazioni fornite da Feng per cui i pacchetti in ingresso al server non
supererebbero mai i 60 byte;
l’invio di due pacchetti successivi avviene in media ogni 41.7ms.
La modellazione analitica è stata realizzata sul traffico generato dal giocatore tipo,
calcolato come la media di tutti i giocatori. Mentre l’inter partenza dei pacchetti può
essere approssimata con una deterministica centrata a 40ms (in accordo a un packetrate medio di 25pkt/s), Faerber propone la distribuzione Extreme in una particolare
versione3 come la candidata migliore a rappresentare analiticamente la dispersione dei
campioni del packet-size.
In figura 2.3 si riportano i grafici esplicativi inseriti da Faerber nell’articolo.
3 Si
veda il capitolo 3
27
Figura 2.3: Funzione densità di probabilità per packet-size e inter-arrival time.
In aggiunta, si segnala che alcuni studiosi [4] hanno espresso critiche nei confronti
dell’analisi del traffico lato server: poiché Faerber isola il traffico scambiato tra il client
e il server assume implicitamente che l’ordine con cui vengono generati i pacchetti durante i burst si mantenga costante. In realtà, in burst successivi il pacchetto inviato a
uno specifico client potrebbe essere spedito una volta per primo e nel burst successivo per ultimo, ciò, se fosse dimostrato, influenzerebbe inevitabilemente l’inter-arrival
time.
Tuttavia, ricordando che lo scopo di questa tesi è quello di modellare il traffico
generato dal solo client, poiché non sono state mosse obiezioni in questo senso, si
considera la modellazione analitica proposta da Faerber un valido termine di paragone.
Inoltre, si cercherà di stabilire attraverso gli esperimenti quale sia l’intervallo effettivo
di valori all’interno del quale variano le dimensioni dei pacchetti generati, visto che su
questo punto nella comunità non c’è accordo.
28
Capitolo 3
Strumenti
In questo capitolo verranno descritti i parametri che saranno oggetto di analisi e gli
strumenti matematici che ne hanno permesso la caratterizzazione statistica. Sarà inoltre necessario descrivere quali scenari di gioco si è cercato di ricreare e come è stato
possibile collezionare e analizzare le tracce e gli strumenti software utilizzati.
3.1
Analisi a livello pacchetto
In letteratura sono stati proposti diversi approcci per lo studio del traffico di rete che
può essere visto a differenti livelli di astrazione: sessione; conversazione; connessione/flusso; pacchetto; byte. Si è deciso di caratterizzare il traffico a livello pacchetto.
Tra i tanti vantaggi che questo approccio comporta si vuole ricordare che dispositivi
di rete quali ad esempio routers, switch e access point operano, solitamente, a livello pacchetto e che a tale livello di astrazione è possibile riscontrare i problemi tipici
del networking come il delay, il jitter e la perdita di informazioni. Molto spesso questo approccio non viene preso in considerazione a causa della sua dipendenza dalle
condizioni della rete è anche vero, però, che aumentando l’intervallo di osservazione permette di evidenziare, quando presenti, caratteristiche di invarianza spaziale e
temporale[23].
Concentrando l’attenzione sul traffico generato dal client dell’applicazione di interesse definiamo i parametri che verranno caratterizzati statisticamente:
29
Packet-Size (PS): la dimensione dei pacchetti senza considerare gli 8 byte dell’header UDP. Questo vuol dire che verrà considerato esclusivamente il carico
utile (anche detto payload) dei segmenti, ossia i dati effettivi generati dall’applicazione.
Inter-Departure-Time(IDT) o Inter-Packet-Time(IPT)1 : l’intervallo di tempo che
impiega la sorgente di traffico a generare due pacchetti consecutivi.
Si faccia riferimento alla figura 3.1 per maggiori chiarimenti.
Figura 3.1: I parametri IDT e PS
3.2
Testbed degli esperimenti
Gli esperimenti hanno avuto luogo presso il laboratorio ARCLAB2 del Dipartimento
di Informatica e Sistemistica (D.I.S.) sito a via Claudio, presso la facoltà di Ingegneria
dell’Università degli Studi di Napoli Federico II.
Si è cercato di ricostruire situazioni di gioco significative. In particolare, gli scenari che abbiamo ricreato sono LAN party wired e wireless e match via Internet con
connessioni a banda larga ADSL. La modalità di gioco prescelta è il cosiddetto deathmatch, ovvero uno scontro tutti contro tutti nel quale vince chi uccide più avversari in
1 Nei
prossimi capitoli verranno utilizzati entrambi i termini
Architetture dei Sistemi di Elaborazione (ARCLAB).
2 Laboratorio
30
un tempo prefissato. La versione del gioco testata è la 1.5 e la mappa utilizzata in tutti
gli scenari è, per motivi di giocabilità, dmc dm6.
Tutte le tracce raccolte fanno riferimento a sessioni di gioco a cui partecipano 4
giocatori, studenti di Ingegneria. Nello scenario wired, grazie alla collaborazione degli
allievi dell’Accademia Areonautica, è stato possibile collezionare un’ulteriore traccia
di 8 giocatori. Si vuole sottolineare come, per precisione e coerenza dei risultati, gli
stessi giocatori abbiano partecipato ad ognuno degli scenari con le medesime macchine. Questo ci consentirà di poter confrontare il comportamento assunto da ogni
giocatore nei vari scenari.
Maggior realismo è assicurato dal fatto che i ragazzi che hanno partecipato agli
esperimenti hanno dichiarato livelli di preparazione informatica e di confidenza col
gioco molto diversi.
La tabella 3.1 mostra i dati relativi ai giocatori.
Nome
Alessandro G. (A)
Stefano (A)
Federico (A)
Silvana (A)
Giovanni (A)
Luca (I)
Alessandro (I)
Biagio (I)
Roberto (I)
Sesso
M
M
M
F
M
M
M
M
M
Eta’
20
20
22
19
19
25
24
23
23
Esperienza di gioco
medio - bassa
scarsa
buona
nessuna
media
nessuna
bassa
nessuna
nessuna
Esperienza informatica
media
discreta
discreta
scarsa
media
buona
buona
buona
buona
Tabella 3.1: Dichiarazioni dei giocatori prima degli esperimenti.
Ingegneria.
31
A - Areonautica I -
La tabella 3.2 mostra i dettagli delle macchine utilizzate.
Nome
S. O.
Alessandro
G. (A)
Stefano (A)
Win Xp
Pro
Win Xp
Federico
(A)
Silvana (A)
Win Xp
Giovanni
(A)
CPU
Win Xp
Pro
Win Xp
Luca
Win Xp
Alessandro
(Tekno)
Biagio
Win
Pro
Win
Pro
Win
Pro
Win
Pro
Roberto
PC
Ing.
Botta
Xp
Xp
Xp
Xp
RAM
(MB)
Intel P4 512
523
Intel
512
centrino
Intel
512
centrino
Intel
512
Centrino
Intel
1 GB
centrino
II
Intel
512
centrino
1.8GHz
Intel P4 512
2.4GHz
Intel p4 512
2.0 GHz
Intel P4 1024
3.4GHz
Intel
256
Centrino
Scheda video
LAN IP
ATI Radeon 9400
64MB
Integrata
1
Integrata
3
Integrata
4
ATI Mobility Radeon x1600 a partire da 128MB
ATI MB Radeon
9700 a partire da
64MB
ATI
Radeon
7200C 32MB
ATI Mobility Radeon 16MB
ATI Radeon 9700
64MB
Intel 82852 /
82855
5
2
11
12
13
14
Tabella 3.2: Dettagli sulle macchine utilizzate dai vari giocatori
Analizziamo adesso in dettaglio i vari scenari:
LAN PARTY
A supporto delle operazioni è stato utilizzato uno switch Cisco Catalyst 2970
24T, a 24 porte. Ai giocatori sono assegnati indirizzi IP che variano tra 10.0.0.15 per i ragazzi dell’Aeronautica e tra 10.0.0.11-14 per quelli di Ingegneria. Gli
indirizzi IP, inoltre, rispecchiano il numero di porta dello switch al quale si è
collegati. Nei match disputati su rete locale Luca utilizza il portatile dell’ing.
Botta, le cui caratteristiche sono riportate in tabella 3.2.
32
monitor session 1 destination interface GigabitEthernet? 0/24
monitor session 1 source vlan 1
monitor session 1 source interface GigabitEthernet? 0/23
Tabella 3.3: Configurazione dello switch CISCO per gli scenari LAN.
Lo switch è stato configurato in modo tale che tutto il traffico indirizzato al server
CS (indirizzo IP 10.0.0.253, collegato alla porta 23) sia replicato sulla porta 24.
A tal proposito si faccia riferimento alla tabella 3.3.
Alla porta 24 è collegato un portatile (10.0.0.250) che colleziona la traccia tramite il software Tcpdump. Tcpdump è uno strumento per l’analisi del traffico
che attraversa la rete fisica a cui si è collegati. Appartiene alla categoria degli
sniffer, ovvero quei programmi che catturano tutti i pacchetti che transitano per
la propria scheda di rete e ne estrapolano informazioni che possono in seguito
essere consultate. Nel nostro caso per ogni pacchetto il programma ha analizzato
un numero di byte pari al valore di default (snaplen) 3 .
Nello scenario wireless è stato utilizzato un access point (10.0.0.252) collegato
alla porta 22 dello switch. Tutti gli studenti di Ingegneria hanno utilizzato schede
wireless 802.11b tranne Roberto che ha utilizzato una 802.11g.
In figura 3.2 è riportata il testbed dell’esperimento.
3 Tcpdump
analizza per ogni pacchetti che transita nella rete un totale di snaplen byte. Aumentare
questo valore significa incrementare il tempo necessario a processare ogni pacchetto e cosı̀ il rischio di
perdere traccia di alcuni di essi. Il valore di default è di 68byte. Per maggiori informazioni si consulti
la manual page
33
Figura 3.2: Testbed dello scenario wireless
ADSL
I 4 studenti di Ingegneria che hanno accettato di partecipare all’esperimento si
sono collegati al server Counter-Strike collocato al D.I.S. da casa, con le proprie connessioni a banda larga. A supporto delle operazioni è stato utilizzato
uno switch della Enterasys, configurato in modo tale da replicare tutto ciò che
attraversa la porta 16 sulla porta 21 alla quale è collegata la macchina che colleziona il traffico diretto al server. A tal proprisito si faccia riferimento alla tabella
3.4. Inoltre, poiché a dispetto della dimensione locale in questo scenario la rete
influenza fortemente il traffico che giunge in ingresso al server, si è deciso di
raccogliere le tracce di traffico non solo in ingresso al server ma anche in uscita
ad ognuno dei client. Pertanto gli studenti hanno raccolto ciascuno il traffico
generato dalla propria macchina attraverso lo sniffer Ethereal. Osservare la stessa sessione di gioco sia dal punto di vista del server che del singolo client ci
permetterà di apprezzare gli effetti della rete sul traffico.
34
set port mirroring create ge.1.16 ge.1.21
set port mirroring enable ge.1.16 ge.1.21
Tabella 3.4: Configurazione dello switch ENTERASYS per gli scenari ADSL.
In aggiunta, data l’elevata complessità computazionale dello sniffer utilizzato
dai giocatori, Ethereal, e la relativa possibilità di corruzione dei timestamp associati ai pacchetti, si è deciso di collezionare un’ulteriore traccia, questa volta
solo lato server, evitando che i giocatori si facessero carico delle operazioni di
sniffing.
La tabella 3.5 mostra gli indirizzi IP e i provider dei ragazzi.
UTENTE
Luca
Alessandro
Biagio
Roberto
IP ADSL
85...69
82...181
213...125
151...246
PROVIDER
Fastweb
Telecom IB
Fastweb
Libero
Tabella 3.5: Indirizzi IP e provider nello scenario ADSL
In figura 3.3 è riportato il testbed dell’esperimento.
Figura 3.3: Testbed dello scenario ADSL
35
I log generati dai vari software di sniffing sono stati analizzati da un tool sviluppato presso il Dipartimento di Informatica e Sistemistica dell’Università degli Studi
Federico II dal nome Plab4 [24]. Questo software è in grado di decomporre il traffico
in sessioni per host, flussi o conversazioni. Inoltre, separa il traffico in ingresso (downstream) e in uscita (upstream) ad ogni sorgente di traffico rilevata generando per
ognuna di esse file di testo che contengono tutte le occorrenze di PS e IDT. In seguito,
questi dati possono essere agevolmente importati negli ambienti di calcolo per successive elaborazioni. Il programma genera i seguenti file di output:
hosts: informazioni sugli host
hosts ip2id: associazione tra indirizzi IP e identificativi (hostID).
pkts all: IPT e PS; relativo a tutto il traffico aggregato
pkts up: IPT e PS; traffico in uscita alla sorgente
pkts dw: IPT e PS; traffico in ingresso alla sorgente
rate: alcuni riferimenti statistici
report.txt: sommario; tiene traccia del comando lanciato e altre informazioni come il numero di pacchetti rilevati.
Le analisi documentate nel capitolo 4 si basano sulle informazioni contenute in
questi file.
4 Per
maggiori informazioni http://www.grid.unina.it/software/Plab/
36
3.3
Analisi statistica
Si faccia riferimento al PS5 . La sorgente di traffico, nel nostro caso il client dell’applicazione, genera per tutta la sessione di gioco pacchetti di dimensione variabile. Come
succede spesso nelle applicazioni pratiche, non è possibile stabilire a priori quale valore assumerà il parametro di interesse. E’ utile in questo senso adottare la teoria della
probabilità, basandosi sul concetto di misurazione ripetuta.
Il PS può essere modellato come una variabile aleatoria che assume valori in un
determinato intervallo6 . E’ risaputo, inoltre, che al concetto di variabile aleatoria è
possibile associare quello di densità di probabilità: una funzione, cioè, che integrata
restituisce la probabilità che l’esperimento abbia come risultato uno degli elementi ω
dello spazio campione la cui immagine, per mezzo della variabile aleatoria χ(ω), è
contenuta nell’intervallo di integrazione.
L’analisi delle tracce mostrerà un elevato numero di pacchetti dalle dimensioni
diverse (dette anche occorrenze) generati da ogni sorgente. Vediamo come a partire
da questi dati sia possibile arrivare a definire una funzione densità di probabilità che
rappresenti la distribuzione dei valori osservati, detta distribuzione empirica. Un semplice procedimento prevede l’uso di un grafo cartesiano: sull’asse delle ascisse sono
riportati tutti i valori che la variabile aleatoria può assumere. Individuato il valore
minimo e quello massimo si suddivide questo intervallo in segmenti non sovrapposti
(detti bin) di dimensioni fisse. Per ognuno di essi si traccia un rettangolo di altezza parti al numero di occorrenze che ricadono all’interno del bin diviso il numero di
osservazioni totali. L’altezza di questi rettangoli, definita anche frequenza relativa, è
la probabilità che il parametro d’interesse assuma valori all’interno di quel segmento.
Infine, il passaggio al limite, ovvero facendo in modo che i bin collassino in un punto,
permette di delineare la distribuzione empirica.
Spesso della distribuzione empirica interessano poche informazione, esprimibili
attraverso alcuni parametri detti sintetici: il valore medio e l’indice di dispersione che
fornisce informazioni importanti sulla distribuzione dei risultati. L’indice di dispersio5 Il
discorso è assolutamente simmetrico per l’IDT
tal proposito ricordiamo che i pacchetti non superano mai la dimensione della MTU (Maximum
Trasmission Unit) tipicamente pari a 1500byte
6A
37
ne è la radice quadrata della varianza ed è una stima sul livello di concentrazione della
variabile aleatoria intorno al suo valor medio. In altri termini, se la variabile aleatoria
ha varianza piccola, allora essa è poco dispersa intorno alla sua media (assumerà con
maggior probabilità valori intorno al valor medio); viceversa, se la variabile aleatoria
ha varianza grande, allora essa è molto dispersa (assumerà con maggior probabilità
valori distanti dal valor medio)[25].
A partire, dunque, dalle misurazioni effettuate durante gli esperimenti per ognuna
delle sorgenti di traffico avremo un insieme di valori del PS e dell’IDT.
Per manipolare e filtrare i dati estrapolati con Plab si è utilizzato Matlab7 . Quest’ultimo è sia un ambiente per il calcolo numerico che un linguaggio di programmazione interpretato. Tra i vari tool che sono stati utilizzati si vuole ricordare Dfittool
che permette di approssimare un set di dati con diverse distribuzioni analitiche. Inoltre
fornisce la possibilità di confrontare graficamente la distribuzione empirica e l’analitica. Le operazioni di analisi sono state realizzate sfruttando script matlab sviluppati
e messi a disposizione dal dipartimento[26]. In molti casi, dunque, ci si è limitati a
utilizzare e modificare script pre-esistenti.
In merito alla larghezza dei bin non esiste una regola universale ma una serie di
indicazioni. Nel nostro caso si è adottata la regola di Scott[27]. Una sua implementazione in linguaggio matlab è lo script scott.m. Ne riportiamo l’help inline in figura
3.4.
%
%
%
%
%
%
function [w,bins] = scott(c,normal,factor);
function [w,bins] = scott(c,normal,factor);
Calculate bins width and bins vector using the Scott’s
rule applied to vector c
normal = 1 : Use Normal rule
normal = 0 : Use Correct normal rule with skewness factor
factor : Multiply calculated width by factor
Figura 3.4: Help Inline dello script scott.m
Un preliminare approfondimento del traffico generato dal client è stato realizzato
attraverso lo script analisi.m che è in grado di automatizzare le operazioni di analisi del
traffico a partire dai file generati da Plab. Nello specifico, studia il traffico in ingresso
7 abbreviazione
di Matrix Laboratory. Maggiori informazioni su www.mathworks.com
38
(downstream) e in uscita (upstream) ad ogni sorgente di traffico rilevata. Sul PS e
l’IDT genera molteplici grafici: pdf e cdf empiriche, byterate e packetrate, sequenze
delle occorrenze, autocorrelazione, FFT, ACF e cosı̀ via. A seconda dello scenario è
stato necessario modificarlo in più parti ma nel complesso può essere considerato il
punto di partenza per tutte le operazioni di analisi.
Fitting
L’obiettivo successivo è quello di individuare tra tutte le possibili candidate, la distribuzione analitica8 che nel modo più efficace ricalca la distribuzione empirica. Questo
procedimento che prende il nome di Fitting risulta abbastanza complesso: esistono,
infatti, tantissime funzioni densità di probabilità, eppure raramente la distribuzione
empirica assume forma identica a una di esse. Riportiamo di seguito gli elementi
chiave che hanno permesso di individuare il modello analitico più adatto:
Expectation-maximization (EM)[28]: algoritmo che, massimizzando la verosimiglianza, restituisce i parametri per un certo insieme di distribuzioni candidate
ad approssimare il set di dati osservati sperimentalmente. Ad esempio, lo script
fitting.m implementando l’algoritmo EM, fornisce, dato in ingresso l’array delle
occorrenze, i parametri per le seguenti distribuzioni: gaussiana, esponenziale,
weibull, gamma, lognormal, rayleigh, uniforme.
Lambda-square λ2 [29]: strumento matematico che, fornendo una misura della
discrepanza tra due distribuzioni statistiche, permette di stabilire quale tra le distribuzioni con parametri assegnati approssimi meglio la distribuzione empirica.
Inoltre, in base al suo valore è possibile stimare il livello qualitativo del fitting
che si sta realizzando. Minore è il suo valore migliore è il risultato ottenuto. Lo
script che permette di calcolare tale parametro si chiama lambda-square.m. Ne
riportiamo l’help inline in figura 3.5.
Mixture: applicando l’algoritmo EM a un mix di due distribuzioni è possibile
calcolare i parametri di due pdf che opportunamente pesate e combinate permettono di costruire un modello analitico che in determinate occasioni è il più adatto
8 Una
funzione densità di probabilità individuata da un’espressione matematica
39
function [x2,lambda2,dev] = lambdasquare(empiric,analytic,p,b,mmin,mmax)
% Estimates lambda2 discrepancy
% [x2,lambda2,dev] = lambdasquare(empiric,analytic,p,b,min,max)
% p = parameters of the analytical distribution
% b = custom bins vector or bin width
% min,max:
% Use 0,0 to not make any truncations
% Use 1,1 to truncate analytical to match min and max from empirical
% Use different values to truncate both distros at your pleasure
Figura 3.5: Help Inline dello script lambda-square.m
ad approssimare il set di dati osservati sperimentalmente. Su questo principio si
basano i seguenti script:
– Normmix2.m[28]: applica l’algoritmo EM a due distribuzioni gaussiane.
Lo script richiama ricorsivamente se stesso cercando di massimizzare la
verosomiglianza tra la distribuzione analitica proposta e quella empirica.
Ad ogni ricorsione si calcolano nuovi parametri per le due gaussiane. A tal
proposito si è deciso di modificarne l’inizializzazione in modo da centrare
le due distribuzioni nel valore minimo e massimo tra quelli che dovranno
essere caratterizzati. In questo modo, sebbene aumenti il numero di ricorsioni necessarie, sperimentalmente è possibile verificare che tutti i set di
dati che si concentrano intorno a due diversi valori vengono correttamente
approssimati. Riportiamo l’help inline dello script in figura 3.6.
– Gammix2.m: sulla falsariga di normmix2, si è ritenuto utile realizzare uno
script che utilizzasse, al posto di due gaussiane, due gamma. Quando la
distribuzione empirica presenta due picchi molto stretti, infatti, attraverso
l’uso di due distribuzione gamma si ottengono approssimazioni migliori.
Tale script, come si vedrà nei prossimi capitoli, ha prodotto buoni risultati
almeno in uno scenario.
40
function [p, m, s, x, pdf, an] = normmix2(data,iter,flag)
%function [p, m, s, x, pdf, an] = normmix2(data,iter,flag)
% Perform statistical fitting using the Expectation Maximization
% algorithm with a mixture of 2 Gaussian distributions.
%
% INPUT
% data:
data to be fitted
% iter:
max number of iterations (0 = default)
% flag:
OPTIONAL:
%
0
do nothing
%
1
plot a comparison of the PDFs
%
% OUTPUT
% p:
percentages
% m:
param1
% s:
param2
% x:
x for the pdf
% pdf:
y for the pdf
% an:
OPTIONAL: generate 100k random numbers following
%
the obtained mixture
Figura 3.6: Help Inline dello script normmix2.m
Distribuzioni particolari
E’ opportuno, a questo punto, descrivere le distribuzioni analitiche ritenute più interessanti.
Extreme
Citata più volte, è la distribuzione che ha utilizzato Faerber per model-
lare il PS di Counter-Strike. A tal proposito si desidera fare un piccolo appunto: nell’articolo viene definita semplicemente come Extreme eppure essa differisce da quella
messa a disposizione dell’ambiente di calcolo Matlab. Un breve approfondimento ci
ha permesso di scoprire che di questa distribuzione ne esiste una forma generale, chiamata Generalized Extreme Value9 , che dipende da tre parametri: location (a), scale
(b), shape (k). Ne riportiamo l’espressione nell’eq 3.1:
f (x) =
9 La
1
e
b
1+k
x
a
! 1
k
b
1+k
x
a
1
1
k
b
Generalized Extreme Value è disponibile in Matlab dalla versione 2006b
41
(3.1)
La Generalized Extreme Value viene tipicamente utilizzata per modellare con efficacia un set di campioni o molto grandi (large) o molto piccoli (small). In particolare
si può specializzare in 3 forme diverse, in base al valore assunto dal parametro shape,
che vengono identificate come Tipo I, II e III. A volte a quest’ultimi vengono associati
i nomi: Gumbel, Frecht e Weibull[30]. La Extreme citata da Faerber corrisponde alla
Gumbel e si ottiene dalla forma generalizzata ponendo shape a zero. L’espressione
della densità di probabilità è riportata dall’equazione 3.2:
f (x) =
Student’s T location-scale
1
e
b
x
x
a
b e
a
b
e
(3.2)
[30] Un’altra distribuzione molto interessante in re-
lazione alle operazioni di fitting documentate nei prossimi capitoli è la cosiddetta Student’s T. Tutte le informazioni a riguardo sono state prelevate dalla documentazione
dell’ambiente di calcolo Matlab. Anche questa distribuzione esiste in varie forme. Nella versione standard l’unico parametro è il grado di libertà, e la densità di probabilità
ha l’espressione riportata dall’equazione 3.3:
f (xjν) =
ν+1
)
1
2 p1
ν
ν+1
νπ
2
Γ( )
x
2
) 2
(1 +
ν
Γ(
(3.3)
Con Γ() la funzione gamma di cui riportiamo l’espressione nell’equazione 3.4:
Γ(α) =
Z ∞
e ttα
1
dt
(3.4)
0
Ben più interessante risulterà la General form detta anche t location-scale riportata
42
dall’equazione 3.5
2
f (x) =
3
x µ 2
ν+1
ν+(
)
)
Γ(
64
75
σ
2
p
ν
ν
σ νπΓ( )
2
(
ν+1
)
2
(3.5)
dove µ è il parametro location, σ è detto scale ed è > 0 e ν è il parametro shape. In
x µ
si distribuisce
particolare, se x si distribuisce secondo la t location-scale allora
σ
secondo la versione standard con ν gradi di libertà[30].
Tutti questi strumenti e altri sviluppati ad hoc saranno utilizzati per le operazioni
di analisi i cui risultati sono riportati nel capitolo 4.
43
Capitolo 4
Analisi delle Tracce
In questo capitolo sono pubblicati i risultati delle analisi condotte sulle tracce raccolte.
In particolare, si mostrerà in accordo a quanto sostenuto da Claypool[6], che il gioco
manifesta delle vere e proprie fasi di gioco diverse, che chiameremo fase attiva e fase
inattiva. In ogni scenario verrà adottato questo approccio: una preliminare analisi della
traccia nella sua interezza mira a individuare eventuali fasi di gioco; la modellazione
statistica che ne consegue verterà sulle singole fasi, quando presenti. Di norma, le
operazioni di fitting verranno realizzate sempre sul giocatore tipo, ottenuto come la
media di tutti i partecipanti alla sessione che manistefano un comportamento simile,
un approccio già utilizzato da altri ricercatori come Faerber e Lang[5][15][17]. Una
volta ottenuta la distribuzione empirica da dover approssimare in alcuni casi è stato
necessario filtrare i dati per poter raggiungere dei risultati migliori.
4.1
LAN party: wired 4 giocatori
A questa sessione di gioco partecipano i 4 ragazzi di Ingegneria. La traccia collezionata con Tcpdump, che chiameremo log1, è stata analizzata da Plab. Questo programma
è in grado di prendere in considerazione solo una parte della traccia imponendo vincoli
temporali. Tuttavia, per ora non si è interessati ad alcun tipo di filtraggio. Si vuole, invece, ottenere una prima idea del traffico generato dal client. In ordine, dunque, viene
lanciato da riga di comando il seguente:
44
./plab -r ./log1.dump -q h -d log1 udp and port 27015
Brevemente:
-r ../log1.dump indica lettura da un file (Plab è anche sniffer)
-q h suddivisione del traffico per host
-d log1 directory di destinazione per i file di output
udp and port 27015 filtri, considera solo traffico UDP in cui una porta
coinvolta sia la 27015 (quella del server CS)
Il file report.txt permette anche a distanza di tempo di verificare quale parte della
traccia si sta analizzando. Il contenuto è riportato in figura 4.1.
command line:plab -r ./log1.dump -q h -d log1 udp and port 27015
Time interval of observation: 1748 seconds (29 min - 0 h)
First examined packet had timestamp:
Sat Nov 11 13:06:49 2006
Last examined packet had timestamp:
Sat Nov 11 13:35:58 2006
Packet processing started at:
Sat Nov 11 13:38:24 2006
Packet processing finished at:
Sat Nov 11 13:38:25 2006
packets read:
285936
mean throughput:
163 pkts/sec
packets discarded:
0
fragments:
0
packets were truncated (damaged):
0
packets with optional IP headers:
0
packets had invalid tcp payload:
0
packets generated by TCP:
0
packets with optional TCP headers:
0
Total Hosts found:
Src Hosts found:
Src Hosts timeout:
Dst Hosts found:
Dst Hosts timeout:
6
5
0
6
0
Figura 4.1: Report.txt dello scenario wired a 4 giocatori
Il file hosts ip2id ci permette di discriminare le sorgenti di traffico. Plab assegna
un identificativo, un intero in ordine crescente, alle sorgenti che riscontra man mano. I
file che contengono il traffico vero e proprio fanno riferimento a questi identificativi e
non agli indirizzi IP delle sorgenti. Si deve tenere presente che nel momento in cui si
dovesse prendere in considerazione solo una parte della traccia, molto probabilmente
45
cambieranno gli identificativi in quanto Plab potrebbe rilevare le sorgenti in ordine
diverso.
Analisi:
avviando l’ambiente di calcolo Matlab basta lanciare analisi.m per ottenere
un’idea preliminare del traffico che abbiamo collezionato. Tra le modifiche che vanno
apportate a tale script vi è l’assegnazione degli identificativi ai vari giocatori associati
da Plab agli indirizzi IP, in quanto questi cambiano da traccia a traccia e quando si
analizzano parti diverse della stessa traccia. Sulle indicazioni fornite da Claypool si è
deciso di verificare l’esistenza di fasi di gioco diverse.
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.2: Wired 4pl - traffico in uscita dai client: Byterate
46
In effetti i grafici riportati in figura 4.2 mostrano chiaramente un comportamento
diverso del client durante la sessione di gioco: il byterate dei giocatori cambia durante
la sessione. All’inizio e alla fine i giocatori sono semplicemente collegati al server
e non giocano. Durante questa fase, detta pertanto inattiva, il byterate si mantiene
intorno a 600. Quando invece si inizia a giocare il byterate aumenta mantenendosi,
per tutti i client, su valori superiori a 1000. Ad esempio, il personaggio di Alessandro
dopo poco più di 13 minuti di gioco muore, e non rientra in gioco (respawn) per quasi
3 minuti. E’ evidente come questo si ripercuota sul traffico generato. Tuttavia, una
differenza cosı̀ marcata non è riscontrabile nel packetrate come evidenzia la figura 4.3.
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.3: Wired 4pl - traffico in uscita dai client: Packetrate
47
I grafici mostrano, infatti, che indipendentemente dalla fase di gioco i client generano, per la maggior parte del tempo, 24 pacchetti al secondo. Tuttavia si registra
l’anomalia del comportamento nel finale di gioco del client Biagio che passa a generare
costantemente 22 pacchetti al secondo.
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.4: Wired 4pl - traffico in uscita dai client: PS Sequence
In conclusione, esistono due fasi diverse ma la differenza è nella dimensione non
nel numero di pacchetti inviati al secondo che rimane costante per tutta la sessione di
gioco intorno ai 24pkt/s. Tale risultato è sostanzialmente in linea con un IDT medio
di 41.7ms riscontrato da Faerber. In effetti quando il giocatore è attivo deve scambiare
con il server una mole maggiore di dati. In alcuni videogiochi, ad esempio Starcraft,
una maggiore quantità di informazioni si traduce in un numero maggiore di pacchetti
48
inviati al secondo[6]. CS, invece, genera pacchetti a intervalli molto regolari indipendentemente dal tipo di attività del giocatore, l’azione influenza esclusivamente il PS
che come mostrano i sequence riportati in figura 4.4 sono molto diversi nelle due fasi.
I grafici evidenziano un’altra tendenza: nel passaggio da una fase all’altra vengono
generati pacchetti più grandi rispetto alla media (occorrenze evidenziate nei cerchietti
rossi). Ulteriore conferma è fornita dal confronto tra le distribuzioni empiriche del PS
nelle due fasi gioco riportato in figura 4.5.
(a) Attiva
(b) Inattiva
Figura 4.5: Wired 4pl - PS: distribuzioni empiriche a confronto.
Pertanto si è deciso di isolare le due fasi e di analizzarle separatamente.
49
4.1.1
Fitting della fase attiva
Si tratta, a questo punto, di filtrare una parte della traccia in cui tutti i giocatori si
trovino in fase attiva. Il report.txt informa che la traccia è stata collezionata dalle ore
13:06:49 e l’ultimo pacchetto è stato sniffato alle 13:35:58. Si è deciso di isolare la
parte centrale, attiva per tutti i giocatori, che va dalle 13:10 alle 13:20 e che corrisponde
all’intervallo 191-791s sui grafici. Ecco il comando:
./plab -r ./log1.dump -q h -d log1 fase attiva -T 13:10-13:20 udp and port 27015
Procediamo adesso alle operazioni di caratterizzazione e fitting per i parametri di
interesse.
4.1.2
IPT
Riportiamo in figura 4.6 l’andamento sovrapposto delle distribuzioni empiriche dei
quattro giocatori.
Figura 4.6: Wired 4pl - Fase attiva: IPT distribuzioni empiriche
50
Distribution: Student’s T location-scale
Parameter Estimate
Std. Err.
mu
41699.4
0.621813
sigma
104.821
0.797037
nu
0.704073
0.00437777
Tabella 4.1: Dfittool: Student’s T location-scale - Fitting IPT [Wired 4pl Attiva]
La figura 4.6 mostra come la maggior parte delle occorrenze dell’IPT si concentri
intorno a 41.7ms. Tale concentrazione è cosı̀ elevata che è stato complesso individuare una distribuzione che potesse efficacemente ricalcarne l’andamento. Innanzitutto
è stata calcolata la distribuzione empirica associata al giocatore tipo, semplicemente
calcolando la densità di probabilità di tutte le occorrenze dell’IPT indipendentemente
dal giocatore. I dati cosı̀ ottenuti sono stati filtrati eliminando le occorrenze superiori
a 180ms, in tal modo comunque si è considerato più del 99.9% dei campioni. Utilizzando Dfittool, il tool di statistica fornito dall’ambiente Matlab, è stato possibile
individuare la distribuzione che nel migliore dei modi ricalcasse l’andamento della distribuzione empirica: la Student’s T versione location-scale. In particolare, il tool ha
calcolato i parametri della distribuzione restituendo i risultati riportati in tabella 4.1.
E’ possibile stimare la bontà del fitting calcolando il λ2 attraverso l’omonimo
script.
In base all’help riportato nel capitolo 3, lambda-square.m necessita di un numero elevato di campioni generati secondo il modello analitico candidato e del vettore
di bins. Purtroppo in Matlab, non esiste un generatore di numeri casuali secondo la
Student’s T versione location-scale. Una sua implementazione è stata realizzata a partire dal generatore di numeri random secondo la Student’s T nella versione standard
disponibile col nome trand. Si veda il listato presente in figura 4.7.
I campioni ottenuti secondo la Student’s T col grado di parità uguale al parametro
shape della versione location-scale vengono moltiplicati per il parametro scale e sommati a location. Non ci resta che calcolare il vettore di bin. Applichiamo le regole di
Scott[27] sfruttando l’omonimo script:
[width,bin]=scott(ipt empirica,1,1);
51
function r = tlsrandom(mu, sigma, nu, varargin)
%TLSRND Random arrays from the t location-scale distribution.
% mu - location
% sigma - scale
% nu - shape
sigma(sigma <= 0) = NaN;
nu(nu <= 0) = NaN;
[err, sizeOut] = statsizechk(3,mu,sigma,nu,varargin{:});
r = mu + sigma.*trnd(nu,sizeOut);
Figura 4.7: TLSRND: generatore di numeri casuali secondo la Student’s T location-scale
Generiamo un vettore di centomila occorrenze secondo la distribuzione Student’s T
versione location-scale con i parametri forniti da Dfittool.
ipt analitica=tlsrandom(41699.4,104.821,0.704073,100000,1);
Calcoliamo infine il valore del λ2 :
[x,lambda,dev] = lambdasquare(ipt empirica,ipt analitica,[1 1 1],bin,0,180000);
lambda = 0.1897
La figura 4.8 riporta i risultati.
Figura 4.8: Wired 4pl - Fase attiva: Fitting IPT
52
Il valore del λ2 non è brillante, tuttavia la particolare forma della distribuzione empirica non permette di raggiungere risultati migliori tramite l’adozione di altre
distribuzioni.
4.1.3
PS
La figura 4.9 mostra il particolare andamento del Packet Size per ognuno dei client.
Figura 4.9: Wired 4pl - Fase attiva: PS distribuzioni empiriche
Come preannunciato l’andamento delle distribuzioni è riconducibile a due gaussiane, i vari tentativi di utilizzare un unica distribuzione hanno portato a risultati molto
scarsi. Per tale motivo si è deciso di approssimare la distribuzione empirica del giocatore tipo con un mix di due gaussiane. Questo procedimento è stato realizzato grazie
allo script pre-esistente normmix2.m che provvede anche a generare centomila occorrenze secondo la distribuzione analitica. Procediamo, dunque, con le operazioni di
fitting1 :
1 E’
stata apportata una modifica al file normmix2.m, sostituendo la riga 92 con la seguente y =
zeros(size(x))+0.001
53
[
p; m; s; x; pd f ; an] = normmix2(ps empirica,0,1);
s=
4.3915
3.6186
sigma
m=
34.8352
49.4904
mu
p=
0.3732
0.6268
peso delle 2 gaussiane
Il fitting raggiunge ottimi risultati. Infatti il λ2 è pari a 0.0842. La figura 4.10
testimonia la bontà del fitting realizzato.
Figura 4.10: Wired 4pl - Fase attiva: Fitting PS
4.1.4
Fitting della fase inattiva
Si procede, adesso, ad isolare la parte inattiva della traccia. Tutti i giocatori sono inattivi durante la fase finale della sessione di gioco. Il lasso di tempo preso in considerazione va dalle ore 13:29:00 alle 13:34:58 e corrisponde all’intervallo 1331-1689sec
nei grafici del byterate. Il filtraggio viene realizzato con Plab tramite il comando
./plab -r log1.dump -q h -d ../log1 fase inattiva -T 13:29-13:34:58 udp and port 27015
Procediamo adesso alle operazioni di fitting per i parametri di interesse.
54
4.1.5
IPT
La figura 4.8 mostra l’andamento sovrapposto delle distribuzioni empiriche dei quattro
giocatori.
Figura 4.11: Wired 4pl - Fase inattiva: IPT distribuzioni empiriche
Osservando la figura 4.11 si nota il comportamento anomalo di Biagio rispetto
agli altri giocatori. In base alle affermazioni di Lang[15] e Borella[10], tale anomalia
potrebbe essere ricondotta alla hardware della macchina utilizzata dal giocatore. La
tabella 3.2 ne riporta informazioni circa la scheda grafica che risulta a 16MB, meno
potente di quelle utilizzate dagli altri partecipanti. Sembra, dunque, che schede grafiche meno potenti siano portate a generare pacchetti ad intervalli maggiori. Si cercherà
di verificare tale tendenza anche negli altri scenari. Tuttavia registriamo che, a livello macroscopico, per tutti i giocatori le occorrenze sono concentrate in un intervallo
temporale (41-47ms) di appena 6ms.
Sebbene, dunque, a un livello di astrazione maggiore tutti i client manifestino un
comportamento comune, l’analisi statistica non considererà le occorrenze generate da
Biagio. Prendere in considerazione anche le sue occorrenze avrebbe sicuramente portato a pessimi risultati nelle operazioni di fitting. Pertanto, i campioni che daranno
55
Parameter Estimate
Std. Err.
mu
41685.8
0.606114
sigma
69.4393
0.739169
nu
1.08341
0.0127999
Tabella 4.2: Dfittool: Student’s T location-scale - Fitting IPT [Wired 4pl Inattiva]
vita alla distribuzione empirica del giocatore tipo saranno quelli riconducibili a Luca,
Alessandro, Roberto. Per migliorare il fitting è stato necessario un filtraggio che ha
eliminato le occorrenze esterne all’intervallo 35-60ms. Tuttavia l’analisi ha riguardato
il 98,8% delle occorrenze totali.
Ancora una volta i risultati migliori si ottengono con la distribuzione Student’s
T versione location scale, i cui parametri forniti da Dfittool vengono riportati nella
tabella 4.2.
Per poter stimare la bontà del fitting dobbiamo lanciare lo script lambda-square.m.
Prima, però, dobbiamo calcolare i parametri di ingresso dello script generando un
elevato numero di campioni secondo il modello analitico candidato e il vettore di bins:
[width,bins]=scott(ipt empirica,1,1);
ipt analitica=tlsrandom(41685.8, 69.4393, 1.08341,1000000,1);
x lambda; dev] = lambdasquare(ipt empirica,ipt analitica,[1 1 1],bins,35000,50000)
[ ;
lambda = 0.1017
La figura 4.12 riporta la sovrapposizione tra il modello analitico e la distribuzione
empirica: il grafico dimostra la bontà del fitting realizzato.
4.1.6
PS
La figura 4.13 mostra l’andamento sovrapposto del Packet Size per ognuno dei client.
La figura mostra come i client durante le fasi inattive generino pacchetti di dimensioni precise che variano tra pochi valori. Inoltre, non riscontriamo nell’andamento
del PS un comportamento anomalo di Biagio. Tuttavia, per coerenza, si procede alla
creazione della distribuzione empirica escludendo tale giocatore in accordo a quanto
56
Figura 4.12: Wired 4pl - Fase inattiva: Fitting IPT
realizzato nell’analisi dell’ IPT. Tra i modelli analitici più idonei risulta la distribuzione gamma con la quale è possibile ottenere un λ2 pari a 0.073. Tuttavia, poiché i client
generano pacchetti la cui dimensione varia tra soli 8 valori, si è preferito utilizzare una
distribuzione discreta cosı̀ caratterizzata:
27byte=83.12%
29byte=4.53%
31byte=8.79%
33byte=1.06%
28byte=0.18%
30byte=1.95%
32byte=0.24%
35byte=0.13%
Il λ2 corrispondente è inferiore a 10 4 , di fatto un ottimo risultato. In figura 4.14
il grafico conclusivo.
57
Figura 4.13: Wired 4pl - Fase inattiva: PS distribuzioni empiriche
Figura 4.14: Wired 4pl - Fase inattiva: Fitting PS
58
4.1.7
Conclusioni sullo scenario wired a 4 giocatori
Il primo scenario ha mostrato alcune caratteristiche che se riscontrate anche negli altri
scenari potrebbero rappresentare quell’invarianza che la tesi cerca di verificare in questo tipo di applicazioni realtime. Di fatto, indipendentemente dalla fase, il client genera
pacchetti ogni 41.7ms in media, con una dispersione inferiore durante la fase inattiva.
I pacchetti generati sono sempre inferiori ai 60 byte ma mentre nella fase attiva la dimensione varia tra i 20 e i 60byte quando il client non è attivo la dimensione assume
solo 8 valori compresi tra i 27 e i 35byte. Tale comportamento può essere collegato al
minor numero di informazione da dover scambiare quando il client è inattivo.
59
4.2
LAN party: wired 8 giocatori
A questa sessione di gioco partecipano anche 5 allievi dell’accademia areonautica, tra
gli studenti di Ingegneria, infatti, non partecipa Luca che era assente. Si riporta il contenuto del file report.txt in figura 4.15.
command line: plab -r log1-wired-8pl -q h -d log1-8pl udp and port 27015
Fri Nov 17 18:14:09 2006
Fri Nov 17 18:34:36 2006
Mon Jan 22 10:20:38 2007
Mon Jan 22 10:20:39 2007
packets read:
402148
mean throughput:
328 pkts/sec
packets discarded:
0
fragments:
0
0
0
0
0
0
Total Hosts found:
Src Hosts found:
Src Hosts timeout:
Dst Hosts found:
Dst Hosts timeout:
10
9
0
10
0
Figura 4.15: Report.txt dello scenario wired a 8 giocatori
Anche stavolta si procede ad analizzare la traccia nella sua interezza con l’ausilio
dello script analisi.m, opportunamente modificato per supportare 8 giocatori. La figura
4.16 contiene alcuni grafici di interesse.
Il byterate mostra come non ci sia stata in questa sessione di gioco una fase inattiva.
Infatti, i giocatori risultano attivi dal momento in cui si collegano al server fino al
termine del match. Si procede pertanto ad analizzare in dettaglio l’unica fase di gioco
riscontrata.
60
(a) AlessandroG.(A)
(b) Stefano(A)
(c) Federico(A)
(d) Silvana(A)
(e) Giovanni(A)
(f) Alessandro(I)
(g) Biagio(I)
(h) Roberto(I)
Figura 4.16: Wired 8pl - traffico in uscita dai client: Byterate
61
4.2.1
Sebbene, i giocatori siano sempre attivi, si è reso necessario eliminare la parte iniziale
e finale della traccia. Eventuali meccanismi di sincronizzazione, infatti, non possono
essere considerati parte della fase attiva. In base a quanto riportato dal report.txt stilato
da Plab nell’analisi dell’intera traccia, il traffico è stato collezionato dalle ore 18:14:09
alle ore 18:34:36. L’analisi seguente esclude il traffico collezionato all’esterno dell’intervallo temporale che va dalle ore 18:15 alle ore 18:30, corrispondente all’intervallo
51-951s sui grafici del byterate, tramite il comando:
./plab -r log1-wired-8pl -q h -d wired8 -T 18:15-18:30 udp and port 27015
Si procede, adesso, alla consueta caratterizzazione statistica.
4.2.2
IPT
La figura 4.17 mostra l’andamento sovrapposto dell’IPT per ognuno dei client.
Figura 4.17: Wired 8pl - Fase attiva: IPT distribuzioni empiriche
Dall’analisi delle pdf si evince una certa eterogeneità dei giocatori. Da un punto
di vista macroscopico, tuttavia, registriamo ancora una volta un concentrazone delle
62
Parameter Estimate
Std. Err.
mu
41680.4
0.200821
sigma
59.9435
0.265052
nu
0.773752
0.00295488
Tabella 4.3: Dfittool: Student’s T location-scale - Fitting IPT [Wired 8pl Attiva (1 tentativo)]
occorrenze in un intervallo di poco superiore a 3ms centrato in 41.7ms. A livello
microscopico dobbiamo registrare che sebbene la media delle distribuzioni coincida
per tutti intorno ai 41.7ms, la forma varia a seconda dei giocatori.
In particolare si ha che Alessandro(I) e Roberto hanno un comportamento abbastanza consolidato che risulta diverso però da Silvana, Stefano e Federico a sua volta
distante da quello di Biagio, Giovanni e Alessandro(A). Tale differenza non è imputabile né alla scheda grafica né al notebook né alla esperienza di gioco, in quanto
giocatori con andamento simile della distribuzione presentano caratteristiche decisamente diverse. Tuttavia, la differenza è in termini di dispersione della distribuzione,
il picco è per tutti a 41.7ms e rispetto ad altre tipologie di traffico questo rappresenta
sicuramente un caratteristica invariante.
Filtrando la distribuzione empirica, ma considerando il 99.95% delle occorrenze,
si ottiene un primo fitting con una Student’s T location-scale con i parametri restituiti
da Dfittool riportati in tabella 4.3. Tuttavia, il λ2 è pari a 0.3268.
Se però non si conderano Roberto e Alessandro(I), che sono quelli con il comportamento più anomalo, si raggiunge un buon fitting grazie a una Student’s T location-scale
con i parametri riportati in tabella 4.4.
Parameter Estimate
Std. Err.
mu
41679.3
0.203431
sigma
51.8522
0.248281
nu
0.821518
0.00358796
Tabella 4.4: Dfittool: Student’s T location-scale - Fitting IPT [Wired 8pl Attiva (2 tentativo)]
Infatti il λ2 si abbassa notevolmente:
63
[width,bins]=scott(ipt empirica,1,1);
ipt analitica=tlsrandom(41679.3, 51.8522, 0.821518,1000000,1);
x lambda; dev] = lambdasquare(ipt empirica,ipt analitica,[1 1 1],bins,35000,50000)
[ ;
lambda = 0.0786
Si riportano in figura 4.18 i grafici relativi al fitting della distribuzione empirica
che non tiene conto delle occorrenze generate da Alessandro(I) e Roberto.
Figura 4.18: Wired 8pl - Fase attiva: Fitting IPT
4.2.3
PS
La figura 4.19 mostra l’andamento del Packet Size per ognuno dei client. In accordo a quanto realizzato per l’IPT la modellazione analitica riguarderà la distribuzione
empirica che non tiene conto delle occorrenze generate da Alessandro e Roberto. Tra
le distribuzioni analitiche, quella che si conferma la miglior candidata è la mix di due
gaussiane:
[
p; m; s; x; pd f ; an] = normmix2(ps empirica,0,1);
s=
1.5662
4.5025
sigma
m=
33.4934
48.0495
mu
p=
0.2071
0.7929
64
Figura 4.19: Wired 8pl - Fase attiva: PS distribuzioni empiriche
Il λ2 corrispondente è pari a 0.24, non un fitting ottimo.
Il risultato può essere migliorato. Si è deciso, infatti, di implementare un nuovo
script, sulla falsa riga di normmix2.m, che utilizzasse distribuzioni gamma al posto
delle gaussiane denominato pertanto gammix2. Tale script ha restituito i seguenti valori:
[
p; a; b; x; pd f ; an] = gammix2(ps empirica,0,1);
b = 1.4289
0.2542
a=
26.4270
195.1370
p=
0.4367
0.5633
peso delle 2 gamma
Il λ2 si dimezza raggiungendo il valore 0.1083. In figura 4.20 si riportano i grafici
per entrambi i modelli analitici proposti.
65
(a) Normmix2.m
(b) Gammix2.m
Figura 4.20: Wired 8pl - Fitting PS: Normmix2 e Gammix a confronto.
Tuttavia, l’utilizzo di gammix2 non consente di migliorare la qualità del fitting in
tutti gli altri scenari, pertanto, in fase di confronto si terrà conto del primo tentativo
anche se non particolarmente brillante.
4.2.4
Conclusioni sullo scenario wired a 8 giocatori
Nel complesso i client mostrano un comportamento simile allo scenario a 4 giocatori, anche se alcuni differiscono lievemente. La ricerca di invarianza nei vari scenari
che esamineremo impone l’utilizzo degli stessi modelli analitici per poter confrontare
agevolmente i risultati ottenuti. Infatti, sebbene il mix di due gamma raggiungesse
un fitting migliore per il PS, poiché ciò non avviene negli altri scenari, si è preferito
adottare il mix di due gaussiane.
66
4.3
LAN party: wireless 4 giocatori
Alla sessione di gioco partecipano solo gli studenti di Ingegneria. Il match dura circa
15 minuti e la traccia, denominata log2, mostra fasi alterne di gioco. Il contenuto del
report.txt redatto da Plab è riportato in figura 4.21.
command line: ./plab -r log2.dump -q h -d ./log2 udp and port 27015
Sat Nov 11 13:48:24 2006
Sat Nov 11 14:03:29 2006
Fri Dec 15 15:47:43 2006
Fri Dec 15 15:47:43 2006
packets read:
134206
mean throughput:
148 pkts/sec
packets discarded:
0
fragments:
0
0
0
0
0
0
Total Hosts found:
Src Hosts found:
Src Hosts timeout:
Dst Hosts found:
Dst Hosts timeout:
6
5
0
6
0
Figura 4.21: Report.txt dello scenario wireless a 4 giocatori
Se si osservano i grafici sul byterate riportati in figura 4.22 è possibile riscontrare
la presenza di entrambe le fasi di gioco. In particolare, i giocatori risultano tutti inattivi
verso la fine del match. Sebbene tale fase sia molto ridotta si procede comunque alla
caratterizzazione statistica del traffico generato dal client nella fase inattiva.
67
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.22: Wireless 4pl- traffico in uscita dai client: Byterate
4.3.1
In base a quanto riportato nel file report.txt la traccia è stata collezionata a partire dalle
ore 13:48:24 fino alle 14:03:29. Si è deciso di analizzare la porzione attiva compresa
tra le 13:50 e le 13:56 con il seguente comando:
./plab -r log2.dump -q h -d log2attiva -T 13:50-13:56 udp and port 27015
L’analisi ha prodotto per i parametri di interesse i seguenti risultati.
68
4.3.2
IPT
La figura 4.23 mostra il particolare andamento dell’IPT per ognuno dei client.
Figura 4.23: Wireless 4pl- Fase attiva: IPT distribuzioni empiriche
La distribuzione empirica che ne consegue contiene un numero molto ridotto di occorrenze lontane dal valore medio che tuttavia portano a un pessimo fitting. Si procede,
dunque, a eliminare tali occorrenze che rappresentano solo lo 0.8% del totale, probabilmenete dovute alle brevissime fasi di gioco in cui il giocatore muore e rinasce2 . Le
occorrenze prese in considerazione sono quelle contenute nell’intervallo 10-60ms, che
comprende il consueto picco compreso in 40-45ms.
Proprio la presenza di uno spike cosı̀ elevato fa sı̀ che con la maggior parte delle
distribuzioni non si riesca a raggiungere un buon livello di fitting. Il λ2 non scende mai
al di sotto dello 0.5, valori inaccettabili. Risultati soddisfacenti, vengono raggiunti
ancora una volta tramite la distribuzione Student’s T location-scale i cui parametri
calcolati da Dfittool sono riportati in tabella 4.5.
La bontà del fitting è certificata dal λ2 , calcolabile attraverso lo script lambda2 Ricordiamo che stiamo considerando esclusivamente una fase attiva della sessione di gioco, durante
la quale i giocatori tendono a rinascere immediatamente senza alcun tipo di pausa.
69
Parameter Estimate
Std. Err.
mu
41711.9
1.06077
sigma
147.19
1.31977
nu
0.902774
0.00783688
Tabella 4.5: Dfittool: Student’s T location-scale - Fitting IPT [Wireless 4pl Attiva]
square.m. Sarà necessario generare un elevato numero di campioni secondo il modello
analitico proposto tramite la funzione tlsrandom:
[widht bins]=scott(ipt empirica,1,1);
analitica = tlsrandom(41711.9, 147.196, 0.902774, 100000, 1);
x lambda; dev] = lambdasquare(ipt empirica,analitica,[1 1 1],bins,0,60000)
[ ;
lambda = 0.0989
Figura 4.24: Wireless 4pl - Fase attiva: Fitting IPT
Un ulteriore confronto tra il modello analitico e la distribuzione empirica è riportato in figura 4.24.
70
4.3.3
PS
La figura 4.25 mostra il particolare andamento del Packet Size per ognuno dei client.
Figura 4.25: Wireless 4pl - Fase attiva: PS distribuzioni empiriche
Ancora una volta per tutti i client i pacchetti non hanno mai dimensione superiore
ai 60byte. Inoltre, la forma ricorda un mix di due gaussiane che si conferma il modello analitico più simile alla distribuzione empirica frutto della media dei 4 giocatori.
Il fitting migliore si raggiunge, dunque, con due gaussiane i cui parametri vengono
restituiti da normmix2:
[p, m, s, x, pdf, an] = normmix2(ps, 0, 1);
s=
4.2281
3.4370
sigma
m=
35.6373
49.6172
mu
p=
0.3428
0.6572
Lo script restituisce anche centomila occorrenze secondo il modello analitico nel
vettore chiamato an. In tal modo è possibile lanciare direttamente lo script lambdasquare.m per stimare la bontà del fitting:
[x,lambda,dev] = lambdasquare(ps,ps an, [1 1 1 1 1], [10:2:100], 10, 100);
lambda = 0.1005
71
Nella figura 4.25 si è utilizzato un bin di un byte. Per dimostrare la bontà del fitting
realizzato è necessario, tuttavia, aumentare la larghezza dei settori. Infatti, la somiglianza delle curve con un mix di due gaussiane risulta evidente portando la grandezza
dei bin a due byte come testimonia la figura 4.26 in cui è riportata la sovrapposizione
della distribuzione analitica proposta e la curva frutto della media dei quattro giocatori.
Figura 4.26: Wireless 4pl - Fase attiva: Fitting PS
72
4.3.4
Fitting della fase inattiva
Quando furono realizzati gli esperimenti non si era previsto un comportamento cosı̀
differente del client tanto da poter individuare delle vere e proprie fasi di gioco diverse. Per questo motivo le fasi inattive non sono presenti in tutti gli scenari. Nel caso
wireless, verso la fine della sessione di gioco i ragazzi restano collegati al server anche
se per un breve periodo di tempo. Nonostante la durata ridotta si è proceduti ugualmente a modellare il traffico della fase inattiva con l’intento di riscontrare invarianza
anche in questa inaspettata modalità di comunicazione.
Dalla traccia è stato estrapolato il traffico generato per un minuto a partire dalle
13:59. Un solo minuto di traffico potrebbe essere considerato non sufficiente per una
modellazione statistica ma quello wireless è l’unico altro scenario in cui tale fase sia
presente. Riportiamo il comando Plab che ha permesso di isolare il traffico di interesse:
./plab -r log2.dump -q h -d ./wireless inattiva/ -T 13:59-14:00 udp and port 27015
Le successive analisi hanno portato ai seguenti risultati.
4.3.5
IPT
Riportiamo in figura 4.27 l’andamento sovrapposto delle distribuzioni empiriche per
ognuno dei client.
Anche nella fase inattiva, tutte le occorrenze dell’IPT sono concentrate nell’intervallo 40-45ms. Il filtraggio dei dati consente il raggiungimento di un fitting migliore.
Considerando solo le occorrenze contenute nell’intervallo 33-50ms, ovvero il 99.37%
del totale, il modello analitico più adatto ad approssimare i dati risulta ancora una volta la distribuzione Student’s T location-scale. I parametri restituiti da Dfittool sono
riportati in figura 4.6.
Lo script lambda-square.m ci permette di stimare la bontà del fitting:
ipt an = tlsrandom(41683.7, 81.3247, 0.95144, 100000,1);
width; bins]=scott(ipt inattiva filer,1,1);
[
x2; lambda; dev]=lambdasquare(ipt inattiva filer,ipt an,[1 1 1],bins,33000,50000);
[
lambda = 0.0702
Il responso conferma l’ottimo risultato documentato anche dalla figura 4.28.
73
Figura 4.27: Wireless 4pl - Fase inattiva: IPT distribuzioni empiriche
Parameter Estimate
Std. Err.
mu
41683.7
1.06145
sigma
81.3247
1.40453
nu
0.95144
0.0162937
Tabella 4.6: Dfittool: Student’s T location-scale - Fitting IPT [Wireless 4pl Inattiva]
Figura 4.28: Wireless 4pl - Fase inattiva: Fitting IPT
74
4.3.6
PS
La ridotta durata dell’osservazione ci impone cautela nell’interpretazione dei dati. Tuttavia, dall’andamento sovrapposto delle distribuzioni empiriche si evince il comportamento anomalo del giocatore Alessandro:
Figura 4.29: Wireless 4pl - Fase inattiva: PS distribuzioni empiriche
Se si osserva con attenzione la figura, si nota in effetti come tutti i client manifestino lo stesso andamento con l’eccezione di Alessandro la cui distribuzione è assolutamente simile alle altre ma risulta traslata di soli 2 byte. Le ragioni di tale comportamento possono essere molteplici, come ad esempio la lunghezza del nickname
del giocatore. La situazione che si viene a delineare è quella in cui Alessandro genera
delle occorrenze che gli altri non generano affatto, è l’unico, ad esempio, a generare pacchetti di 25byte. Prendere in considerazione anche queste occorrenze significa
allontanarsi dal giocatore tipo individuato da 3 partecipanti su 4. In realtà, in questo
caso, si potrebbe aumentare la grandezza del bin, tuttavia, si perderebbero dettagli come la mancata generazione di pacchetti di specifiche dimensioni (ad esempio, da tre
giocatori su quattro non vengono mai generati pacchetti di dimensioni pari a 28, 30,
75
32 e 34 byte). Si è deciso pertanto di trascurare le occorrenze generate da Alessandro:
27byte = 86.89% 29byte = 5.00%
33byte = 0.22%
31byte = 7.39%
35byte = 0.05%
Il λ2 corrispondente risulta inferiore a 10 4 . Ulteriori studi dovranno far luce sul
comportamento anomalo manifestato dal client Alessandro.
Figura 4.30: Wireless 4pl - Fase inattiva: Fitting PS
4.3.7
Conclusioni sullo scenario wireless a 4 giocatori
L’analisi del traffico generato in questo scenario evidenzia alcuni tratti già riscontrati
nello scenario wired. L’IPT resta concentrato in un intervallo ben preciso che va dai 40
ai 45ms indipendentemente dal livello di attività del giocatore. Il PS della fase attiva
non supera mai i 60 byte nella fase attiva, mentre assume pochi precisi valori nella fase
inattiva.
76
4.4
ADSL: 4 giocatori
Sulla base delle esperienze raccolte durante le operazioni di fitting negli scenari wireless e wired, procediamo adesso ad analizzare il comportamento dei client durante le
sessioni di gioco ADSL. Questo scenario è, per alcuni aspetti, il più interessante. Negli scenari LAN, infatti, non era possibile apprezzare gli effetti della rete sul traffico.
Con le connessione a banda larga, invece, è possibile confrontare il traffico generato
in uscita dai client con quello in ingresso al server. In particolare, tale confronto verrà
utilizzato per indagare un anomalia riscontrata nel comportamento di uno specifico
giocatore.
A tal proposito identifichiamo due sessioni di gioco:
1 Sessione: 4 tracce del traffico in uscita ai vari client collezionate tramite
Ethereal. La stessa sessione di gioco viene raccolta in ingresso al server tramite
Tcpdump.
2 Sessione: per timore di una possibile contaminazione dei time-stamp da parte
di Ethereal si evita che i client si facciano carico delle operazioni di sniffing.
Pertanto si è collezionata la sola traccia in ingresso al server.
Analizziamo singolarmente le due sessioni.
4.4.1
1 Sessione di gioco - Lato client
Per cominciare, si porrà l’attenzione sul traffico in uscita ai vari client collezionato
attraverso Ethereal dai giocatori stessi. Lanciando Plab su ognuna delle tracce, vengono generati i file che contengono il traffico generato dai 4 giocatori. Modificando
opportunamente lo script analisi.m in modo tale che analizzi il traffico a partire da file
diversi si è potuto constatare come non siano presenti fasi inattive. I grafici riportati in
figura 4.31 lo testimoniano.
77
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.31: 1 Sessione ADSL - traffico in uscita dai client: Byterate
Procediamo, dunque, ad analizzare l’unica fase presente.
4.4.2
L’andamento delle distribuzioni empiriche evidenzierà per i parametri di interesse
alcune anomalie che dovranno essere indagate separatamente.
4.4.3
IPT
La figura 4.32 riporta le distribuzioni empiriche sovrapposte. Roberto si discosta nettamente dagli altri giocatori manifestando un comportamento mai registrato prima in
nessun altro scenario:
78
Figura 4.32: 1 Sessione ADSL (client)- Fase attiva: IPT distribuzioni empiriche
Gli altri giocatori, tuttavia, presentano il solito comportamento, con picco intorno
ai 41.7ms. Prima di escludere dall’analisi il traffico generato da Roberto, si vogliono
fornire alcuni elementi di riflessione sulle origini di tale anomalia:
Il caso Roberto
In base a quanto riportato dalla figura 4.32 l’IPT di Roberto assume alcuni valori
ben precisi, con un picco a 4.2ms e altri picchi minori a valori che distano in media di
5ms. Un tale comportamento è difficile da spiegare. L’ipotesi più plausibile è che ci sia
un meccanismo secondo il quale il client genera traffico in base ai tempi e alla natura
delle informazioni provenienti dal server. In pratica, se riuscissimo a dimostrare che il
server nei confronti di Roberto si comporta diversamente, ovvero trasmette a intervalli
diversi, allora potremmo indagare più a fondo quello che potrebbe rappresentare un
vero e proprio protocollo di comunicazione utilizzato dal videogioco. Per appurare
tale evenienza iniziamo col confrontare il traffico che ricevono i client dal server.
Osservando la figura 4.33 è evidente la connotazione diversa del traffico che riceve
Roberto. Resta da capire se ciò è dovuto alla rete o se in partenza il server genera pacchetti verso questo giocatore a intervalli diversi rispetto agli altri partecipanti. Inoltre,
79
Figura 4.33: 1 Sessione ADSL (client)- Fase attiva: IPT in DownStream
in accordo a quanto sostenuto da altri ricercatori [4], tale anomalia potrebbe essere
legata alla posizione del pacchetto riservato a Roberto all’interno dei burst generati dal
server. Ovvero vi è la possibilità che tale pacchetto si trovi a volte in testa e a volte in
coda al burst.
Figura 4.34: 1 Sessione ADSL(server) - Fase attiva: IPT in UpStream
A questo punto non resta che analizzare il traffico che nella stessa sessione di gioco
ha generato in uscita il server. Purtroppo le ipotesi si dimostrano false, la figura
80
4.34 mostra come l’IPT dei pacchetti diretti ai client si distribuiscano per ognuno
dei giocatori nello stesso modo.
Il server genera pacchetti verso tutti a intervalli che in media durano 55.5ms. La
principale indiziata per l’anomalia diventa, dunque, la rete. L’ipotesi è che il client sia
effettivamente influenzato dai tempi e dalla natura delle informazioni che riceve dal
server ma è la rete in questo senso a giocare un ruolo decisivo. Roberto è un utente
dell’Internet Provider “Libero”, lo screenshot del traceroute che riportiamo in figura
4.35 mostra, in effetti, il percorso particolare che seguono i pacchetti nel raggiungere
il dipartimento.
Figura 4.35: 1 Sessione ADSL(client) - Tracerouter del giocatore Roberto
Addirittura vengono coinvolti alcuni nodi di Roma. Tale circostanza è però presente anche nei traceroute degli altri giocatori, alcuni dei quali manifestano latenze
anche superiori a Roberto. In conclusione risulta necessario un ulteriore studio che
miri a individuare un legame di tale anomalia o alla macchina del giocatore o a un
possibile malfunzionamento del sistema Ethereal-Interfaccia di rete o, più probabile,
all’influenza che esercita la rete sul traffico che riceve il client.
81
Parameter Estimate
Std. Err.
mu
41682.2
0.487575
sigma
71.3588
0.638334
nu
0.678717
0.00482119
Tabella 4.7: Dfittool: Student’s T location-scale - Fitting IPT [ADSL 1 Ses.(C) Attiva]
Si procede dunque ad analizzare il traffico trascurando quello generato da Roberto
che si discosta nettamente dal giocatore tipo.
Come già successo negli scenari wired e wireless, il miglior fitting si ottiene con la
distribuzione Student’s T location-scale. I relativi parametri restituiti da Dfittool sono
riportati in tabella 4.7.
Procediamo adesso a stimare il livello qualitativo del fitting che si sta realizzando:
[w,b]=scott(ipt menorob,1,1);
ipt an=tlsrandom(41682.2,71.3588,0.678717,1000000,1);
x1; lambda; dev1] = lambdasquare(ipt menorob,ipt an,[1 1 1],b,1,100000);
[
lambda =0.3478
Il risultato non è eccezionale ma può essere considerato, tuttavia, soddisfacente,
anche perché con tutti gli altri modelli analitici si ottengono risultati molto scarsi.
4.4.4
PS
La figura 4.39 mostra l’andamento sovrapposto delle distribuzioni associate al PS per
ognuno dei giocatori.
Il comportamento anomalo di Roberto non è riscontrabile in termini di PS in quanto l’andamento della distribuzione è quello consueto già riscontrato in altri scenari. Per
coerenza, verranno comunque escluse dall’analisi le occorrenze riconducili al giocatore Roberto. Il mix di due gaussiane è il modello analitico più adatto. Riportiamo di
seguito i risultati dell’analisi.
82
Figura 4.36: 1 Sessione ADSL(client)- Fase attiva: PS distribuzioni empiriche
[p, m, s, x, pdf, ps an] = normmix2(ps menorob,0,1)
s=
3.6835
3.8387
sigma
m=
34.7812
49.7303
mu
p=
0.3473
0.6527
x2; lambda; dev] = lambdasquare(ps menorob,ps an,[1 1 1 1 1],[20:2:100],20,100)
[
lambda = 0.0911
Un buon risultato documentato anche dalla figura 4.37
Figura 4.37: 1 Sessione ADSL(client) - Fase attiva: Fitting PS
83
4.4.5
1 Sessione di gioco - Lato server
Passiamo adesso ad analizzare la stessa sessione di gioco ma dal punto di vista del
server. In particolare, ci aspettiamo che l’IPT venga decisamente corrotto dalla rete.
La figura 4.38 mostra, infatti, come dal punto di vista del server i client generino
pacchetti a intervalli molto variabili.
Figura 4.38: 1 Sessione ADSL(server) - IPT distribuzioni empiriche
E’ evidente un aumento della dispersione. Per alcuni giocatori l’IPT medio è inferiore ai 41.7ms, il reale valore. La figura 4.39 mostra, invece, come il PS non sia
assolutamente influenzato dalla rete.
Figura 4.39: 1 Sessione ADSL(server) - PS distribuzioni empiriche
84
4.4.6
2 Sessione di gioco - Lato server
Analizziamo, adesso, la seconda sessione di gioco. Analisi.m ci permette, come di
consueto, di ottenere una visione preliminare del traffico che si sta analizzando. In
particolare, osservando i grafici sul byterate, è possibile constatare la mancanza della
fase inattiva anche se la traccia contiene sia l’inizializzazione che la terminazione della
sessione di gioco che dovranno essere opportunamente troncate.
(a) Luca
(b) Alessandro
(c) Biagio
(d) Roberto
Figura 4.40: 2 Sessione ADSL(server) - traffico in uscita dai client: Byterate
85
Parameter Estimate
Std. Err.
mu
40704.7
11.1753
sigma
1859.66
13.3364
nu
1.20853
0.010153
Tabella 4.8: Dfittool: Student’s T location-scale - Fitting IPT [ADSL 2 Ses.(S) Attiva]
4.4.7
IPT
La figura 4.41 mostra l’andamento sovrapposto delle distribuzioni empiriche dei vari
giocatori cosı̀ come sono percepite dal server.
Figura 4.41: 2 Sessione ADSL(server) - Fase attiva: IPT distribuzioni empiriche
E’ evidente l’influenza della rete: non è possibile individuare in questa figura quella nitidezza riscontrata negli scenari LAN. Procediamo, tuttavia, alla caratterizzazione
statistica sul giocatore tipo. Ancora una volta è la Student’s T location-scale la distribuzione che permette di raggiungere il miglior risultato. I parametri restituiti da
Dfittool sono riportati in tabella 4.8.
Ovviamente il fitting non è ottimo, proprio perché la rete ha un effetto diverso su
ognuno dei giocatori modificando la forma delle distribuzioni empiriche. Il giocatore
tipo, frutto della media dei 4 partecipanti, viene cosı̀ identificato da un distribuzione
86
dalla forma particolare difficilmente approssimabile con un modello analitico. Attraverso la Student’s T versione location-scale si riesce ad ottenere un λ2 pari a 0.45.
Tuttavia, nessun altro modello analitico permette di raggiungere risultati migliori. Si
veda la figura 4.42 che mostra il fitting realizzato.
Figura 4.42: 2 Sessione ADSL(server) - Fase attiva: Fitting IPT
4.4.8
PS
La rete, come già detto, non influenza la dimensione dei pacchetti. Dunque, almeno in
questo caso si attendono risultati simili a quelli degli altri scenari:
Figura 4.43: 2 Sessione ADSL(server) - Fase attiva: PS distribuzioni empiriche
87
Procedendo infatti con la caratterizzazione analitica risulta ancora una volta come modello analitico più adatto il mix di due gaussiane con i parametri restituiti da
normmix2.m:
[p, m, s, x, pdf, an] = normmix2(ps empirica,0,1);
s=
3.2181
3.4386
sigma
m=
34.2072
49.7467
mu
p=
0.3049
0.6951
Il λ2 corrispondente è pari a 0.22. La seguente figura permette di confrontare il
modello analitico candidato con la distribuzione empirica:
Figura 4.44: 2 Sessione ADSL(server) - Fase attiva: Fitting PS
4.4.9
Conclusione sullo scenario ADSL
L’analisi delle tracce raccolte in questo scenario ha permesso di evidenziare l’influenza
che la rete ha sul traffico che client e server ricevono. In particolare, gli effetti di tale
influenza si concretizzano non sulla dimensione dei pacchetti ma sull’IPT percepito
dai destinatari del traffico. La distribuzione associata a tale parametro subisce una
deformazione con un forte aumento della dispersione dei campioni, sorprendemente
però, dal punto di vista del server in entrambe le sessioni di gioco il client genera,
mediamente, pacchetti a intervalli di tempo più piccoli. Infatti, mentre il client immette
88
i pacchetti in rete in media ogni 41.7ms, il server li riceve in ingresso in media ogni
40ms. Tale comportamento va imputato ai meccanismi di bufferizzazione propri della
rete. In realtà, ci saremmo aspettati che la rete ritardasse in modo più o meno marcato
tutti i pacchetti, evenienza che a quanto pare non sempre si verifica.
89
4.5
Scenari a confronto
Riportiamo schematicamente i risultati delle operazioni di fitting per tutti gli scenari e
cerchiamo a partire da essi di trarre alcune riflessioni:
4.5.1
Fase Attiva
Le tabelle riportate di seguito schematizzano i risultati documentati in questo capitolo
sull’analisi del traffico generato durante la fase attiva di gioco. In tutti gli scenari la
distribuzione che ha prodotti i migliori risultati nel fitting dell’IPT della fase attiva si
è dimostrata la Student’s T location-scale. Per quanto cencerne il PS la distribuzione
statistica più adatta si è rilevata un mix di due gaussiane tranne nello scenario wired a
8 giocatori dove si sono ottenuti risultati migliori con un mix di due gamma. Tuttavia
per agevolare il confronto si farà riferimente sempre al mix di due gaussiane.
Inter-Departure-Time
Si faccia riferimento alla tabella 4.9.
Scenario
WIRED 4PL
WIRED 8 PL
WIRELESS
ADSL (1 Sessione - Client)
ADSL (1 Sessione - Server)
ADSL(2 Sessione - Server)
mu
41699.4
41679.3
41711.9
41682.2
40433.7
40704.7
sigma
104.821
51.8522
147.196
71.3588
1534.66
1859.66
nu
0.704073
0.821518
0.902774
0.678717
0.90124
1.20853
λ2
0.1897
0.0786
0.0989
0.3478
0.5305
0.45
Tabella 4.9: Fase attiva - Inter-Deparute-Time: Student’s T location scale (us)
Ulteriore spunto è fornito dalla sovrapposizione delle distribuzioni empiriche associate al giocatore tipo in ognuno degli scenari riportata in figura 4.45.
90
Figura 4.45: IPT - Distribuzioni empiriche in ogni scenario (Fase attiva)
La figura mostra come, in ogni scenario, le occorrenze si concentrino in un intervallo ben preciso, la maggiore dispersione delle distribuzioni negli scenari adsl lato server
è legata all’azione deformante della rete, pertanto tali distribuzioni non contribuiscono
a delineare il comportamento del client.
Packet-Size
Param.
mu
sigma
peso
mu
sigma
peso
Normal 1
Normal 2
λ2
Wired4PL Wired8PL
34,8352
33,4934
4,3915
1,5662
0,3732
0,2071
49,4904
48,0495
3,6186
4,5025
0,6268
0,7929
0,0842
0,24
Wireless
35,6373
4,2281
0,3428
49,6172
3,4370
0,6572
0,1005
1 Ses(C) 1 Ses(S)
34,7812 34,7793
3,6835
3,2215
0,3473
0,3137
49,7303 49,8279
3,8387
3,7687
0,6527
0,6863
0,0911
0,2480
2 Ses(S)
34,2072
3,2181
0,3049
49,7467
3,4386
0,6951
0,22
Tabella 4.10: Fase attiva - Packet Size: mix di due gaussiane (byte)
La figura 4.46 riporta le distribuzioni associate al giocatore tipo in ogni scenario.
E’ evidente come nessun pacchetto abbia dimensione superiore ai 60 byte, l’andamento inoltre è simile in ogni scenario e ricorda un mix di due gaussiane come del
resto confermano i risultati delle operazioni di fitting.
91
Figura 4.46: PS - Distribuzioni empiriche in ogni scenario (Fase Attiva)
4.5.2
Fase inattiva
Si riportano di seguito, in forma tabellare, i risultati dell’analisi sulle fasi inattive riscontrate nei soli scenari wired e wireless a 4 giocatori. Ancora una volta, a conferma
della stabilità riscontrata nel traffico, la distribuzione che approssima al meglio l’andamento dell’IPT è la Student’s T versione location-scale. Per quanto concerne il PS,
tuttavia, il parametro assume pochi precisi valori compresi tra i 25 e i 35byte. Pertanto
la distribuzione empirica può essere efficacemente approssimata con una distribuzione
discreta.
Inter-Departure-Time
Scenario
Wired 4pl
Wireless 4pl
mu
41685,8
41683,7
sigma
69,4393
81,3247
nu
1,08341
0,95144
λ2
0,1017
0,0702
Tabella 4.11: Fase inattiva - Inter-Deparute-Time: Student’s T location scale (us)
I valori medi collimano, differiscono lievemente le dispersioni intorno al valore
medio che risulta tuttavia in linea con i risultati ottenuti nel fitting delle fasi attive. La
92
figura 4.47 mostra graficamente il confronto tra le distribuzioni empiriche e conferma
la maggiore dispersione registrata nello scenario wireless.
Figura 4.47: IPT - Distribuzioni empiriche a confronto (Fase inattiva)
Packet-Size
La tabella 4.12 riassume i risultati a cui è giunta l’analisi del Packet-Size nelle fasi
inattive.
Packet Size Wired 4 pl
27
83.12%
28
0.18%
29
4.53%
30
1.95%
31
8.79%
32
0.24%
33
1.06%
35
0.13%
Wireless 4 pl
86.89%
5.0%
7.39%
0.22%
0.05%
Tabella 4.12: Fase inattiva - Packet Size: distribuzione discreta (byte)
Un confronto grafico è riportato in figura 4.48.
Notare come, sebbene nello scenario wired la distribuzione sia continua, nello scenario wireless vengono generati pacchetti solo di determinate dimensioni. Considerato
93
Figura 4.48: PS - Distribuzioni empiriche a confronto (Fase inattiva)
il numero ridotto dei valori in gioco si è deciso, dunque, di utilizzare una distribuzione
discreta per agevolare il confronto.
94
Capitolo 5
Conclusioni e Futuri Sviluppi
5.1
Conclusioni
A valle dell’analisi dei dati raccolti durante gli esperimenti è possibile trarre alcune
conclusioni. Seppur con piccole sfumature, risultano evidenti caratteristiche invarianti
nel traffico generato dal client di Counter-Strike. L’analisi, infatti, conferma quello che
la comunità scientifica aveva già acquisito: le applicazioni realtime a carattere ludico
generano pacchetti di dimensione notevolmente inferiore rispetto alle altre tipologie di
traffico e in alcuni casi ad intervalli regolari. Tale caratteristica è presente ed accentuata
nel client CS che genera, indipendentemente dallo scenario o dal livello di attività del
giocatore, in media un pacchetto di dimensioni non superiori ai 60byte ogni 41.7ms.
Tale livello di determinismo non è riscontrabile in altre tipologie di traffico.
L’analisi ha evidenziato due fasi diverse di gioco. Nella fase attiva il giocatore partecipa attivamente alla sessione, in quella inattiva è semplicemente collegato al server.
Il traffico generato dal client è influenzato dalla fase in cui versa il gioco ma solo in
termini di Packet Size. Infatti, mentre l’IPT resta sostanzialmente immutato, in media
41.7ms in accordo a quanto sostenuto da Faerber, i pacchetti assumono dimensioni
comprese in un intervallo continuo che va dai 25byte ai 60byte con un andamento che
ricorda due gaussiane nella fase attiva e assumono dimensioni in un insieme discreto
composto da pochi elementi, tra i 27 e i 35byte, nella fase inattiva. I nostri risultati,
dunque, confermano la teoria sostenuta da Feng in merito alla dimensione dei pac95
chetti che in tutti gli scenari e fasi non supera mai i 60 byte, diversamente da quanto
sostenuto da Faerber.
Una cosı̀ netta differenza di comportamento non era prevista sebbene studiosi come
Claypool avessero sottolineato la dipendenza del PS dall’azione di gioco. Per tale motivo gli esperimenti non sono stati realizzati in modo da collezionare in ogni scenario
una porzione di fase inattiva, presente in soli due casi: wireless e wired a 4 giocatori.
Tuttavia, il client assume un comportamento simile nei due scenari ricreati e non vi
sono elementi per ritenere che negli altri scenari possa assumere un comportamento
diverso.
Il risultato più importante del lavoro di tesi, tuttavia, è sicuramente la caratterizzazione e la modellazione statistica del traffico generato dal client in tutti gli scenari
e fasi. Le operazioni di fitting hanno evidenziato come l’unica distribuzione in grado
di approssimare efficacemente la distribuzione empirica dell’IPT in ogni scenario è la
Student’s T versione location-scale. Considerando la notevole regolarità del traffico,
infatti, la distribuzione empirica è caratterizzata da un picco notevole centrato intorno
ai 41.7ms e la Student’s T è l’unica in grado di assecondare tale andamento. Per quanto concerne il PS, la distribuzione empirica, nella fase attiva, manifesta un andamento
dolce e i campioni si concentrano in due punti diversi intorno ai 35 e 50byte. Qualsiasi tentativo di utilizzare un’unica distribuzione porta a pessimi risultati, pertanto il
modello analitico che si è rilevato più idoneo in tutti gli scenari è stato il mix di due
gaussiane. In un solo caso (LAN party wired a 8 giocatori) si sono ottenuti risultati migliori attraverso l’uso di due distribuzioni gamma. Nella fase inattiva, invece, il
client genera pacchetti di dimensioni che variano in un intervallo discreto composto da
pochi elementi. In tal caso l’approssimazione migliore si ottiene con una distribuzione
discreta.
In conclusione, la tesi conferma aspetti importanti relativi alla forte regolarità del
traffico generato e alla ridotta dimensione dei pacchetti prodotti dal client del videogioco on-line Counter-Strike. Si fornisce, inoltre, una caratterizzazione statistica di tale
traffico per ogni scenario di gioco e livello di attività del giocatore e vengono proposti
semplici modelli statistici, per il livello pacchetto, relativi all’andamento del traffico
generato.
96
5.2
Futuri sviluppi
I modelli statistici riportati in questa tesi potranno essere impiegati in future implementazioni in simulatori di rete e generatori di traffico sintetico, al fine di realizzare
analisi di performance realistiche e testare l’effettiva capacità delle infrastrutture di
rete nel supportare queste particolari applicazioni.
Relativamente allo studio delle proprietà statistiche del traffico di CS, rimane spazio per ulteriori approfondimenti. Potrebbe essere interessante, infatti, studiare le dipendenze mutue e temporali tra PS e IPT. Di notevole interesse, in aggiunta, è lo studio
dell’influenza che ha la rete sul traffico generato come già realizzato in parte nello scenario ADSL. Inoltre, in tale scenario si potrebbe testare il client in fase inattiva non
presente nelle tracce analizzate.
Ulteriori studi dovranno confermare quanto sostenuto da alcuni ricercatori[11],
cioè che Counter-Strike manifesta un comportamento caratteristico della maggior parte
dei videogiochi appartenenti al genere sparatutto. Nel caso in cui l’invarianza riscontrata dovesse essere presente anche in altri titoli, il passo successivo dovrebbe essere
uno studio approfondito su giochi appartenenti ad altri generi. L’ambizioso obiettivo è,
infatti, quello di individuare un insieme di elementi caratterizzanti il traffico generato
dai client di un applicazione realtime a carattere ludico indipendentemente dal genere
a cui essa appartiene. Sulla base di questi elementi potranno essere progettate efficienti
architetture di rete per il supporto di applicazioni di questo tipo.
97
Bibliografia
[1] S. McCreary K. Claffy. A view from ames internet exchange, 2000.
[2] N. Shah and C. Haigh. The video game industry, An Industry Analysis, from a
VC perspective. 2005.
[3] W. Feng, F. Chang, W. Feng, and J. Walp ole. Provisioning on-line games: a
traffic analysis of a busy Counter-Strike server. in Proc. of SIGCOMM Internet
Measurement Workshop, (Marseille, France, November 2002).
[4] N. Degrande, D. De Vleeschauwer, and R.E. Kooij. Modeling Ping Times in First
Person Shooter Games. May 2006.
[5] J. Faerber. Traffic Modelling for Fast Action Network Games. Multimedia Tools
and Applications, 23 (1). 31-46. .
[6] M. Claypool, D. LaPoint, , and J. Winslow. Network Analysis of Counterstrike and Starcraft. In Proceedings of the 22nd IEEE International Performance,
Computing, and Communications Conference (IPCCC), April 2003.
[7] P. Huang K.-T. Chen and C.-L. Lei. Game traffic analysis: An MMORPG perspective. Computer Networks. Article In Press, Computer Networks, 51(3),
2007.
[8] M. Claypool. The Effect of Latency on User Performance in Real-Time Strategy Games. Elsevier Computer Networks, Special Issue on Networking Issues in
Entertainment Computing, 49(1):52–70, Septemb er 2005. .
98
[9] T. Beigbeder, R. Coughlan, C. Lusher, J. Plunkett, E. Agu, and M. Claypool. The
Effects of Loss and Latency on User Performance in Unreal Tournament 2003.
In Proc. Workshop on Network and System Support for Games, pages 144–151,
Aug. 2004. .
[10] M. Borella, Source models of network game traffic, Computer Communications
23 (4) (2000) 403-410.
[11] W. Feng, F. Chang, W. Feng, and J. Walp ole. A Traffic Characterization of.
Popular On-line Games. IEEE/ACM Transactions on. Networking, 2005.
[12] J. Lakkakorpi, A. Heiner and J. Ruutu. Measurement and Characterization of
Internet Gaming Traffic. Research Seminar on Networking, Helsinki University
of Technology, Networking Laboratory, Espoo, Finland, February 2002.
[13] N. Sheldon, E. Girard, S. Borg, M. Clayp ool, and E. Agu. The Effect of Latency
on User Performance in Warcraft I I I. In Proc. Workshop on Network and System
Support for Games, May 2003.
[14] J. Kim, J. Choi, D. Chang, T. Kwon, Y. Choi, and E. Yuk. Traffic characteristics
of a massively multi-player online role playing game. In NetGames ’05: Proceedings of 4th ACM SIGCOMM workshop on Network and system support for
games, pages 1–8, New York, NY, USA, 2005. ACM Press.
[15] T. Lang, P. Branch, and G. Armitage. A synthetic traffic model for quake3. In
ACE ’04: Proceedings of the 2004 ACM SIGCHI International Conference on
Advances in computer entertainment technology, pages 233–238, New York, NY,
USA, 2004. ACM Press.
[16] J. Faerber. Network game traffic modelling. In NetGames ’02: Proceedings of
the 1st workshop on Network and system support for games, pages 53–57, New
York, NY, USA, 2002. ACM Press.
[17] T. Lang, G. Armitage, P. Branch, H-Y. Choo. A Synthetic Traffic Model for HalfLife. Australian Telecommunications, Networks and Applications Conference
(ATNAC), Melbourne, December 8-10, 2003.
99
[18] R. A. Bangun and E. Dutkiewicz. Modeling multi-player games traffic. In ITCC
’00: Proceedings of the The International Conference on Information Technology: Coding and Computing (ITCC’00), page 228, Washington, DC, USA, 2000.
IEEE Computer Society.
[19] R.A. Bangun, E. Dutkiewicz, G.J. Anido, An analysis of multi-player network
games traffic, in: Proceedings of the 1999 International Workshop on Multimedia
Signal Processing, Copenhagen, Denmark, 1999, pp. 3-8.
[20] Entertainment Software Association, Essential facts about the coumputer and
video game industry, 2006.
[21] GameSpy.com ’Top Game Servers By Players’, 2006 http:/www.gamespy.com.
[22] Counter-Strike, Counter-Strike: A Counter-Terrorism Half-Life Modification,
http://www. c o u n t e r - s t r i k e . n e t / .
[23] A. Dainotti, A. Pescape, and G. Ventre. A Packet-level Characterization of
Network Traffic. CAMAD06, 2006.
[24] A. Dainotti, A. Pescapè, Plab: a packet capture and analysis architecture,
Technical Report TR-DIS-122004, Dipartimento di Informatica e Sistemistica,
Università degli Studi di Napoli Federico II, December 2004, Italy.
[25] G. Gelli.
Probabilità e informazione: Manuale per il corso di Teoria dei
Fenomeni Aleatori. Napoli, quinta edition, 2002.
[26] Dipartimento
di
Informatica
e
Sistemistica.
Script
Matlab
-
http://www.grid.unina.it/Traffic/Tools/statools.php.
[27] D. W. Scott, “On Optimal and Data-Based Histograms”. Biometrika, Vol. 66, pp.
605-610, 1979.
[28] J.A. Bilmes, “A Gentle Tutorial of the EM Algorithm and its Application to Parameter Estimation for Gaussian Mixture and Hidden Markov Models”. Technical
Report, ICSI-TR-97-021, University of Berkeley, CA, 1998.
100
[29] S. Pederson, M. Johnson, “Estimating Model Discrepancy”. Technometrics,
32(3), pp. 305-314, Aug. 1990.
[30] Documentazione in linea di Matlab R2006b (7.3).
101

universit¬ degli studi di napoli federico analisi a livello pacchetto del

Transcript

Documenti analoghi

NetRisk

Istruzioni per l`accesso all`Offcampus con piattaforma LINUX

Gestione totale per 40 anni all`Aeroporto Internazionale di Napoli

Airport traffic report

Test di biomeccanica per gli azzurri alla Bernstein

I concetti logistici nel traffico urbano

COMUNICATO STAMPA