Receiversjoingroupsbyinformingupstreamrouterseg

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: address)'to'advertise/ discover'multicast'groups' Multicast'Delivery' IPv4'multicast:' •  sender'sends'a'single'packet'to'the'IP'multicast'address' •  multicast'data'is'sent'best7effort,'using'UDP' •  sender'sendto()'the'multicast'address' •  receiver'recvfrom()'the'multicast'address' •  routers'deliver'packets'to'all'interfaces'that'reaches'a' receiver'belonging'to'the'multicast'group' •  receivers'join'groups'by'informing'upstream'routers,'e.g.,' by'using'Internet'Group'Management'Protocol'(IGMP)' •  not'uniformly'deployed'throughout'the'Internet' End7host'Multicast' Issues'in'multicast'group'management:' 1.  how'to'advertise/discover'a'multicast'group?' 2.  how'to'join'a'multicast'group?' 3.  delivering'multicast'packets'to'the'group' ' End7host'(p2p)'multicast:' •  use'a'well7known,'centralized'rendezvous'server' •  each'peer'must'register'with'rendezvous'server' •  rendezvous'server'returns'a'(random)'list'of'peers' •  each'peer'can'support'only'a'limited'number'of'peers' •  avoid'sending'duplicate'messages'and'looping:' •  if'single'source,'construct'a'shortest7path'tree'rooted'at'source' •  or'use'flood7and7prune'algorithm' •  prefer'peers'in'same'subnet' Flood'and'Prune' How'to'ensure'that'only'one'copy'of'packet' from'S'is'forwarded'by'P3'to'P4?' S! •  keep'track'of'packet'sequence'number' •  only'forward'packet'that'comes'from' shortest'path'from'(to)'source' ' How'to'ensure'that'only'one'copy'of'packet' from'S'reaches'P3?' •  only'forward'if'self'is'on'neighbor’s'shortest'path' from'(to)'source' •  prune'(P3'tells'P2'not'to'forward'packets'from'S )' P1! P2! P3! P4! •  must'be'done'per'source'if'there'are'multiple'sources,' each'source'forming'its'own'multicast'group'and' (logically)'its'own'multicast'tree' •  must'periodically'flood'in'case'of'membership'change' P2P(Overlay(Networks( P2P(applicaCons/peers(need(to:( •  track(idenCCes(and(IP(addresses(of(peers( •  there(may(be(a(large(number(of(peers( •  peers(may(come(and(go(frequently((high(churn)( •  can’t(keep(track(of(all(peers( •  route(messages(among(peers( •  may(be(mulCQhop( ( Overlay(network( •  peers(have(to(do(both(naming(and(rouCng( •  IP(becomes( just (the(lowQlevel(transport( •  all(IP(rouCng(is(opaque( application transport network link physical P2P'Challenges' Relative'to'other'parallel/distributed'systems:' •  partial'failure' •  churn' •  few'guarantees'on'transport,'storage,'etc.' •  network'bottlenecks'and'other'resource'constraints' •  no'administrative'organizations' •  trust'issues:'security,'privacy,'incentives' Relative'to'IP'networking:' •  much'higher'function,'more'flexible' •  much'less'controllable/predictable' Challenges'for'P2P'Networks' 1.  NAT'and'firewall:' •  cannot'peer'with'a'host'you'can’t'address' Solutions:' •  Gnutella:' •  querier'sends'PUSH'message'to'responder'over'the'p2p'network' •  responder'opens'a'TCP'connection'to'querier'and'send'over'the'file' •  no'luck'if'both'are'behind'firewalls' •  KaZaA,'eDonkey,'Skype:' •  supernodes'establish'relay'if'both'peers'are'behind'firewalls' •  Standards'to'traverse'NAT'(and'firewall!):'UPnP,'STUN' 2.  Download/upload'bandwidth'asymmetry' 'needs'bandwidth'subsidy'by'content'provider'or'CDN,' or'suffer'long'download'time'...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online