La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Cours 7 (18 novembre 2011 DNS, Pair à pair. M2-Internet 2 DNS Why not centralize DNS? r single point of failure r traffic volume r distant centralized.

Présentations similaires

Présentation au sujet: "Cours 7 (18 novembre 2011 DNS, Pair à pair. M2-Internet 2 DNS Why not centralize DNS? r single point of failure r traffic volume r distant centralized."— Transcription de la présentation:

1 Cours 7 (18 novembre 2011 DNS, Pair à pair

2 M2-Internet 2 DNS Why not centralize DNS? r single point of failure r traffic volume r distant centralized database r maintenance doesnt scale! DNS services r hostname to IP address translation r host aliasing Canonical, alias names r mail server aliasing r load distribution replicated Web servers: set of IP addresses for one canonical name H. Fauconnier

3 M2-Internet 3 Root DNS Servers com DNS servers org DNS serversedu DNS servers DNS servers DNS servers DNS servers DNS servers DNS servers Distributed, Hierarchical Database Client wants IP for; 1 st approx: r client queries a root server to find com DNS server r client queries com DNS server to get DNS server r client queries DNS server to get IP address for H. Fauconnier

4 M2-Internet 4 DNS: Root name servers r contacted by local name server that can not resolve name r root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) i Autonomica, Stockholm (plus 28 other locations) k RIPE London (also 16 other locations) m WIDE Tokyo (also Seoul, Paris, SF) a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) H. Fauconnier

5 M2-Internet 5 TLD and Authoritative Servers r Top-level domain (TLD) servers: responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. Network Solutions maintains servers for com TLD Educause for edu TLD r Authoritative DNS servers: organizations DNS servers, providing authoritative hostname to IP mappings for organizations servers (e.g., Web, mail). can be maintained by organization or service provider H. Fauconnier

6 M2-Internet 6 Local Name Server r does not strictly belong to hierarchy r each ISP (residential ISP, company, university) has one. also called default name server r when host makes DNS query, query is sent to its local DNS server acts as proxy, forwards query into hierarchy H. Fauconnier

7 M2-Internet 7 requesting host root DNS server local DNS server 1 2 3 4 5 6 authoritative DNS server 7 8 TLD DNS server DNS name resolution example r Host at wants IP address for iterated query: rcontacted server replies with name of server to contact rI dont know this name, but ask this server H. Fauconnier

8 M2-Internet 8 requesting host root DNS server local DNS server 1 2 4 5 6 authoritative DNS server 7 8 TLD DNS server 3 recursive query: rputs burden of name resolution on contacted name server rheavy load? DNS name resolution example H. Fauconnier

9 M2-Internet 9 DNS: caching and updating records r once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time TLD servers typically cached in local name servers Thus root name servers not often visited r update/notify mechanisms under design by IETF RFC 2136 H. Fauconnier

10 M2-Internet 10 DNS records DNS: distributed db storing resource records (RR) r Type=NS name is domain (e.g. value is hostname of authoritative name server for this domain RR format: (name, value, type, ttl) rType=A name is hostname value is IP address rType=CNAME name is alias name for some canonical (the real) name is really value is canonical name rType=MX value is name of mailserver associated with name H. Fauconnier

11 M2-Internet 11 DNS protocol, messages DNS protocol : query and reply messages, both with same message format msg header ridentification: 16 bit # for query, reply to query uses same # rflags: query or reply recursion desired recursion available reply is authoritative H. Fauconnier

12 M2-Internet 12 DNS protocol, messages Name, type fields for a query RRs in response to query records for authoritative servers additional helpful info that may be used H. Fauconnier

13 M2-Internet 13 Inserting records into DNS r example: new startup Network Utopia r register name at DNS registrar (e.g., Network Solutions) provide names, IP addresses of authoritative name server (primary and secondary) registrar inserts two RRs into com TLD server: (,, NS) (,, A) r create authoritative server Type A record for; Type MX record for r How do people get IP address of your Web site? H. Fauconnier

14 M2-Internet 14 Chapter 2: Application layer r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P applications r 2.7 Socket programming with UDP r 2.8 Socket programming with TCP H. Fauconnier

15 M2-Internet 15 P2P file sharing Example r Alice runs P2P client application on her notebook computer r Intermittently connects to Internet; gets new IP address for each connection r Asks for Hey Jude r Application displays other peers that have copy of Hey Jude. r Alice chooses one of the peers, Bob. r File is copied from Bobs PC to Alices notebook: HTTP r While Alice downloads, other users uploading from Alice. r Alices peer is both a Web client and a transient Web server. All peers are servers = highly scalable! H. Fauconnier

16 M2-Internet 16 Pair à pair r quelques principes les nœuds offrent des fonctionnalités identiques (pair) volatilité importante (apparition/disparition) grande échelle et dispersion géographique dynamicité importante r applications partage de fichiers messagerie téléphone (Skype) … différent du client-serveur H. Fauconnier

17 M2-Internet 17 Partage de fichiers r Communication basée sur deux types de protocoles différents découverte et localisation des fichiers recherche des données mettre en contact deux (ou plusieurs) utilisateurs parmi des millions téléchargement des fichiers H. Fauconnier

18 M2-Internet 18 Découverte-localisation r Base publication des fichiers partagés avec des méta-données découverte des fichiers disponibles localisation des sources à télécharger (En plus identification des doublons détection des fichiers corrompus forums) H. Fauconnier

19 M2-Internet 19 Architecture du réseau r Centralisée: un serveur ou un cluster sur lequel les clients se connectent (Napster) r Décentralisée: il n'y a que des clients (Gnutella) r Faiblement centralisée: des clients et des serveurs (Edonkey) r Hybride: les clients peuvent devenir des serveurs H. Fauconnier

20 M2-Internet 20 P2P: problems with centralized directory r Single point of failure r Performance bottleneck r Copyright infringement file transfer is decentralized, but locating content is highly centralized H. Fauconnier

21 M2-Internet 21 Pure P2P architecture r no always-on server r arbitrary end systems directly communicate r peers are intermittently connected and change IP addresses r Three topics: File distribution Searching for information Case Study: Skype peer-peer H. Fauconnier

22 M2-Internet 22 File Distribution: Server-Client vs P2P Question : How much time to distribute file from one server to N peers? usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) File, size F u s : server upload bandwidth u i : peer i upload bandwidth d i : peer i download bandwidth H. Fauconnier

23 M2-Internet 23 File distribution time: server-client usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server sequentially sends N copies: NF/u s time r client i takes F/d i time to download increases linearly in N (for large N) = d cs = max { NF/u s, F/min(d i ) } i Time to distribute F to N clients using client/server approach H. Fauconnier

24 M2-Internet 24 File distribution time: P2P usus u2u2 d1d1 d2d2 u1u1 uNuN dNdN Server Network (with abundant bandwidth) F r server must send one copy: F/u s time r client i takes F/d i time to download r NF bits must be downloaded (aggregate) fastest possible upload rate: u s + u i d P2P = max { F/u s, F/min(d i ), NF/(u s + u i ) } i H. Fauconnier

25 M2-Internet 25 Server-client vs. P2P: example Client upload rate = u, F/u = 1 hour, u s = 10u, d min u s H. Fauconnier

26 Quelques exemples M2-Internet 26H. Fauconnier

27 M2-Internet 27 Query flooding: Gnutella r fully distributed no central server r public domain protocol r many Gnutella clients implementing protocol overlay network: graph r edge between peer X and Y if theres a TCP connection r all active peers and edges is overlay net r Edge is not a physical link r Given peer will typically be connected with < 10 overlay neighbors H. Fauconnier

28 M2-Internet 28 Gnutella: protocol Query QueryHit Query QueryHit Query QueryHit File transfer: HTTP r Query message sent over existing TCP connections r peers forward Query message r QueryHit sent over reverse path Scalability: limited scope flooding H. Fauconnier

29 M2-Internet 29 Gnutella: Peer joining 1. Joining peer X must find some other peer in Gnutella network: use list of candidate peers 2. X sequentially attempts to make TCP with peers on list until connection setup with Y 3. X sends Ping message to Y; Y forwards Ping message. 4. All peers receiving Ping message respond with Pong message 5. X receives many Pong messages. It can then setup additional TCP connections H. Fauconnier

30 M2-Internet 30 Exploiting heterogeneity: KaZaA r Each peer is either a group leader or assigned to a group leader. TCP connection between peer and its group leader. TCP connections between some pairs of group leaders. r Group leader tracks the content in all its children. H. Fauconnier

31 M2-Internet 31 KaZaA: Querying r Each file has a hash and a descriptor r Client sends keyword query to its group leader r Group leader responds with matches: For each match: metadata, hash, IP address r If group leader forwards query to other group leaders, they respond with matches r Client then selects files for downloading HTTP requests using hash as identifier sent to peers holding desired file H. Fauconnier

32 M2-Internet 32 KaZaA tricks r Limitations on simultaneous uploads r Request queuing r Incentive priorities r Parallel downloading H. Fauconnier

33 M2-Internet 33 File distribution: BitTorrent tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer rP2P file distribution H. Fauconnier

34 M2-Internet 34 BitTorrent (1) r file divided into 256KB chunks. r peer joining torrent: has no chunks, but will accumulate them over time registers with tracker to get list of peers, connects to subset of peers (neighbors) r while downloading, peer uploads chunks to other peers. r peers may come and go r once peer has entire file, it may (selfishly) leave or (altruistically) remain H. Fauconnier

35 M2-Internet 35 BitTorrent (2) Pulling Chunks r at any given time, different peers have different subsets of file chunks r periodically, a peer (Alice) asks each neighbor for list of chunks that they have. r Alice sends requests for her missing chunks rarest first Sending Chunks: tit-for-tat rAlice sends chunks to four neighbors currently sending her chunks at the highest rate re-evaluate top 4 every 10 secs revery 30 secs: randomly select another peer, starts sending chunks newly chosen peer may join top 4 optimistically unchoke H. Fauconnier

36 M2-Internet 36 BitTorrent: Tit-for-tat (1) Alice optimistically unchokes Bob (2) Alice becomes one of Bobs top-four providers; Bob reciprocates (3) Bob becomes one of Alices top-four providers With higher upload rate, can find better trading partners & get file faster! H. Fauconnier

37 Rechercher M2-Internet 37H. Fauconnier

38 M2-Internet 38 Recherche par diffusion simple r les clients ne publient rien et ne font que des requêtes une requête est diffusée à tous les clients: avec une limite de portée (TTL) en évitant les cycles (identification unique de la requête, la requête contient le son chemin …) recherche en profondeur ou en largeur un client répond par le chemin emprunté par la requête H. Fauconnier

39 M2-Internet 39 Filtres de Bloom r Principe: un ensemble E de n éléments k fonctions de hachage h i de E sur {1,m} un vecteur de m bits (le filtre) tester si x appartient à E si si le bit h i (x)=0 pour un i non si le bit h i (x)=1 pour tout i oui (mais peut être faux-positif) On diminue les faux positifs en utilisant plusieurs fonctions de hachage Pour m et n donné le k optimal est m/n ln 2 et la probabilité de faux-positifs est (1/2) k H. Fauconnier

40 Exemple: Filtres de Bloom r Trois fonctions de hachage r W nappartient pas à E H. Fauconnier M2-Internet 40

41 Filtres de Bloom r Utilisation: Si le client possède le document les bits des mot-clés correspondant sont à 1 Les clients s'échangent les filtres Les requêtes ne sont propagées que vers les clients qui ont le bon filtre M2-Internet 41 H. Fauconnier

42 M2-Internet 42 Recherche par indexation r Les clients publient les fichiers qu'ils partagent sur les serveurs sur lesquels ils sont connectés r Les serveurs indexent les descriptions des fichiers r Les clients envoient des requêtes aux serveurs pour trouver les fichiers et les localiser H. Fauconnier

43 M2-Internet 43 Recherche par DHT r Distributed Hash Table: Des nœuds et des données Un espace de clés (exemple: clés de 160 bits) Un répartition des clés (qui possède les clés?) Un "overlay" de connexion entre les nœuds pour qui permet de savoir quel nœud possède quelle clé. H. Fauconnier

44 Distributed Hash Table (DHT) r DHT = base de données pour P2P r Contient des couples (key, value) key: numero SS; value: nom key: content type; value: adresse IP r Un pair query la DHT par une key retourne les values correspondant à la key r Un pair peut aussi inserer des couples (key, value) H. Fauconnier44 M2-Internet

45 DHT r Stocker un fichier f de contenu data: Un hachage (SHA1 par exemple) produit une clé de 160 bits k à partir du nom f Par un put(k, data) sur l'overlay trouver le nœud responsable pour la clé k et lui transférer les données r Rechercher un fichier f: Par hachage (SHA1) obtenir la clé k associée à f Rechercher sur l'overlay le nœud responsable de k et récupérer les données M2-Internet 45 H. Fauconnier

46 DHT: hachage consistant r On associe à chaque document (ou mot-clé) un identificateur unique (hachage) r On associe à chaque client un identificateur unique de même taille ID r On définit une métrique pour définir la distance d entre les clés-ID r Un nœud ID i possède les clés j telles que d(j,i) est minimal parmi les ID (chaque nœud possède les clés les plus proches) Le retrait ou lajout d'un nœud ne modifie que les voisins M2-Internet 46 H. Fauconnier

47 DHT r notion d'overlay: chaque nœud maintient des liens vers d'autres nœuds, on obtient ainsi un overlay. Comment obtenir un routage efficace r Un nœud soit possède la clé soit connaît un nœud plus près de la clé: on peut utiliser algorithme glouton basé sur la clé. r On peut aussi définir d'autres algorithmes de routage sur des overlays (et définir des topologies d'overlays ayant de bonnes propriétés –degré et taille des routes). M2-Internet 47 H. Fauconnier

48 DHT Identifiers r Assign integer identifier to each peer in range [0,2 n -1]. Each identifier can be represented by n bits. r Require each key to be an integer in same range. r To get integer keys, hash original key. eg, key = h(Led Zeppelin IV) This is why they call it a distributed hash table H. Fauconnier48 M2-Internet

49 How to assign keys to peers? r Central issue: Assigning (key, value) pairs to peers. r Rule: assign key to the peer that has the closest ID. r Convention in lecture: closest is the immediate successor of the key. r Ex: n=4; peers: 1,3,4,5,8,10,12,14; key = 13, then successor peer = 14 key = 15, then successor peer = 1 H. Fauconnier49 M2-Internet

50 1 3 4 5 8 10 12 15 Circular DHT (1) r Each peer only aware of immediate successor and predecessor. r Overlay network H. Fauconnier50 M2-Internet

51 Circle DHT (2) 0001 0011 0100 0101 1000 1010 1100 1111 Whos resp for key 1110 ? I am O(N) messages on avg to resolve query, when there are N peers 1110 Define closest as closest successor H. Fauconnier51 M2-Internet

52 DHT r exemple Chord: points sur un cercle la distance est la longueur de l'arc orienté. L'espace des clés est décomposé en segments. Si i et j sont des nœuds adjacents, i a toutes les clés comprises entre i et j Anneau de taille 2 m (clés de 0 à 2 m -1) Hachage par SHA1 (ID-clés réparties de façon uniforme) Chaque nœud maintient une liste de K successeurs et K prédécesseurs sur l'anneau M2-Internet 52 H. Fauconnier

53 Peer Churn r Peer 5 abruptly leaves r Peer 4 detects; makes 8 its immediate successor; asks 8 who its immediate successor is; makes 8s immediate successor its second successor. r What if peer 13 wants to join? 1 3 4 5 8 10 12 15 To handle peer churn, require each peer to know the IP address of its two successors. Each peer periodically pings its two successors to see if they are still alive. H. Fauconnier53 M2-Internet

54 Circular DHT with Shortcuts r Each peer keeps track of IP addresses of predecessor, successor, short cuts. r Reduced from 6 to 2 messages. r Possible to design shortcuts so O(log N) neighbors, O(log N) messages in query 1 3 4 5 8 10 12 15 Whos resp for key 1110? H. Fauconnier54 M2-Internet

55 Chord H. Fauconnier M2-Internet 55 Chaque nœud maintient une table de nœuds à distance (n + 2 i ) mod 2 m

56 Chord Chercher le successeur de k pour nœud n: r Soit C(k) le premier nœud successeur de (n+ 2 k-1 ) mod 2 m Si k appartient à ]n, successor]: trouvé Sinon transmettre la demande au plus près prédécesseur f de k dans C(k) Si les nœuds sont répartis uniformément on y arrive en m étapes (et donc en log de la taille =(2 m )) à chaque appel la distance entre le nœud et k divisée par 2. M2-Internet 56 H. Fauconnier

57 M2-Internet 57 Un autre exemple: CAN Content-Addressable Network tore de dimension d join degré = O(d) diamètre moyen = O(d n 1/d ) H. Fauconnier

58 M2-Internet 58 Téléchargement r protocoles ad-hoc (Edonkey, Bittorrent) ou http r Swarming (essaim) téléchargement d'un fichier en téléchargeant différentes parties en parallèle depuis plusieurs clients r téléchargement multiple le fichier est décomposé en n blocs calcul du hachage de chaque bloc fichier est identifié par le hachage des blocs H. Fauconnier

59 M2-Internet 59 Succès… June 19, 2005 - 23:00 Network Users eDonkey2K 4,379,883 FastTrack 2,482,130 Gnutella 1,598,329 Overnet 745,472 DirectConnect 294,255 MP2P 251,137 Filetopia 3,455 H. Fauconnier

60 M2-Internet 60 Quelques réseaux r Napster (historique) Protocole: architecture centralisée recherche par indexation r Fasttrack clients: Kazaa Mldonkey architecture hybride recherche par indexation et diffusion entre ultrapeers identification faible des fichiers (MD5 sur 300ko puis hachage sur 32 bits) http (+ swarming) H. Fauconnier

61 M2-Internet 61 Quelques réseaux r Edonkey Clients: Edonkeys, Emule protocole faiblement centralisée recherche par indexation TCP recherche multi-serveurs par UDP téléchargement en duplex avec bitmaps, streaming et swarming (Bittorrent dans les dernières versions) système de crédits pour inciter au partage r Overnet/Kad télécharement Edonkey décentralisé DHT (Kademlia) H. Fauconnier

62 M2-Internet 62 Quelques réseaux r Gnutella architecture hybride Recherche par diffusion courte (TTL <8) avec filtres de Bloom Gnutella et Gnutella2 téléchargement par http avec possibilité de swarming r Bittorrent pas de découverte, un fichier.torrent contient les infos sur le fichier localisation centralisée pour chaque fichier (tracker) téléchargementavec bitmaps le client commence à forunir du contenu à ses voisins au bout d'un certain temps il bloque les voisins qui ne répondent pas et conserve les quatre meilleurs H. Fauconnier

63 M2-Internet 63 Quelques réseaux r Freenet complètement distribué publication par copie recherche par diffusion en profondeur protocole et contenu cryptés documents signés par signature digitale axé sur l'anonymat H. Fauconnier

64 M2-Internet 64 P2P Case study: Skype r inherently P2P: pairs of users communicate. r proprietary application-layer protocol (inferred via reverse engineering) r hierarchical overlay with SNs r Index maps usernames to IP addresses; distributed over SNs Skype clients (SC) Supernode (SN) Skype login server H. Fauconnier

65 M2-Internet 65 Peers as relays r Problem when both Alice and Bob are behind NATs. NAT prevents an outside peer from initiating a call to insider peer r Solution: Using Alices and Bobs SNs, Relay is chosen Each peer initiates session with relay. Peers can now communicate through NATs via relay H. Fauconnier

Télécharger ppt "Cours 7 (18 novembre 2011 DNS, Pair à pair. M2-Internet 2 DNS Why not centralize DNS? r single point of failure r traffic volume r distant centralized."

Présentations similaires

Annonces Google