Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sistemi Distribuiti part 5: P2P systems: from simple to distributed P2P trust for DRM and health care record

428 views

Published on

P2P, DHT, distributed trust and certification information for DRM, P2P Health care record protection, AXMEDIS P2P, P2P for video streaming, DHT models, P2P for CDN, P2P and AXCP, monitoring P2P networks.

Published in: Technology
  • Be the first to comment

Sistemi Distribuiti part 5: P2P systems: from simple to distributed P2P trust for DRM and health care record

  1. 1. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 1Sistemi DistribuitiCorso di Laurea in IngegneriaProf. Paolo Nesi2013 Parte 5: Sistemi P2PDepartment of Information EngineeringUniversity of FlorenceVia S. Marta 3, 50139, Firenze, Italytel: +39-055-4796523, fax: +39-055-4796363Lab: DISIT, Sistemi Distribuiti e Tecnologie Internethttp://www.disit.dinfo.unifi.it/paolo.nesi@unifi.ithttp://www.dsi.unifi.it/~nesi
  2. 2. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 2Sistemi P2PO Aspetti Generali, ApplicazioniO Evoluzione StoricaO Motivazioni per il P2PO RequirementsO Architecture P2P e caratteristicheO Ricerche e download multisorgente, BTorrentO Reti P2P in OverlayO Controllo e supervisione reti P2PO Esempi: Skype, P2P per il B2B, basata su BTorrentO Esempi: P2PTV, P2P webTV, progressive Download ofaudio/visual contentO Esempio: monitoraggio reti P2P, P2P distributed trust
  3. 3. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 3O
  4. 4. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 4Coupling and Scalability
  5. 5. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 5The P2P World: Current StatusO first wave spreadsheet and word processorsO second wave Internet and Mosaic ….. Netscape, …IEO third wave Napster: over 60 million users AOL Instant Messaging: 100 million subscribers In search for “Killer Apps” for Networked ObjectsO forth wave P2P on real time applications: streaming, WEB TV, 3D streaming, P2P on mobilesO Fifth wave P2P on applications: games, chat, netmeeting, etc. P2P on security: DRM,
  6. 6. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 6Peer-To-Peer ComputingSource: Sun Microsystems, Project JXTA, 2001A network-based computing model for applications wherecomputers share resources via direct exchanges betweenthe participating computers
  7. 7. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 7Application areasO Content and Resource sharing Network-wide file/document sharing (napster, eDonkey, Gnutella,Freenet, piratebay, emule, etc.) VOIP: Voice Over IP P2P CDN: Content delivering network P2P VOD (Video on demand), P2PTV, WebTV also in STBO Distributed computation more GRID than P2P Internet-based (e.g. United devices, entropia) Intranet-based (www.datasynapse.com, NetBatch of Intel) Web testing (e.g., United devices) Esempio: gridella, etc…. Resource sharing: seti@home, aids@home, folding@home
  8. 8. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 8P2P Applications for file sharingO Napster, Gnutella, Freenet, KazaaO Emule, Emule Plus: both based on kademliaO Mojo NationO BitTorrent (Azureus client) BT based: PirateBay, Suprnova, isoHunt, TorrentSpyO Shareaza supports protocols like: Gnutella, Gnutella2, eDonkeyNetwork, BitTorrent, FTP and HTTP
  9. 9. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 9
  10. 10. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 10
  11. 11. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 11Definition of PeerO The peer is a node client of the P2P network Each client peer has many files Some in download and/or uploadsO The peer is a single thread, process of download and/orupload, such as in BitTorrent Terminology Each client node has many peers, typically no more than 5/10at the same time.O We can have a network that at a given time instant mayhave 4Mpeers, 1.2Mfiles and 890Kusers Some are seeders the other are passively reading only !
  12. 12. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 12O
  13. 13. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 13P2P Main requirementsO Creation of the P2P community of Peers/clients Discovering of the Peers/clients to reach the resourcesO THUS: Discovering resources/services Resources may be objects, files or disk space, or computational power, users, etc. Allocation of resources/objects into the P2P networkGlobal Unique ID, GUID for the objects Indexing of the resources into the P2P networkCustomization of query for getting informationO Managing updates in the information shared In the information requested only Removing obsolete files and/or referencesit is not always possible in P2P solutions in which it is tracked who hasdownloaded the file, or has the reference Notification of changes in the downloaded files, in the accessed resources, etc.Versioning, replacementNotification to all peers that have downloaded, please stop providing the lastversion.Again: also in this case the system has to keep trace of who has the file or thereference
  14. 14. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 14P2P Main requirementsO Interoperability between the applications (peer client) built byusing different P2P infrastructuresE.g.: JXTA and Microsoft P2PDifferent protocols: from low level to high levelDifferent information managementDifferent Routing modelsDifferent metadataDifferent certification and authentication of content Esistono anche client che fanno query su piu’ protocolli P2P La vera interoperabilita’ sarebbe poter postate un file in una reteP2P e vederlo nell’altra rete P2P indicizzato direttamenteClient the utilizzano piu’ protocolli fanno solo download da piu’canaliPartially true on BTorrent
  15. 15. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 15P2P Main requirementsO Scalability of the P2P solutionO From 1 peer/resource/user to Millions and Millions How is the capability in penetrating the network, Intranet to internet,Discovery, query, versioning, maintenance, etc.In intranet UTP can be usedIn Internet UTP CANNOT be usedPeers need to perform the boot of the P2P network in Internet Intrinsic limits of models,for example a limit on the code for unique ID for files, users, etc..How it may graw ? how is the costs of the model to grow in terms numbers of Peers??How many servers are needed ?Which networks capability, bandwidth, they need ?Which is the velocity that the graw may sustain ??
  16. 16. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 16P2P Main requirementsO Performance Analysis and control of the network connectionsBanda per esempio in termini di Mbps/Kbpsmassimo numero di connessioni apribili/attive in ingresso(download) ed uscita (upload)From the peer to a set of reference peers/servers Measuring CPU features:fixing % of free CPU reserved Space on the HD disk:space reserved, (maximum) space accessible, effectively freespace used in the shared files, etc.. Max Number of shared files, opened connections:reserved and maintained visible Time to download, time to start the downloadTime to perform the download, start-end time etc.
  17. 17. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 17Performance of P2P solutionsO Grafo dell’andamento delle prestazioni (download rate) in funzione del numerodei peer che hanno un certo file, misurato in un certo punto della rete.O L’obiettivo della distribuzione e’ arrivare a superare una certa soglia nel minortempo possibile. Il superamento della soglia di seeding mi garantisce delleprestazioni ragionevoli in termini di capacita’ di prestazioni per/gli l’utente/i epenetrazione della rete.O La saturazione e’ dovuta ai limiti di banda del clientQPerformanceQ Number of replicas on PeersQ idealeQ reale
  18. 18. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 18Velocity of Penetration/diffusion/seedingO Velocity by means of which a file becomes accessible (isseeded) in enough peers to guarantee a certain downloadrate in a certain area with a certain level of certaintyQRateofdownloadQ timeQ Andamento non noto ????Q Dipende dal comportamentodelle persone che scelgono ilcontenutoQ Si possono fare delle ipotesi
  19. 19. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 19Trend of Penetration in a given areaO In general non predicatable, depends on: the users’ interest and activities The content type and size The time, etc…Q TimeQ # Down,Q Vel of Down,Q # of replicas
  20. 20. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 20P2P Main requirementsO Assessment of peers,Assessment of user’s behaviour (single or cluster) For:organizing requests in a queue on the basis of past assessment andscoring of peersProviding better services to more virtuous peersRecognising bonus to more virtuous peers, if the P2P network iscreated for e-commerce Assessment for reputation and scoring of peer behaviourNumber of provided files, bandwidth, behaviour (leaving files) Assessment for repudiation of peersPerformance evaluation of peers, etc.Not enough: CPU power %, disk space, files to be downloaded,sockets open, Assessment of peers to exploit them as super-peers etc.
  21. 21. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 21P2P Main requirementsO Security and Trust of users Authentication of usersIdentification of the user in terms of name/surname, etc., or in termsof a simple UID, watermark• Knowledge of who has posted the file Privacy is typically preferred by P2P usersPrivacy vs Authentication of users and PeersO Security and Trust of Content Data/file/object certification: consistencyAuthentication lead to higher level of trustinessTrust of metadata and data, certification of content:per verificare/riconoscere la firma del content,garantire la consistenza fra metadati e dati Authorization to delivering and use contentControllo dei diritti, Digital rights managementgestione dei diritti/rights, licenze, etc.
  22. 22. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 22P2P Main requirementsO Security and Trust of Peer applicationsO To be sure that the Peer Client is working according to therules of the community In terms of respecting scoring, not presenting UserID of others, etc. See later the routing overlayO authentication and certification of peers devices Tool certification/fingerprint to know who is the tool owner and avoid toassign to him a score of another user. Certification that the Peer has not been manipulated to provide abehavior non conformant to the rules of the community/protocol
  23. 23. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 23P2P Main requirementsO Robustness, Fault tolerance Robustness with respect to eventual fault ofSingle peers• Interruption of downloads• Interruption of query/interrogation service• Interruption of instradation service (see Routing Overlay)SuperNodes that permit the indexing and/or the boot of the P2PcommunityNetwork problems, turn off/on of the peersO Definition of solutions for recovery from failure Recovering the interrupted download of file when it ismonolithic: total restartsegmented: restart of the segmentChoosing a different Peer from which the download can beperformed Duplication of resources (usage of strategies for duplication)
  24. 24. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 25P2P Technological ChallengesO Architecture Usable on different platformsJava has been the most selected Interoperability between the applications built on differentP2P infrastructures (diff. protocols, languages, etc.) Controllability of PeersMonitoring of user/peer behavior Performance, Scalability Fault tolerance Security: Privacy, Trust of content and of Peers
  25. 25. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 26P2P Technological ChallengesO Architecture Efficient in joining the network, discovery if needed Efficient setup of the P2P community Query/search of resourcesComplex queries: such as those based on SQL or RDF,based on semantics: title xx, author YY, ….Connection with local databases: ODBC, JDBC, etc. Deleting of filesRemoving from the network Changing of filesNotification of changes in the files posted/changed on thenetworkversioning QOS: Quality of Serviceperformance in querying and in the download for B2B and forB2C
  26. 26. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 28P2P Technological ChallengesO Development capabiliies Several Groups:DHT librariesJXTA librariesBTorrent librariesjava (JXTA), open source, …Microsoft P2P Tool Kit, …..Others are C++, etc.Many of them are open source projects at DISIT Lab, DSI, University of Florence:DIMOB P2PAXMEDIS P2P, derived from BTBamboo based DHT P2P
  27. 27. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 29O ArchitettureP2P
  28. 28. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 30Architetture P2PO Concentrate, centralizedO Distribuite, Distributed, decentralizedO Hierarchical or hybrid
  29. 29. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 31Centralized P2P ArchitecturesO Concentrated, centralized One server and N peers; in some cases, more servers Example: Napster (central index)O Also called “Server-based” which may support: Login, registration of peers to the central server Boot: performed asking to the server to get list of nodes Search: performed asking to the server Collection of data, index, query, etc.Table to know where the files (their replicas) and theirsegments are: obj45: n3, n4, n56, n78O Server Problems: fault, size, performance, cost...O Gli scambi dei file/risorse possono essere: Centralised or P2P, multisource
  30. 30. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 32NapsterO http://www.napster.com direct swapping MP3 music files over 50 million users by mid-2001
  31. 31. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 34Napster Pros and ProblemsO Veloce per l’entrata nella comunità tramite server centrale oserver locali ma sempre tramite serverO Anonimità degli utentiO Nessun controllo su dati coperti da IPR (intellectually propertyright) e questi venivano centralizzati (come indice) in modo nonautorizzato Questo problema e’ stato risolto nella versione attuale non moltodiffusa ed apprezzata, dalla massaO Sicurezza: Contenuti non certificati Utenti non autenticati Non accesso a database, query molto sempliciO Protocollo proprietario, filtrato da firewalO Scarsa scalabilità Costi elevati di gestione
  32. 32. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 35NapsterO Architettura centralizzata per la condivisione di fileO Query centralizzataO Copie dei contenuti centralizzate, in parteO Al crescere del numero degli utenti e’ necessarioaumentare le prestazioni e lo spazio disco del servercentrale che dai il servizioO Una o piu’ soluzioni: Fare un cluster di server Duplicare le risorse su piu’ serverO Aumento dei costi
  33. 33. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 36Napster: search files
  34. 34. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 37Napster: peer-to-peer file sharing with acentralized, replicated indexNapster serverIndex1. File location2. List of peersrequestoffering the filepeers3. File request4. File delivered5. Index updateNapster serverIndex
  35. 35. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 38Distributed P2P ArchitectureO Distribuited, decentralizedO Also called Pure P2P networks N peers, all identical Example: Gnutella (gnutella hosts), freenet Boot: massive discovery, highly complex/net-costs Search: fully distributed!, high complexity No problems of faultredundancy of information and services The most common problems:Low performance on search and discovery(distributed), etc.No administration, no certificationNo control on the network
  36. 36. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 39GnutellaO March 2000, Molto sempliceO Meccanismi di distribuzione e monitoraggio deifile in HTTPO Non vi sono meccanismi di sicurezzaNon e’ possibile autenticare gli utentiGli oggetti non sono certificatimetadati e contenuti possono non essereconsistentiO http://www.gnutelliums.comO www.gnutella.comO Several implementations of Gnutella clients For example: limewire,
  37. 37. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 40Gnutella: discovering peers12 3231.12.1 2.12.12.13.13.13.1
  38. 38. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 41Gnutella: searching (via routing)12 3232.1 2.13.13.13.1
  39. 39. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 42Hybrid P2P ArchitettureO Hierarchical, hybrid Mix of centralized and decentralized N peers not all identical (at least in the role)some with the role of local concentrator that can be activatedwhen needed, the so called “super peers” Example:Fast TrackEmule: with the servers for bootO Super peers facilitating the starting/booting of the peer network, recovering the list of closer peers May create a restricted community around which the content issharedmarginally connected with others communities
  40. 40. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 43Hierarchical/Hybrid P2P Network0List of peers 1s1 1 11 1List of peers 1sList of its peers 2s222222222 2222List of peers 2s +its 1 super2Q Boot facilitationQ Query instradation………Nodo centrale di bootSupernodi intermediNodi foglia, client, peers
  41. 41. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 44Main Functionalities of NodesO Nodo Centrale di Boot: NodeList GetList(): to provide list of supernodes level 1 AddNode(node): to add a supernode of level 1 to the list DelNode(node): to remove a supernode of level 1 to the list,performed by missing a ping for a while Bool Alive(): to verify if the node is aliveO Level 1 Node : NodeList GetList(): to provide list of supernodes level 2 Alive(), AddNode(node), DelNode(node), as above Result PassQuery(query): to pass a received query to lower levelnodes in its Node2List Result RedirectQuery(query): to pass a received query to nodes ofits level: Node1ListO Level 2 Node: are almost all notifications It does not receive any command from other nodes on the list Result Query(query): another node is making a query Data GetFileSegment(GUID): to get a file segment Alive(), etc.
  42. 42. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 45KaZaA exampleO It is a semicentralized P2P solutionO Super-peers maintain info/DB with: file identifiers, their children are sharing metadata (file name, size, contentHash, descriptors) IP addresses of childrenO peers frequently exchange list of super-peers Peer clients maintains list of 200 super-peers Super-Peers maintain a list of thousands of SPsO All of the signaling traffic between peers is encrypted Lists, Metadata upload, Queries and repliesO File transfer among nodes is not encryptedO TCP is used for both file transfer and other communications
  43. 43. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 46O Ricerche eDownloadmultisorgente
  44. 44. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 47Risposte delle QueryO A fronte di una queryO Risposta con file singoli monolitici: FileABC: N1, N34, N56, N58, N67 FileFGH: N5, N4, N75, N6, N88, N92, N60O Risposta con file a segmenti: FileABC: N1(1,3,4,56), N34(345,3,2,1), N56(4,56) FileFGH: N5(all), N4(3,5,7), N60(56,78,125) All means 100%O Where for Nx we intend: IP address, Port, position in the list, estimated time to wait, iconsider you a friend, location, bandwith, etc.
  45. 45. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 48Recombination of Query ResultsN4Q Nn invia la queryQ Nn deve ricombinare R1, 2, 3, 4Q i duplicati possono essere molti,etc.N4R4N1 N2 N3NnR3R2R1QQ Q QR1,2,3,4N1 N2 N3NnQ+R1QQ+R1,2Q+R1,2,3R1,2,3,4Q Nn invia la queryQ Ni riceve la query con i risultatidel nodo precedente e ne fal’unione con i propri, li passa alnodo successivoQ I duplicati vengono integrativia viaQ Nn non ricombina risultatiQ Carico distribuitoQ Soluzioni anche ibride
  46. 46. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 49Download MultisorgenteO File diviso in Parti di dimensioni ragionevoli per la rete, qualcheKbyte o decina di Kbyte: F1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10O Nodi hanno delle parti nella loro memoria cache: N1: 1, 3, 5, 7, 8 N2: 2, 4, 5, 7, 8, 10 N3: 5, 6, 2, 9 Etc..O Alcuni nodi possono anche averle tutte, cioe’ il file completoO Un nodo puo’ scaricare parti diverse da nodi diversi anche allostesso tempo sfruttando in questo modo un parallelismo P.es.: N3 puo scaricare 4 e 10 da N2, ed 3, 1, 8 da N1
  47. 47. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 50Download MultisorgenteO Politiche per scaricare le parti/file dai nodi: Il Nodo permette lo scarico in base ad una coda di richiesteIl nodo che chiede viene messo in coda, quando quelli primahanno avuto almeno una parte vengono messi in fondo allacodaIl nodo può salire nella coda se ha da dare delle parti anchelui all’altro nodo, per esempio Il Nodo ha una limitazionesul numero di scaricamenti contemporaneisulla banda sfruttata in uscita e/o ingresso Un Nodo può acquisire un credito (uno score/voto) in base al suocomportamento nel lasciare scaricare file o nel permettere inuscita una banda larga.In base a questo credito potrebbe/dovrebbe avere dellefacilitazioni/score in caso di richieste, per scalare delleposizioni nelle code, etc.
  48. 48. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 51bitTorrentO Programma di file sharing Principalmente P2P, ma con seme iniziale su semplicipagine WEB, .torrent file Open Source Soluzioni in vari linguaggi, C++, Java, etc.O prestazioni migliori per file di grosse dimensioniO L’ipotesi e’, come per la maggior parte dei sistemi i P2P: che quando uno ha un file anche intero/completo lo continuia condividere con gli altri e non lo tolga dalla directory checontiene i file visibili per gli altri
  49. 49. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 52bitTorrentO Idea: Un file .torrent contiene informazioni su come prendere le parti del file DATI,dove prenderlechi sono i nodi che hanno porzioni di quel file Il file DATI viene diviso in parti e queste in segmenti Il primo pezzo che viene scaricato e’ casuale, i successivi vengono scelti inmodo da dare precedenza al più raro, in modo che la sua rarità si attenui vistoche viene copiato su di un altro nodo.A ha 1,4,5,7,8, e metà di 3B ha 2,3,4,5, e metà di 6C ha 2,5,6,7 e metà di 8O Quando A finisce con la parte 3, richiede una nuova parte.O Il programma analizza lo stato generale e trova i pezzi 1 e 6 che sono ipiù rari.O Fra questi, A ha bisogno solo della parte 6, così A inizia a scaricare 6O poi passa agli altri segmenti
  50. 50. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 53Il tracker in bitTorrentO Quando si effettua una query, la risposta e’ una lista di filee per ognuno di questi un file .torrentO Il file .torrent contiene informazioni su chi ha i segmenti delfile, eventuali duplicazioni, etc.O Il nodo contatta gli altri peer e parte con lo scarico in basealla strategia vistaO Archivi/tracker diversi possono avere file .torrent diversi equesti possono o meno essere manutenuti aggiornati conle informazioni su chi ha il file in questioneO Un client può essere connesso a uno o più tracker per laricerca dei file .torrent
  51. 51. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 54Azureus: Monitoraggio dello stato
  52. 52. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 55Azureus: Andamento del download/upload
  53. 53. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 56Azureus: Mappa delle parti
  54. 54. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 57BitTorrent TerminologyO Choked: a peer to whom the client refuses to send filepieces.O interested a downloader who wishes to obtain pieces of afile the client has.O leech a peer who has a negative effect on the swarm byhaving a very poor share ratio - in other words,downloading much more than they upload.O peer one instance of a BitTorrent client running on acomputer on the Internet to which other clients connectand transfer data.O seeder a peer that has a complete copy of the torrent andstill offers it for upload.O Nodes of the BT are the peers and seeders
  55. 55. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 58BitTorrent TerminologyO superseed When a file is new, much time can be wastedbecause the seeding client might send the same filepiece to many different peers, other pieces have not yetbeen downloaded at all. Some clients, like ABC, Azureus, BitTornado,TorrentStorm, and µTorrent have a "superseed" mode, they try to only send out pieces that have never been sentout before, making the initial propagation of the file muchfaster.O swarm all peers (including seeders) sharing a torrent arecalled a swarm. For example, six ordinary peers and two seeders make aswarm of eight.
  56. 56. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 59O Reti P2PO OverlayO DHT
  57. 57. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 60Rounting OverlayO Soddisfare tutti i requisiti precedenti e’ molto complessoO RO garantisce che ogni nodo può accedere ad ognioggetto instradando la richiesta al fine di far raggiungereil nodo dove si trova la risorsa/info (tramite una sequenzadi nodi) L’oggetto può essere spostato in altri nodi senzacoinvolgimento degli utenti Si crea una catena di riferimenti Usato in molti casi, vedasi: Skype, P2PTV, etc.O Sistemi P2P usualmente replicano la risorsa In questo caso, l’algoritmo di RO deve tenere conto di dovesono le repliche e può facilitare la consegna fornendo afronte delle richieste/query il nodo più vicino
  58. 58. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 61Distribution of information ina routing overlayQ Object:Q Node:Q DQ C’s routing knowledgeQ D’s routing knowledgeQ A’s routing knowledgeQ B’s routing knowledgeQ CQ AQ B
  59. 59. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 62Rounting OverlayO Le richieste possono essere effettuate tramite un GUID(global unified ID) La richiesta fatta al RO produce in risposta il/un nodo che ha larisorsa/info.O L’algoritmo di RO deve anche: Pubblicare/Rendere-noto a tutti i nodi le eventuali nuovepubblicazioni di GUID PRO: Poter cancellare da tutti i nodi gli oggetti e pertanto la loroGUID che e’ stata rimossa PRO: Rendere aggiornati i nuovi nodi con la lista dei GUIDdandogli alcune delle responsabilita’, la gestione del segmento diconoscenza che loro rappresentano CONTRO: Al momento in cui un nodo lascia la rete deveridistribuire le responsabilita’/(la conoscenza) ai nodi cherimangono. In modo da non creare delle falle.
  60. 60. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 63Al momento in cui un nodo lascia deve ridistribuirele responsabilità/(la conoscenza) ai nodi cherimangono. In modo da non creare delle falle.Se A va via, gli oggetti X devono essere presi incarico da B o da altri, altrimenti vengono persi.Q Object:Q Node:Q DQ C’s routing knowledgeQ D’s routing knowledgeQ A’s routing knowledgeQ B’s routing knowledgeQ CQ AQ B
  61. 61. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 64GUID and DHTO GUID puo’ esserecalcolato tramite: HASH function delle infoO Pertanto il problema e’simile ad avere unatabella Hash distribuita:Distributed Hash Table,DHT.O Si veda a destra unasemplificazioneQ N1Q N2Q N3Q N4Q N5OggettoRiferimento
  62. 62. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 65Routing Overlay e replicheO un algoritmo random decide dovemettere l’oggetto e le sue replichein modo da assicurare la loroaccessibilita’O Il numero di repliche puo’ esserevariabile. Se l’alg. Randomidentifica ancora lo stesso nododeve essere ricalcolata un nuovaposizioneO La posizione dipende dal valore diGUID dell’oggettoO Un oggetto con GUID x (e.g., 5)viene posto in nodi che hannoGUID prossimi/vicini in modo damassimizzare la probabilità ditrovarlo in fase di ricerca.Q N1Q N2Q N3Q N4Q N5PubblicaRepliche
  63. 63. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 66Basic programming interface for a distributedhash table (DHT) as implemented by thePAST API over Pastryput(GUID, data)The data is stored in replicas at all nodes responsible for theobject identified by GUID.remove(GUID)Deletes all references to GUID and the associated data.Solo accedendo a quelli che coprono tale conoscenza.Pertanto se vi sono delle repliche prodotte da utenti, possonoessere o meno cancellate se non si operano particolariaccorgimenti. Comunque non sono piu’ recuperabili da altreoperazioni di GET pertanto la rete non le considera piu’value = get(GUID)The data associated with GUID is retrieved from one of thenodes responsible for it. Quelli che coprono quella conocenza
  64. 64. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 67Pastry (esempio preso da Cardellini) (3 bit per ogni cifra)
  65. 65. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 68Distributed Object Location and RoutingO DOLR: e’ un modello di RO leggermente miglioratoO Idea di base: Gli oggetti sono disposti dove si vuole, sono i riferimenti chevengono disposti sulla base del GUID DOLR ha il compito di definire un mapping fra gli indirizzi dei nodiche contengono repliche e gli oggetti (con i loro GUID) Gli oggetti sono memorizzati con lo stesso GUID in nodi diversi,questi sono repliche RO ha la responsabilità di instradare le richieste verso il nodo piùvicino al richiedenteO Posizione degli oggetti: Le repliche sono poste senza considerare la vicinanza del valoredi GUID secondo delle politiche: e.g., random Ogni replica deve essere notificata al DOLR tramite Publish()
  66. 66. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 69Basic programming interface for distributed object locationand routing (DOLR) as implemented by Tapestry• publish(GUID)•GUID can be computed from the object (or some part of it,e.g. its name). This function makes the node performing apublish operation the host for the object corresponding toGUID.• unpublish(GUID)•Makes the object corresponding to GUID inaccessible.• sendToObj(msg, GUID, [n])•Following the object-oriented paradigm, an invocationmessage is sent to an object in order to access it. This might bea request to open a TCP connection for data transfer or to returna message containing all or part of the object’s state. The finaloptional parameter [n], if present, requests the delivery of thesame message to n replicas of the object.
  67. 67. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 70Cambiamenti sui fileO Se un certo oggetto e’ statocambiato/cancellato Notifcation to who:has performed the download for thatobject in the past oris managing replica for that objecthas references for that object The object has to be reloaded, replicatedagain, substituting the old one, not verynice privacy problemsO If the object is not replicated the change is immediateWho has downloaded has to beinformed as well replicated:Make a query to know where theobject is replicatedremoving/deleting the old versionsPut/publish the new oneQ N1Q N2Q N3Q N4Q N5OggettoRiferimentoCambia/cancella
  68. 68. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 71Come instradareO Pastry e Tapestry usano il Prefix Routing per determinareil percorso per l’instradamento per la consegna deimessaggi/pacchetti/richieste indirizzate ad un certo GUID.O Idea di base: Modelli basati sulla disposizione dei nodi in base ad unagerarchia come per esempio in routing IP packets:ogni byte identifica 256 possibili figli, ogni figlio 256 figli,etc.. IP4 has 4 livelli.Segmento il GUID in livelli, etc. Praticamente dei meccanismi che permettono di definiredelle distanze massime fra nodi
  69. 69. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 72Criteri per la stima della distanzaO CHORD come distanza usa la differenza fra il GUID del nodopresente e di quello che si cerca. Distanza in un modello Hash uniforme Nodi geograficamente distanti potrebbero trovarsi vicini nellospazio della tabella, questo non e’ positivo per ottimizzare i tempidi comunicazione visto che nodi vicini si devono parlare spesso Si basa su un match esatto della stringa di ricerca
  70. 70. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 73Criteri per la stima della distanzaO CAN: usa una distanza d-dimensionale nell’iperspaziodelle possibili posizioni dei nodi Dimensioni per esempio possono essere: IP (geografico),location (nationality), language, fuso orario, codice postale,hash, etc.O Kademlia: usa lo XOR sulla coppia di GUID comedistanza fra i nodi Anche questo puo’ evere i problemi che si hanno perCHORD.
  71. 71. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 74GUID storingO GUID non hanno senso per gli umani sono semplicicodici binari/esadecimali/ottali “lunghi”, non hanno unsignificato diretto alla loro letturaO GUID puo’ essere calcolato sulla base dei dati checompongono l’oggetto e/o le informazioni del nodo, peresempio sulla base delle keyword che lo descrivono, ilfile name, etc.O potrebbero essere anche ottenuti tramite lo standardUUID che pero’ produce un valore assoluto nonricostruibile dai dati dell’oggetto e dovrebbe essere datoda un ente superparte, che oltre che generare l’IDverifica di non avere dei duplicati
  72. 72. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 75Skype P2P architectureO Skype is a P2P application for VOIP, Voice Over IPO Skype has a proprietary protocol, the P2P is similar to KaZaA AES 256 is used to protect the channelO There are three types of nodes in the P2P network: Ordinary-peers (OP, the client), Super-peers, Central loginserver The boot of OP is performed on a Super Peer (SP), and askto the Central server to perform the authenticationO For user search OP send the user name to SP which provide 4 IP addresses,if it is not there, with another request to SP obtain 8 peers,etc…
  73. 73. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 76Some info on SkypeO Skype usa il P2P per implementare la directorydistribuita degli utenti DHT – Chord algorithm Costo della ricerca: O(log N)O For user search OP send the user name to SP which provide 4 IPaddresses, if it is not there, with another requestto Sp obtain 8 peers, etc…
  74. 74. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 77O Controllo esupervisionereti P2P
  75. 75. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 78GUID e indirizzi dei peerO Indirizzi logici e fisici dei peer Internet Service Provider danno in modo dinamico degli indirizzi su baseDHCP, sempre in un certo range, ma diversiperdita di validità dei link, dei riferimenti ai file, etc…L’ID del nodo dovrebbe essere effettuato su una base diversa. I Firewall di struttura offrono verso l’esterno un unico indirizzo per tutti inodi che ci stanno dietroSi possono usare protocolli che espongono anche l’indirizzo realeinterno del nodo nella intranet, ma devono essere tenuti tutti e due,tutte le intranet usano lo stesso range. Intranet e DHCP (ISP o firewall)Possono dare indirizzi a rotazione periodica (alcune universita’)altre hanno la reservation su base del MAC address pertanto vegonosempre assegnati gli stessi con elevata prob. Il MAC address sarebbe un migliore identificativo ma molti calcolatori nehanno diversi…diverse schede di rete. In alternativa, un fingerprint delcalcolatore potrebbe aiutare a fare del riconoscimento
  76. 76. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 79Controllo e supervisione della rete P2PO Sulla rete passano molteinformazioni Alcune sono sensibili per IPR Altre potrebbero esserlo per lasicurezza nazionale, per ilpenaleO Eventuali monitoraggi, consniffer Controllo intorno al nodo che riceve Controllo intorno al nodo chetrasmette Controllo sul provider e leve legali
  77. 77. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 80Controllo e supervisione della rete P2PO Per evitare di essere troppovisibili come nodo providerO Soluzione di instradamento: Instradamento del file tramitenodi intermedi terzi Se i nodi intermedi non fannocaching, il controllo intorno alnodo che trasmette e’ ancorapossibile visto che il trafficoesce comunque da quello Instradamento di uno stessofile tramite nodi diversi
  78. 78. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 81Controllo e supervisione della rete P2PO Per evitare di poter essere controllati sulla rete Soluzioni che utilizzano canali protetti, proteggono solo iltraffico ma non il monitoraggio dei volumi Soluzioni che utilizzano la rete P2P come un databasevirtualeDivisione del file in segmenti spread sui nodi, anche informa criptata….Segmenti dello stesso file finiscono in nodi diversianche lontaniPerdita di controllo della porzione dell’HD, l’utente nonconosce cosa contiene, problemi di sicurezza visto chepotrebbe essere sfruttato per azioni non legaliControlli non facilmente realizzabili
  79. 79. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 82O Esempi disoluzioni
  80. 80. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 83Vediamo alcuni esempiO Bit TorrentO P2P AXMEDIS del DISIT, basato suBitTorrent, palestra per le valutazioni e nuovimodelli.O Monitoraggio di sistemi P2PO P2P per video streamingO P2P per distributed trust
  81. 81. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 84OO Questa e’ la seconda parte,la prima parte e’ stata presentata in precedenzanel contesto del download multisorgente
  82. 82. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 85BitTorrent based solutionsO When a file is published by a peer (initial seeding) a file (.torrent) is createdand sent to a reference TrackerO A peer can start the download having the BitTorrent file (can be obtained:from the tracker knowing the ID, via email, from HTML pages, ftp, MMS, etc. )O The Tracker periodically updates the list of peers involved in hosting the fileand notify them about the other active peersO Tracker has the list of objects, the catalogue, and the metadata are limited,e.g., to the file name
  83. 83. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 86Time of Seeding of a given objectin a given pointV [Bps]tSoglia oltre la quale siha una V accettabileTseedTo
  84. 84. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 87O no capabilities to provide support for querying/indexing of content on the basis of the metadata andrelated object/file cataloguing and querying for B2B and/or C2C(Consumer to Consumer).The querying/indexing is delegated to external services,the content type is not uniform so that the classification is hardand almost impossiblethe Tracker has only capabilities of presenting the list ofobjects, the called catalogue and the metadata are limited tothe file name; content protection and DRM, to control the publicationdistribution and sharing of non certified/protected/authorizedcontentBitTorrent limitations
  85. 85. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 88O no network control for removal of content/files from the network, that would means toremove them at least from the tracker; fast notification of new files (changed files) and thus of seeding offiles among the network; publishing and downloading files in an automatic manner, via theintegration of the P2P network facilities with the content productionfacilities; monitoring activities and user behavior on nodes.In addition to the classical P2P network monitoring that canbe performed on the tracker in a limited mannerBitTorrent limitations
  86. 86. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 89OO
  87. 87. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 90P2P Network of AXMEDISO Requirements P2P for B2B content distribution and sharingO BitTorrent Technical RequirementsO Fast content downloadO Additional Technical requirements: Support to make query, similarly to other BT servers Immediate/fast high performancesFast seeding for a number of given objects Control of the networkDelete/change the objects/content Certified metadata Secure in terms of IPR and DRM Automated control
  88. 88. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 91Content Sharing among Content ArchivesContent ProviderContent ProviderContent IntegratorArchive AArchive BLibrary CMediateque CArchive ZWireless LANInternet DistributorMobile Distributor
  89. 89. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 92P2P Network of AXMEDIS, req.O Automated Control of P2P Network: Sharing and publishing of content Control of the P2P network avoiding thedistribution of non certified/authorized content (e.g., content withmetadata inconsistent with resources),sharing of illegal files (those that are shared without thecorresponding authorizations of the content owner),access to P2P B2B facilities to non authorized (or malicious)actors/users, that is registering the users; monitoring the activities of the P2P network (tools and users) in termsofPerformances: ?download rate for a given file in a given area,content shared: when, where and by whoQueries on Query Server: log of performed queriesstatistical information that may be used to better tune the service andunderstand the user behavior;Status of the control nodes: workload, cpu, disk, etc.
  90. 90. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 93P2P Network of AXMEDIS, req.O Automated Control of P2P Network: querying on content on the basis of a large set of metadata,including those to make search and queries onbusiness/trading aspects: complex metadata, licensing rulesand conditions, costs, etc.; set up of high quality services of content distribution andsharing, CDN (Content Delivering Network).This implies to guarantee the content download according topredictable performance, QOS (Quality Of Service); evenwhena new content object/file is shared, thus when the P2Pnetwork may not contains enough replicas;faults occur in the network and/or in the nodes;
  91. 91. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 94AXMEDIS P2P solutionO Satisfaction of all the above mentioned requirements forB2B P2P networksO Extension of the BitTorrent solution Usage of the AXOID as unique identificationFrom AXOID to hash Insertion of a classification and query support Insertion of DRM support (only to protect digital files) Insertion of control nodes for publication and monitoringO Addition of: P2P client tools for B2B: AXEPTool tool P2P client tools for Consumers, B2C and C2C: AXMEDIA tool Server for classification and query: AXMEDIS Query Support Server for DRM: AXMEDIS DRM GRID solution for P2P Network control, AXCP based etc.
  92. 92. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 95AXEPTool P2PAXEPToolAXEPToolAXEPToolAXMEDIA P2PAXEPToolAXMEDIS P2P NetworkDownloadQuery SupportMetadata AXTrackerAXCP P2P ControlAXMEDIS DRMDistributorDistributorAXCP P2P ControlAXMEDIS P2P network architecture
  93. 93. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 96P2P Network of AXMEDISO Tracker: AXTracker is a modified BitTorrent Tracker thatmanages the AXMEDIS P2P network and communityO Supernodes: AXEPTool is a special P2P BitTorrent ClientNode, suitable to play the role of a P2P Node for B2B activitiessuch as producers, distributors, integrators, etc., for B2Bcontent distribution.O P2P clients: AXMEDIA is a specific P2P BitTorrent ClientNode for final users content sharing and B2C (Business toConsumer) content distribution.O Control: AXCP GRID is an instance of the AXCP GRID tool tocontrol the activites of some AXEPToolsO Query Server: AXQuery Support is a server on which theuser and the AXCP may perform queries
  94. 94. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 97AXMEDIS P2P NetworkO different kinds of P2P Nodes: content production, publications and sharing nodes inwhich a controlling tool (e.g., AXCP GRID) and atleast one AXEPTool are joined; content sharing and distribution nodes which areconstituted by an AXEPTool only (controlled andsupervised by other AXCP GRID nodes); AXMEDIA P2P nodes for content sharing.
  95. 95. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 98AXP2P Tuning the service, req.O Monitoring the network by means of the a uniformdistribution of supernodes allows to measure the: The velocity of download for each content for hours of the dayalong the time of service This may be used to change the distribution of replicas onsupernodes so that to work in the guaranteed area since ToV [Bps]tSoglia oltre la quale si hauna V accettabileTseedTo
  96. 96. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 99P2P Network of AXMEDISO Exploitation of BitTorrent Hierarchical BitTorrent solution, super-peersO In addition technical support to: MPEG-21 files and normal filesCertification of objectsCentralized query support for search of MPEG-21 files Control of P2P network via one or more control servers, that maybe grid or not. perform measures on the Tracker control the P2P status
  97. 97. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 100AXMEDIS P2P network: BenefitsO Fast seeding of the P2P network Asking to superpeers to start downloading of new objects Immediate notification of new objectsO Guaranteed quality of service With the deterministic number of superpeers and the possibility ofknowing their networking capabilitiesO Possibility of deleting object from the network Delete of objects on superpeers via GRID Delete of objects on the Tracker (to be done)O Possibility of having multiple GRIDs controlling the network forpublication of objectsO Performance control: Control of tracker performance Control of superpeer performance, in terms of networking, seeding,space on disk, etc. Definition of policies of LRU on the network, optimization of contentlocation
  98. 98. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 101Use Cases per AXEPTool
  99. 99. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 102AXTrackerAXQuery SupportMetadataAXCP GRID WS P2P MonitoringWS File SharingWS DownloadingPublishing InterfaceDownloading InterfacebitTorrent P2P client coreP2P AXEPToolOther AXEPToolsand AXMEDIA toolsQuery Service InterfaceAXEPTool P2P clientDerivato da Azureus/Vuze
  100. 100. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 103AXEPTool, P2P BT client, downloading
  101. 101. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 104AXMEDIS P2P Query Support
  102. 102. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 105AXTracker Catalogue
  103. 103. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 106Example of AXEPTool monitoring
  104. 104. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 107P2P Network control functionalitiesO publishing(AXEPToolURL, FileURI, AXTrackerURL)O download(AXEPToolURL, FileName or AXOID orBitTorrentURL)O listContent listPublished(AXEPToolURL)O listContent listDownloaded(AXEPToolURL)O infoStatus status(AXEPToolURL, FileName or AXOID)O controlDownload(AXEPToolURL, FileName or AXOID)O listAXOID query(AXQuerySupportURL, Query)O listContent catalogue(AXTrackerURL)O delete(AXEPToolURL, FileName or AXOID)O FileURI get(AXOID or FileName)O listAXEPTool listAXEPTool(AXTrackerURL)O infoNode statusNode(AXEPToolURL)O infoTracker statusTracker(AXTrackerURL, period)
  105. 105. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 108P2P ExperimentsO Publishing an object on all the AXEPTools of the P2P Networkfor example to accelerate the seeding of a given object on thenetwork: Axoid=getAXOID(MyFile); publishing(MyAXEPTool, MyFile, TheAXTracker); LA = listAXEPTool(TheAXTracker); For each la of LA: download(la, Axoid);00,511,522,533,541 2 3 4 5 6 7Q Minuti perXXX MbytesDim (LA)Q Raggiunta la saturazione del download rate
  106. 106. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 109Programming P2P ExperimentsO Notifying the publication of new objects/files in the network among thedifferent AXCP GRIDs/AXEPTools controlled;O Removing/deleting of objects/files from the network, at least from theAXEPTool nodes and from the AXTrackers and AXQuery Support;O Monitoring the status of the P2P Network: discovering which are the mostactive/virtuous AXEPTools, their capabilities, how many downloads have beenperformed, how many segments have been provided and for whoseobjects/files, then they are active, etc. This allows to perform specific analysisto assess the reputation of Business actors on the basis of their behavior onthe corresponding AXEPTool;O Controlling the content seeded by the AXEPTools, for example constrainedthem to become an exact replica of each other (uniforming the seedingdistribution), or imposing some distribution for the content in the network of theAXEPTools on the basis of the content distribution and statistical analysis;O Activating automated queries for obtaining, downloading and posting theseobjects into the database of specific content collection on the basis of complexqueries. So that, these active queries can be periodically activated to verify ifsome new content satisfy the criteria and in the positive case, the automateddownload can be activated as well;O Activating automated publishing on the P2P Network of accessible collectionsfrom the AXCP GRID and crawling facilities
  107. 107. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 110OO
  108. 108. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 111IPTV vs VODO IPTV: TV via Internet ProtocolO VOD: Video on DemandStreaming ServerplayerIp:portplayerplayerplayerplayerplayerplayerVOD ServerplayerplayerplayerplayerplayerplayerplayerplayerplayerMultipleportsO(1)+O(n) if QoSO(N) in any case: 300bps x 10.000 Clients
  109. 109. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 112P2P Progressive DownloadO The cost of streaming is very highsince the number of streams/usersupported depends on the maxbandwidth supported by theserver: e.g., 10Mbps -> 50x200 kbps,YouTube…O P2P solution reduces the costs ofdistribution while the user has towait for the download to play thecontent.O Progressive P2P supports the playwhile P2P downloading.
  110. 110. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 113BitTorrent:progressive download finestra disegmentidefinite “urgenti”Q Individuare uncompromesso tra la RarestFirst Policy e il downloadsequenziale.Q Fondamentale la scelta delladimensione della finestra. Q d
  111. 111. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 114 La dimensione ottimale dellafinestra deve rispettare laseguente equazioneO Estrazione del BitRate dall’headerdel file (formato WAVE e MP3);O Uso della rarest first policy nellafinestra;O Gestito lo spostamento dellafinestra;Applicazione SymTorrent:Adattamento al download sequenzialeQ Riproduzione del concetto di finestra di segmenti:Q downloadsequenzialeQ download nonsequenziale(SymTorrentoriginale)Q w = n° blocchi nella finestraQ d = playback delay (secondi)Q b = BitRate file (Kb/s)Q c = dimensione blocco in byte
  112. 112. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 115Implementazione Multimedia StreamingO Creata un’interazione tra le applicazioni: garantita lacontemporaneità dei servizi forniti dalle dueO La strategia di buffering implementata fornisce all’utente una stimadel tempo di attesa necessario per garantire una riproduzione fluidadel media:La formula w = d*b garantisce la riproduzione dei primi d secondiTerminati i d secondi, è necessario rispettare la relazionecDR = velocità media di download delfile dalla reteS = secondi necessari a scaricare iw blocchi successivid
  113. 113. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 116O Monitoraggioreti P2P
  114. 114. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 117O Monitoraggio reti P2P Analisi del traffico dei downloadO Motivazioni: Misurare l’effettivo gradimento di un prodotto di mercatotramite la sua diffusione sul P2P Quantificare il fenomeno di download illegale, per eventualeripartizione dei diritti forfettari Statistiche sulla distribuzione di contenuti digitaliO Come: Fare delle analisi periodiche Analizzare I risultati territoriali Produrre dei report anche per estrapolazione
  115. 115. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 118Requisiti P2P MonitoringO Fare un’analisi della rete e della diffusione dei downloadsulla base di keyword prelevate identificate dal committente Keyword prese dalle top 20, top 10, eventi, etc. Nuovi prodotto di mercato Nuove uscite dei film Etc.O Periodicamente fare questa analisi per: comprendere il trend Calcolare un volume di scaricamenti o pervasivita’
  116. 116. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 119ArchitetturaReteP2PinfoinfoinfoKeywordestraction Query EngineReteP2PReteP2PdatabaseP2PCrawlerSchedulerDataAnalyzerP2P statusMonitoring
  117. 117. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 120Sequence Diagrams
  118. 118. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 121Example of track record
  119. 119. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 122Andamento dei Seeder/peerFigura 6.1 degli utenti per paese
  120. 120. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 123Andamento dei Seeder nel tempo x key
  121. 121. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 124O Analisi della situzione Italiana Su quelle keyword Per quel periodo Senza estrapolazioneO Dai 2 siti P2P (TorrentPortal,TorrentBox) In media 318000 record salvati 5600 IP individuati per ogni 10 ore di esecuzione Circa 2200 seeder 46 file effettivamente condivisi
  122. 122. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 125O P2P, Db DHTO DistributedTrust
  123. 123. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 126O le prestazioni del DRM AXMEDIS sono fortementecondizionate dal numero di chiamate contemporanee; Ad esempio, in certi casi, ogni 8 richieste diautorizzazione in contemporanea, 2 non hanno esitopositivo, a causa dei ritardi nell’elaborazione; il DRM AXMEDIS ha complessità computazionalelineare 1:N (1 server:N client), e.g., 10 alla 12. O(R),O(U*C), un milione di utenti per un milione di content.Obiettivi:O Scalabilità: definire e sviluppare una soluzione scalabileche consenta di far fronte a carichi elevati sul sistema,decentralizzando le risorse da aggiungere, in modo dapoter soddisfare un elevato numero di richiestecontemporanee.O Sicurezza: adottare politiche adeguate alla nuovasoluzione, mantenendo gli stessi standard di sicurezzaP2P reciprocal Trusting for DRM
  124. 124. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 127
  125. 125. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 128Richiami sul DRMO AXMEDIS e’ un’infrastruttura distribuita multipiattaforma per la creazione,protezione, distribuzione e consumo delle risorse digitaliO Digital Rights Management, DRM: meccanismi di gestione dei diritti di risorse digitali, grazie allapossibilità di rendere protette, identificabili e tracciabili le risorsestesseO DRM AXMEDIS fornisce una serie di strumenti che consentono dicertificare utenti e dispositivi,gestire i diritti econtrollarne lo sfruttamento da parte degli utenti finali
  126. 126. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 129Architettura DRM AXMEDISAXMEDIS DRM SERVERSAXCSPMS ServerCAAXMEDIS PLAYERSPMS ClientsAXCP GRIDDistributor ServersMonitoring andReporting
  127. 127. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 130DRM AXMEDIS/MPEG-21O Procedure fondamentali del DRM:•Server side•registrazione di: utente e tool type•protezione e registrazione del contenuto•registrazione della licenza•Client side•certificazione del tool: salvataggio dei dati relativi al toolutilizzato•verifica del tool: controllo sull’integrità•autorizzazione: concessione del grant all’utente finale
  128. 128. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 131DRM AXMEDIS EsempioAXMEDIS DRMAXCSPMS ServerCADBDBAXMEDISPlayerCertificazione del toolRegistrazione della licenzaLicensorVerifica del toolAutorizzazione
  129. 129. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 132Q 132Scelta della struttura decentralizzataO Si concretizza la decentralizzazione scegliendo didelegare l’esecuzione di alcune procedure chiave ad unaDHT su rete P2P DHT: Distributed Hash Table: Classe di sistemi distribuiti decentralizzati che partizionanol’appartenenza di un set di chiavi tra i nodi che fanno parte dellarete P2P; hanno complessità computazionale logaritmicaO Perché Bamboo DHT:• due insiemi di vicini: leaf set e routing table• interfacce put/get predefinite: XML-RPC• gestione del churn• open source
  130. 130. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 133RETE P2PDBAXCP GRIDprocessingregistrationpackagingprotectionlicensingSERVERSPLAYERSINTERNET,WEB...BROADCAST,IP-TV,i-TV...MOBILES, PDA...AX P2PAXMEDIS DRMSERVERSAX P2PNETWORKCMSContentReportingMonitoringandreportingRegisteringLicensingLicensingGrantProtectedcontent
  131. 131. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 134Interazioni tra nodi e DRMAXMEDIS DRM SERVERSPMS ServerFinal userAXMEDIS PlayerPMS ClientBamboo DHTNodeBamboo DHTGatewayOther nodesBambooNodeBambooNodeBambooNodeBambooNode
  132. 132. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 135Esempio di deployment ‘ottimo’AXMEDIS DRM SERVERSPMS ServerFinal userAXMEDIS PlayerPMS ClientBamboo NodeBambooGateway 1Other nodesBambooNodeBambooNodeBambooNodeBambooNodeBambooGateway 2BambooGateway N…
  133. 133. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 136Q 136Salvataggio dati sulla DHTO avviene nei casi dicertificazione del tool eregistrazione della licenza.O si effettua durantela verifica del tool el’autorizzazione per l’utente finale.O Il PMS Server, completate le rispettiveprocedure, effettuauna connessione ad un nodo Bamboo Gatewayper trasmettere le informazioni utili.
  134. 134. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 137Recupero dati dalla DHTO Si effettua, come scelta prioritaria,ogni volta che si eseguono le procedure di verifica eautorizzazione.O Spetta al PMS Client effettuare un lookup sullaDHT,in base alla chiave specifica per la relativaprocedura.O Quando viene trovata una corrispondenza sullarete P2P,la procedura viene espletata direttamente,senza dover ricorrere ai server di DRM AXMEDIS.
  135. 135. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 138K VK VK VK VK VK VK VK VK VK VK VDHT in action: put()put(K1,V1)Operation: take key as input; route msgs to node holding key(K1,V1)
  136. 136. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 139get (K1)K VK VK VK VK VK VK VK VK VK VK VDHT in action: get()Operation: take key as input; route msgs to node holding key
  137. 137. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 140O n keyspace composto da stringhe di 160 bit Al massimo di hanno u numero di hop pari al Log in basedue di 160 Costo della ricerca: O(log N)O Se si vuole immettere nella DHT un contenutocaratterizzato dai parametri filename e data, vieneinizialmente calcolato l’hash del filename, ad esempiotramite un algoritmo SHAO Bamboo è un sistema peer to peer che riassume alcunedelle caratteristiche di Chord e Tapestry. È stato scritto inJava da Sean Rhea della UC Berkeley, ma si basafortemente sui progetti OceanStore e Libasync, ed èopen source
  138. 138. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 141Sicurezza dei datiO Sicurezza ottenuta tramite meccanismi di crittazione:Blowfish e RSA.O Si ottiene quindi un doppio sistema di cifratura, cheimpedisce agli utenti non autorizzati l’utilizzo delleinformazioni riservate.AXUID AXOID Right Protection KeyAXTIDBlowfishkey Enabling CodeCriptato con BlowfishCriptatocon chiavepubblica utenteBlowfishkeyPer la licenzaper verificaDHT ValueDHT key
  139. 139. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 142Scenario di test (1)LicensorAXMEDIS DRMAXCSPMS ServerCABamboo DHTDBDBAXMEDISPlayerPubKeyPrivateKeyAnaloga procedura usata perla certificazione e verifica del toolQ 142
  140. 140. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 143PM SServerAXC S2: soap_call_PM S 1_certify()3: certify()8: getPubKeyFrom D B()11: encryptD H T()12: D H Tvalue13: store_certInfo_D H T()PM SC lientgetPM SC lient.certify()1: certify()7: certified4: soap_call_axcv1_certify()5: certResult=06: certifiedD atabaseD H T9:query10:PubKey15:storeResult14:execute()
  141. 141. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 144Computing and saving protection information relatedto a grant authorization formalized in a license, in thecase of DRM P2P.P M S S e r v e rA X C S2 : s o a p _ c a ll_ P M S 1 _ s e n d L ic e n s e ( )3 : s e n d L ic e n s e ( )1 7 : g e t P u b K e y F r o m D B ( )2 0 : g e t E n c K e y D H T ( )2 3 : e n c r y p t D H T ( )2 4 : D H T v a lu e2 5 : s t o r e _ lic e n s e _ D H T ( )P M S C lie n t1 : s e n d L ic e n s e ( )1 6 : lic e n s e I D4:soap_call_axcv1_ping()13:soap_call_axcv1_verifyPmsAL()21:soap_call_axs1_getProtectionInfo()L ic e n s e V e r if ic a t o rL ic e n s e M a n a g e rL ic e n s e8 : is D is tr ib u to r L ic e n s e ( )22:encKey14:ALverified5:AXCSonline6 : v e r if y L ic e n s e ( )1 0 : v e r if y T e m p L ic e n s e ( )1 1 : c o r r e c t L ic e n s e7 : lic e n s e V e r if ie d9 : n o tD is tr ib u to r L ic e n s e12:storeLicense()1 5 : lic e n s e I DD a t a b a s e18:query19:PubKeyD H T26:execute()27:storeResult
  142. 142. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 145Scenario di test (2)LicensorAXMEDIS DRMAXCSPMS ServerCABamboo DHTDBDBAXMEDISPlayerPubKey
  143. 143. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 146Considerazioni su P2P DRMDRM AXMEDISTRADIZIONALEDRM P2PSICUREZZA SI SITRUST MANAGEMENT SI SIRIDONDANZA DEI DATI NO SISCALABILITA’ NO SIEFFICIENZA Lineare LogaritmicaCosto di storage O(L=C*U)O(L=C*U)+ duplications on DHTCosto di accesso,transazioneO(U*devices), caso peggioreO(1)  O(U*D) sulserver oppure su DHTO( Log2 N )FAULT TOLERANCE NO SI
  144. 144. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 147Parameter Description Range ofvaluesL Size of the leaf node list 8-400Ltime Time to update the leaf node list 25-250sK Number of replicas per node 4-200N Number of nodes involved in the network 1000-10000Delay Delay of transmission 30-50 msJitter variability over time of the packet latencyacross a network10%SendQueueLenghMax dimension of the output buffer 0.5 Mbyte
  145. 145. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 148(a) L=200, K=100;02040608010012014016018020030% 50% 75%missing %min latency*10 in sec.max lantecy in sec.mean latency in sec.min number of Keysper node/10max number of keysper node/100
  146. 146. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 149Trend of the percentage of missing estimated onthe DHT P2P for the cases of a churn of 30%,50% and 75%, and K equal to 100, 150, and 200.0102030405030% 50% 75%K=100K=150K=200
  147. 147. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 150Trend of the percentage of missing estimated on the DHT P2PWith respect to the Ltime value for the cases of a churn of 30%,and different values of the number of nodes, N, with the same number ofreplica0,00%0,50%1,00%1,50%2,00%2,50%3,00%3,50%50 100 150 200 250 300 350 400 450 500N=1000N=5000
  148. 148. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 151Trend of the percentage of missing estimated on the DHTP2P with respect to different percentage of churn, for Kequal to 20, 16 and 802040608010012030% 50% 75% 90%K=20K=16K=8
  149. 149. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 152Trend of needed bandwidth for the PMS Server with respect tothe number of requests per second of verification/authenticationcoming from the clients both with and without P2P solution, forK=100.01020304050607080901001 10 100 1000 10000 100000PMSServerBandwidthMBRequests/sec.Without P2PWith P2P
  150. 150. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 153BibliografiaO P. Bellini, P. Nesi, F. Pazzaglia, "Exploiting P2P Scalability for GrantAuthorization in Digital Rights Management Solutions", InternationalJournal Multimedia Tools and Applications, Springer press, 2013. ,DOI 10.1007/s11042-013-1468-y, Pub on line April 2013,O Emanuele Bellini , Paolo Nesi, "A Trust P2P network for the Access toOpen Archive resources", WORLD LIBRARY AND INFORMATIONCONGRESS: 75TH IFLA GENERAL CONFERENCE AND COUNCIL,23-27 August 2009, Milan, Italy, http://www.ifla.org/annual-conference/ifla75/index.htmO P. Bellini, I. Bruno, D. Cenni, P. Nesi, D. Rogai, “P2P Architecture forAutomated B2B Cross Media Content Distribution”, AutomatedProduction of Cross Media Content for Multi-Channel Distribution,2007. AXMEDIS 07. Third International Conference on, AXMEDIS2007, IEEE press, 28-30 Nov. 2007 Page(s):105 - 112, Digital ObjectIdentifier 10.1109/AXMEDIS.2007.31
  151. 151. Sistemi Distribuiti, Univ. Firenze, Paolo Nesi 2012-2013 154BibliographyO Colouris Book come menzionato nelle prime slidedel corsoO progetto Jxta ( http://www.jxta.org )O progetto MyJxta2 ( http://myjxta2.jxta.org )O Bernard Traversa, Project JXTA 2.0 Super-PeerVirtual Network, Maggio 2003.O AXMEDIS P2P solution extending BitTorrent www.axmedis.org

×