-
Computer Networks
Lecture8:ContentDeliveryInfrastructure:Peer-to-Peer
2015InternetTrafficAnalysis
Sandvine’sGlobalInternetPhenomenaReport:https://www.sandvine.com/trends/global-internet-phenomena/
ContentDistribution
Mostpopularcontentcanonlybeservedifitishighlyreplicatedacrossmultipleservers•
reduceloadatoriginserver•
improveperformanceforendusersMostContentDeliveryInfrastructures(CDI)havealargenumberofserversdistributedacrosstheInternetandcachecontentontheseservers
ContentDeliveryInfrastructure
Peer-to-peer(p2p):• hybridp2pwithacentralizedserver• purep2p•
hierarchicalp2p• end-host(p2p)multicast
Content-DistributionNetwork(CDN)
-
HybridP2PandCentralizedServer
Napster:• P2Pfiletransfer• centralizedfilesearch:•
peersregisterIPaddressandcontentatacentralindexserver
• peersquerycentralindexservertolocatecontent
register
queryreply
PureP2PArchitecture• noalways-onserver• arbitraryendsystemsdirectlycommunicate• peersareintermittentlyconnectedandchangeIPaddresses• example:Gnutella• highlyscalable(why?)• butdifficulttomanage•
howtofindpeer?• howtofindcontent?
Gnutella• nocentralizedindexserver•
networkdiscoveryusingpingandpongmessages
• filediscoveryusingqueryandqueryHitmessages
•
bothpingandquerymessagesareforwardedusingthefloodingalgorithm:forwardonalllinksexceptincomingone
• previouslyseenmessagesarenotfurtherforwarded
• newversionofgnutellausesKaZaA-likesupernodes
A
B
ping
pong
A
B
query
queryHit
HierarchicalP2PFastTrackusedbyKaZaA,Groskster,iMesh,Morpheus•
hierarchicalarchitecture•
peersdividedintosupernodesandordinarynodes
• eachsupernodekeepsanindexofallitschildren’sfiles
• requestsaresenttosupernodes•
supernodesqueryeachotherforfilesnotintheirlocalindices
•
ordinarynodesare“promoted”tosupernodesiftheyhaveenoughresourcesandhavestayedonnetworklongenough
• paralleldownloadoffiles
reg
req
-
HierarchicalP2P:SkypeSkypeformsahierarchicalP2P:•
indexmappingusernamestoIPaddressesisdistributedacrosssupernodes•
searchesforSkypeusersaresenttosupernodes
• supernodesqueryeachotherforusersnotintheirlocalindex
• supernodeschooseapeertoactasrelayfortwoNATtedusers
eDonkey/eMulealsobuildsahierarchicalnetwork,butthe“supernodes”arededicatedservers,notjustmoreequalpeers
openhost
A
B
maintain a central index of files, so that userscan send
requests directly to information hold-ers. Unfortunately,
centralization creates a sin-gle point of failure that is easy to
attack. Forexample, if you were trying to phone MichaelJordan, the
simplest way to get his numberwould ordinarily be to call directory
assistance.However, because directory assistance is central-ized,
your access can be easily blocked if Jordanor someone else decides
to remove his directoryentry, or if the service goes down.
Systems like Gnutella broadcast queries to everyconnected node
within some radius. Using thismethod, you would ask all of your
friends if anyof them knew Jordan’s number, get them to asktheir
friends, and so on. Within a few steps, thou-sands of people could
be looking for his number.Although this process would eventually
find youranswer, it is clearly wasteful and unscalable.
Freenet avoids both problems by using asteepest-ascent
hill-climbing search: Each nodeforwards queries to the node that it
thinks isclosest to the target. You might start searchingfor Jordan
by asking a friend who once playedcollege basketball, for example,
who might passyour request on to a former coach, who couldpass it
to a talent scout, who might pass it to Jor-dan’s agent, who could
put you in touch with theman himself.
Requesting files. Every node maintains a routingtable that lists
the addresses of other nodes and theGUID keys it thinks they hold.
When a nodereceives a query, it first checks its own store, and
ifit finds the file, returns it with a tag identifyingitself as the
data holder. Otherwise, the node for-wards the request to the node
in its table with theclosest key to the one requested. That node
thenchecks its store, and so on. If the request is suc-
cessful, each node in the chain passes the file backupstream and
creates a new entry in its routingtable associating the data holder
with the request-ed key. Depending on its distance from the
holder,each node might also cache a copy locally.
To conceal the identity of the data holder, nodeswill
occasionally alter reply messages, setting theholder tags to point
to themselves before passingthem back up the chain. Later requests
will stilllocate the data because the node retains the truedata
holder’s identity in its own routing table andforwards queries to
the correct holder. Routingtables are never revealed to other
nodes.
To limit resource usage, the requester gives eachquery a
time-to-live limit that is decremented ateach node. If the TTL
expires, the query fails,although the user can try again with a
higher TTL(up to some maximum). Because the TTL can giveclues about
where in the chain the requester is,Freenet offers the option of
enhancing security byadding an initial mix-net route before
normalrouting. This effectively repositions the start of thechain
away from the requester.
If a node sends a query to a recipient that isalready in the
chain, the message is bounced backand the node tries to use the
next-closest keyinstead. If a node runs out of candidates to try,
itreports failure back to its predecessor in the chain,which then
tries its second choice, and so on.
Figure 1 depicts a typical request sequence. Theuser initiates a
request at node A and forwards therequest to B, which forwards it
to C. Node C isunable to contact any other nodes and returns
a“request failed” message to B. Node B then triesits second choice,
E, which forwards the requestto F. Node F forwards the request to
B, whichdetects a loop and bounces the message back.Unable to
contact any additional nodes, node Fbacktracks one step to E, which
forwards therequest to its second choice, D, and locates thefile. D
returns the file via E and B back to A,which sends it to the user.
Along the way, E, B,and A might also cache the file.
With this approach, the request homes in closerwith each hop
until the key is found. A subsequentquery for this key will tend to
approach the firstrequest’s path, and a locally cached copy can
sat-isfy the query after the two paths converge. Sub-sequent
queries for similar keys will also jump overintermediate nodes to
one that has previously sup-plied similar data. Nodes that reliably
answerqueries will be added to more routing tables, andhence, will
be contacted more often than nodesthat do not.
44 JANUARY • FEBRUARY 2002 http://computer.org/internet/ IEEE
INTERNET COMPUTING
Peer-to-Peer Networking
Figure 1.Typical request sequence.The request moves through
thenetwork from node to node, backing out of a dead-end (step 3)
anda loop (step 7) before locating the desired file.
= Data request
= Data reply
= Request failedRequester
Data holder
2 3
58
910
4
1
11
12
67
a b
c
d
ef
Freenet:AnonymousP2P• noindexserver•
requesterdoesn’tconnectdirectlytocontentprovider
•
instead,contentispassedinabucket-brigadefashionfromprovidertorequester
•
subsequentrequestforthesamecontentissatisfiedfromthenearestcache
•
requestercannotdifferentiateproviderfromacacheholderoraforwardingpeer(allowsforanonymity)
BitTorrentContentdistribution:•
contentisdividedintoNpiecesof16KBeachandsenttoNpeers
Contentdownload:•
todownloadafile,apeermustfirstregisterwithaTracker•
Trackerreturnsarandomlistofpeerswhohavethefile•
peeropensabout5TCPconnectionstotheprovidedpeers•
apeerwillonlyuploadtopeersfromwhomitcanalsodownload(“tit-for-tat”)
Summary:P2POverlayNetworksP2Papplications/peersneedto:•
trackidentitiesandIPaddressesofpeers•
theremaybealargenumberofpeers•
peersmaycomeandgofrequently(highchurn)• can’tkeeptrackofallpeers•
routemessagesamongpeers• maybemulti-hop
Overlaynetwork• peershavetodobothnamingandrouting• IPbecomes
just thelow-leveldeliverysubstrate• allIProutingisopaque
application
transport
network
link
physical
-
ModesofDeliveryUnicast,broadcast,multicastAssumingavideoconference
involvingS,D2,andD3•
unicasting:twocopiesofpacketsfromSaresentovertheSRlink•
broadcasting:onecopyofpacketssentfromStoalldestinations,butpacketssenttoD1andD4unnecessarily•
multicasting:onecopyofpacketsfromSissentovertheSRlink,RthensendsonecopyeachtoD2andD3
D4
D3
D2
D1
RS
MulticastDelivery
Usesofmulticasting:•
videoconferencing,distancelearning,distributedcomputation,p2pdelivery,multi-playergaming,etc.
Multicastdesigngoals:•
cansupportmillionsofreceiverspermulticastgroup•
receiverscanjoinandleaveanygroupatanytime•
sendersdon’tknowallreceivers•
sendersdon’thavetobemembersofagrouptosend•
therecouldbemorethanonesenderspergroup
MulticastGroupManagementIssuesinmulticastgroupmanagement:1.
howtoadvertise/discoveramulticastgroup?2.
howtojoinamulticastgroup?3.
deliveringmulticastpacketstothegroup
IPmulticast:• usemulticastaddressesasanonymousrendezvouspoint:•
IPv4:Class-D(224.0.0.0to239.255.255.255[RPC3171])•
265Mmulticastgroupsatmost• IPv6:multicastprefix:FF00::/8
•
createawell-knownmulticastgroup(address)toadvertise/discovermulticastgroups
MulticastDeliveryIPmulticast:
• sendersendsasinglepackettotheIPmulticastaddress
• multicastdataissentbest-effort,usingUDP(why?)
•
routersdeliverpacketsoutallinterfacesthathasareceiverbelongingtothemulticastgroup
•
receiversjoingroupsbyinformingupstreamrouters,e.g.,byusingInternetGroupManagementProtocol(IGMP)
• notuniformlydeployedthroughouttheInternet
-
FloodandPruneHowtoensurethatonlyonecopyofpacketfromSisforwardedbyP3toP4?•
keeptrackofpacketsequencenumber•
onlyforwardpacketthatcomesfromshortestpathfrom(to)source
HowtoensurethatonlyonecopyofpacketfromSreachesP3?•
onlyforwardifselfisonneighbor’sshortestpathfrom(to)source
• prune(P3tellsP2nottoforwardpacketsfromS )•
mustbedonepersourceiftherearemultiplesources,
eachsourceformingitsownmulticastgroupand(logically)itsownmulticasttree
• mustperiodicallyfloodincaseofmembershipchange
S
P3
P2P1
P4
End-hostMulticastIssuesinmulticastgroupmanagement:1.
howtoadvertise/discoveramulticastgroup?2.
howtojoinamulticastgroup?3.
deliveringmulticastpacketstothegroup
End-host(p2p)multicast:•
usesawell-known,centralizedrendezvousserver•
eachpeermustregisterwithrendezvousserver•
rendezvousserverreturnsa(random)listofpeers•
eachpeercansupportonlyalimitednumberofpeers•
avoidsendingduplicatemessagesandlooping:•
ifsinglesource,constructsashortest-pathtreerootedatsource•
orusesflood-and-prunealgorithm
• preferspeersinsamesubnet
P2PChallenges
RelativetoIPnetworking:• muchhigherfunction,moreflexible• muchlesscontrollable/predictable
Relativetootherparallel/distributedsystems:•
noadministrativeorganizations•
fewguaranteesontransport,storage,etc.• partialfailure• churn•
networkbottlenecksandotherresourceconstraints•
trustissues:security,privacy,incentives
ChallengesforP2PNetworks1. NATandfirewall:•
cannotpeerwithahostyoucan’taddress
Solutions:• Gnutella:•
queriersendsPUSHmessagetoresponderoverthep2pnetwork•
responderopensaTCPconnectiontoquerierandsendsoverthefile•
noluckifbotharebehindfirewalls
• KaZaA,eDonkey,Skype:•
asupernodeactsasrelayifbothpeersarebehindfirewalls
• StandardstotraverseNAT(andfirewall!):UPnP,STUN,TURN
2. Download/uploadbandwidthasymmetryneedsbandwidthsubsidybycontentproviderorCDN,orsufferlongdownloadtime
