punto Punto Reliable peertopeer overlay network con capacit

punto. Punto Reliable peer-to-peer overlay network con capacità di NAT traversal Vincenzo Pacella matr. 0000197406

Obiettivi o Progettare una semplice overlay network peerto-peer n n o Decentralizzata Garanzie sulla consegna dei pacchetti trasmessi Capacità di attraversamento dei NAT Alta configurabilità Realizzare un prototipo funzionante, con i relativi strumenti di supporto

Scenario

Architettura di punto. Punto

Struttura del pacchetto o o Header di lunghezza fissa (56 byte) Tre tipi: n n n System Feedback Data Chunk

Packet Exchange Protocol o o Necessario garantire la ricezione dei messaggi spediti Messaggi organizzati in Message Pools n n Garbage collecting configurabile Resend policy configurabile Prima spedizione gestita da Pool. Manager (unico) Resending gestito individualmente per ogni Pool

Discovery/Heartbeat Protocol o In fase di bootstrap si caricano i descrittori n n o o Dal Rendezvous Server Dalla cache locale Gestione delle tabelle locali descrittori Alla ricezione di un messaggio di discovery ogni nodo invia il proprio descrittore in risposta Profondità del discovery configurabile I nodi confermati si scambiano continuamente messaggi di heartbeat

Routing o Routing table costruita a partire dalle informazioni estratte dai pacchetti ricevuti n n o Alla prima ricezione da un dato nodo Ogni volta che viene ricevuto un pacchetto da un dato nodo NAT Traversal implicito in molti casi

STUN o o Necessario identificare la tipologia di NAT tramite STUN n Full Cone n Restricted Cone n Port Restricted Cone n Symmetric Il Packet Exchange Protocol garantisce l’attraversamento implicito per alcuni tipi di NAT Presenza obbligatoria di un intermediario se i due endpoint si trovano dietro due NAT diversi (relaying) Non è obbligatorio/necessario utilizzare STUN

Rendezvous server o o o Server sviluppato in php/mysql Ogni nodo è dotato di un broker che traduce le richieste da/per http Operazioni: n n o Registrazione Rimozione Ricerca Download dei descriptors Tutte le richieste sono firmate da un hash calcolato con la chiave di sessione n n La chiave varia a ogni esecuzione Solo server e nodo conoscono la chiave

Conclusioni o o o Ottime possibilità di attraversamento di NAT L’invio e la ricezione di dati avviene in maniera del tutto trasparente rispetto all’architettura sottostante e alla dislocazione dei nodi L’architettura offre buone prestazioni per reti di modeste dimensioni Per reti di grandi dimensioni è necessario adottare tecniche di routing più effcaci, comunque implementabili in strati superiori E’ necessario ottimizzare l’uso della banda n n Tecniche di relaying più efficienti Analisi della Qo. S percepita e scelta dei migliori canali