08.09.2019 Views

Progettazione e Sviluppo di un Multiplayer Online Game su Reti Peer-to-Peer

Alma Mater Studiorum Universit`a degli Studi di Bologna Facolta` di Scienze Matematiche, Fisiche e Naturali Corso di Laurea in Scienze di Internet Tesi di Laurea in Laboratorio di Programmazione Internet

Alma Mater Studiorum Universit`a degli Studi di Bologna
Facolta` di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Scienze di Internet
Tesi di Laurea in Laboratorio di Programmazione Internet

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

22 CAPITOLO 2. ARCHITETTURA SOFTWARE<br />

e <strong>di</strong> “Link”. Un “Node” è sostanzialmente <strong>un</strong> endpoint <strong>di</strong> com<strong>un</strong>icazione,<br />

mentre <strong>un</strong> “Link” è <strong>un</strong>a rappresentazione del canale ci com<strong>un</strong>icazione tra<br />

due endpoints.<br />

In <strong>un</strong> contes<strong>to</strong> <strong>Peer</strong>-To-<strong>Peer</strong> forma<strong>to</strong> da N no<strong>di</strong>, significa che ogni “Node”<br />

possiede N-1 “Link”, <strong>un</strong>o per ogni nodo appartenente alla rete (escluso se<br />

stesso).<br />

Da <strong>un</strong> p<strong>un</strong><strong>to</strong> <strong>di</strong> vista più vicino all’implementazione vera e propria, sia il<br />

“Node” che il “Link” sono considerati “NetElement”, ovvero elementi identificabili<br />

tramite <strong>un</strong> “NetID”, costrui<strong>to</strong> in base all’in<strong>di</strong>rizzo IP e alla porta<br />

<strong>di</strong> ascol<strong>to</strong>.<br />

Quando si vuole connettere <strong>un</strong> nodo A ad <strong>un</strong> nodo B in ascol<strong>to</strong>, in A viene<br />

crea<strong>to</strong> <strong>un</strong> Link identifica<strong>to</strong> dal NetID <strong>di</strong> B. Quando B riceve la richiesta<br />

<strong>di</strong> connessione, può ricavare l’in<strong>di</strong>rizzo IP <strong>di</strong> A, ma non la porta <strong>su</strong>lla quale<br />

sta ascoltando.<br />

Inizia quin<strong>di</strong> <strong>un</strong>a fase <strong>di</strong> Handshaking, eseguita a livello applicazione, nella<br />

quale i due no<strong>di</strong> si scambiano i propri NetID, identificando gli at<strong>to</strong>ri e consolidando<br />

così la connessione.<br />

La fase <strong>di</strong> Handshaking inizia appena <strong>un</strong> nodo (A) riceve la connessione <strong>di</strong><br />

<strong>un</strong> secondo nodo (B).<br />

Il primo step vede A inviare il comando NET “HandShakeBegin” a B.<br />

Quando B riceve tale comando, risponderà inviando ad A il comando NET<br />

“HandShakeResponse” contenente il proprio NetID.<br />

L’ultimo step vede infine A confermare a B l’avvenu<strong>to</strong> riconoscimen<strong>to</strong> tramite<br />

il comando NET “HandShakeEnd”.<br />

Una volta terminata questa fase (Figura 2.1), entrambi i no<strong>di</strong> possono iniziare<br />

a scambiarsi i messaggi inoltrati dai rispettivi Layer <strong>su</strong>periori.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!