autore: Simone Artesino (0000 248678) simone.artesino@studio.unibo.it Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi Service Peer : un applicazione tollerante p2p per il framework uniboEnv-p2p autore: Simone Artesino (0000 248678) simone.artesino@studio.unibo.it Service Peer Simone Artesino Reti di Calcolatori LS

l'idea uniboEnv-p2p uniboEnv l'applicazione ServicePeer unboEnv -> Il framework uniboEnv è un MOM (Messagge Oriented Middleware) per l’ambiente JAVA. Nasce con l’intento di superare la semantica della chiamata a procedura e realizzata i concetti di chiamata asincrona, di comunicazione a scambio di messaggi,di scatenamento e ricezione di eventi, al fine di fornire un sistema di supporto all'eterogeneità e all'interoperabilità di più sistemi che comunicano tra loro attraverso uno scambio di messaggi. uniboEnv-p2p -> Il middleware UniboEnv-p2p realizza un mondo ibrido Server delle Tuple / peer to peer ServicePeer -> Service Peer, nasce come entità “peer to peer” in un mondo dove si offrono servizi di conversione l'applicazione l'estensione al mondo tuple-p2p il framework di partenza <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Servizio di Discovery : Il framework p2p Tuple (Tucson) / P2P (PGrid) semantica Messaggi UniboEnv SuperPeer & "località" Servizio di Discovery : Messaggi Un mittente deposita nel sistema un messaggio, etichettandolo e poi si disinteressa dello stesso. Il messaggio può permanere latente nel sistema per un tempo indefinito. CheckForMsg: cerciamo nello spazio delle tuple la template specifica per vedere se ci sta o meno. Usiamo rdp perchè nel caso non ci sia la tupla,l’operazione fallisce. sendMsg: creamo un messaggio con i parametri adeguati e lo inseriamo nello spazio delle tuple specifico attraverso “out”. ReceiveMsg: si cerca con “in” la tupla nello spazio delle tuple e si construisce il messaggio (IMessage) per restituirlo con i parametri che si sono cercati. public void offerForService(String serviceName,String remoteIP,String port) public InetSocketAddress askForService(String serviceName) UniboEnv-p2p <<Service Peer >> Simone Artesino Reti di Calcolatori LS

l'applicazione I idea Obiettivo : tolleranza ai guasti fase di discovery idea mondo dove si offrono servizi di conversione servizio come richiesta di elaborazione differita Obiettivo : tolleranza ai guasti fase di servizio <<Service Peer >> Simone Artesino Reti di Calcolatori LS

l'applicazione II Peer "Client" Peer "Server" <<launch>> ServiceName audioService -> mp3 to wav <<launch>> Peer "Server" local execution thread (ie lame.exe) <<capture>> Peer "Client" interaction configuration file <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Discovery Peer "Server" indirizzo del client Peer "Client" Nome del servizio, indirizzo del server <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Scelte tecnologiche TCP vs UDP vs Middleware Peer "Server" Peer "Client" Connessione diretta Client-Server Tipi di dato scambiati (dati-configurazione-stringhe) Obiettivo : tolleranza ai guasti scambio di file di grandi dimensioni TCP vs UDP vs Middleware - Per questa motivazione si è scartato l’utilizzo di un MOM, in quanto avrei dovuto leggere, codificare ed impacchettare file di grosse dimensioni per poi ricostruirli dall’altro lato dell’end-point. - Non è stata considerata la tecnologia RMI poiché non vi è la necessità di grosse interazioni, e neanche l’utilizzo di middleware più complessi, quali CORBA, per l’inutili costi di overhead che comportano. Non è stata utilizzata la tecnologia UDP poiché : Non da garanzie rispetto alla perdita di pacchetti Per la tipologia di applicazione, non siamo interessati allo scambio in di piccoli pacchetti e non siamo orientati all’utilizzo di stream , al contrario vi è la necessità di aver ricevuto interamente il dato e la configurazione prima di eseguire. L’overhead della costruzione del canale rispetto all’ invio “immediato” di semplici messaggi UDP viene a giustificarsi per la qualità di servizio offerta . Inoltre la relativa lentezza del protocollo TCP viene ad annullarsi nel caso di invio di file di grandi dimensioni, poiché nel caso di mittente e destinatario distanti (come che è possibile trovare nelle rete peer) mi assicura lo stesso instradamento per tutto il flusso di dati. <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Scelte per la Tolleranza SEND & RECEIVE OMISSION - GENERAL OMISSION - NETWORK FAILURE - NETWORK PARTITION Identificazione reciproci controllo TCP tcp è best effort ma può essere la base per costruire sistema tollerante Tolleranza nella fase di apertura della socket Tolleranza nella fase di invio-ricezione Replicazione a copie passive-Fredde da parte del peer”Client” <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Tolleranza nella fase di apertura della socket peer Process peer Process Peer "Client" Peer "Server" TCP connection tentative repeat times clientSocket.connect(serverAddress); ServerStub soket soket StubThread connection refuse Skeleton Thread Peer Control Peer Control ClientStub <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Tolleranza nell'invio-ricezione esito dell'invio data data* 3 Peer "Server" Peer "Client" config config* H H =? Si/No <message> <serviceName></serviceName> <opParams></opParams> <inputFilename></inputFilename> <outputFilename></outputFilename> <inputFileLenght></inputFileLenght> <payload>Client_Hash</payload> </message> 2 1 <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Copie Passive Fredde 2 1 3 4 Peer "Client" PeerControl creating new Stub & new ask for service 2 new Peer "Server" ClientStub ClientStub StubThread 1 Network-Server Faliure 3 getting configuration copy Peer "Server" StubThread 1 2 3 4 new connection <<Service Peer >> Simone Artesino Reti di Calcolatori LS

Testing I & II Scenario uno : Discovery statico (indirizzi specificati nel file di configurazione /config/ad.txt) Scenario due : Discovery dinamico supporto del framwork UniboEnv-p2p Testing dell'applicazione all'interno della stessa macchia (connessioni socket nella stessa località) Testing dell'applicazione fra macchine diverse (connessioni socket fra host differenti) Fallimento manuale l'utente termina il server durante le varie fasi di vita dell'applicazione : Fase di connessione delle socket Fase di invio-ricezione dei dati e della configurazione Fase di elaborazione del server Fallimento automatico Peer Server con stub (ServerErrorStub) che crea faliure con TCP <<Service Peer >> Simone Artesino Reti di Calcolatori LS

(focus) Testing Copie Passive Fredde socket address : 192.168.0.4 7500 Peer "Server" ServiceName audioService -> mp3 to wav configuration bd_small.mp3 configuration socket connect : socket address : 192.168.0.4 7500 bd_small.mp3 192.168.0.3 5688 Peer "Server" Peer "Client" socket connect : bd_small.wav 192.168.0.3 5688 <<Service Peer >> Simone Artesino Reti di Calcolatori LS