Computer Networking Michaelmas/Lent Term M/W/F 11:00-12:00 ... · Computer Networking...

ComputerNetworking

Michaelmas/LentTermM/W/F11:00-12:00LT1inGatesBuilding

SlideSet6

Evangelia [email protected]

2017-2018

1

Topic6– Applications

• Overview

• InfrastructureServices(DNS)

• TraditionalApplications(web)

• MultimediaApplications(SIP)

• P2PNetworks2

3

Client-serverarchitectureserver:

– always-onhost– permanentIPaddress– serverfarmsforscaling

clients:– communicatewithserver– maybeintermittentlyconnected– mayhavedynamicIPaddresses– donotcommunicatedirectly

witheachother

client/server

4

PureP2Parchitecture

• no always-onserver• arbitraryendsystems

directlycommunicate• peersareintermittently

connectedandchangeIPaddresses

Highlyscalablebutdifficulttomanage

peer-peer

5

Hybridofclient-serverandP2PSkype

– voice-over-IPP2Papplication– centralizedserver:findingaddressofremoteparty:

– client-clientconnection:direct(notthroughserver)

Instantmessaging– chattingbetweentwousersisP2P– centralizedservice:clientpresencedetection/location

• userregistersitsIPaddresswithcentralserverwhenitcomesonline

• usercontactscentralservertofindIPaddressesofbuddies

6

Addressingprocesses• toreceivemessages,

processmusthaveidentifier

• hostdevicehasunique32-bitIPaddress

• Q: doesIPaddressofhostonwhichprocessrunssufficeforidentifyingtheprocess?– A: No,many processescanberunningonsamehost

• identifier includesbothIPaddress andportnumbersassociatedwithprocessonhost.

• Exampleportnumbers:– HTTPserver:80– Mailserver:25

• tosendHTTPmessagetoyuba.stanford.edu webserver:– IPaddress: 171.64.74.58– Portnumber: 80

• moreshortly…

Recall:Multiplexingisaserviceprovidedby(each)layertoo!

DemultipexingMultiplexing

Lower channelApplication:oneweb-servermultiplesetsofcontentHost:onemachinemultipleservicesNetwork:onephysicalboxmultipleaddresses(likevns.cl.cam.ac.uk)….

UNIX:/etc/protocols=examplesofdifferenttransport-protocolsontopofIP

UNIX:/etc/services=examplesofdifferent(TCP/UDP)services– byport(Thesefilesareanexampleofa(static)

approachtonameservices)7

8

App-layerprotocoldefines• Typesofmessages

exchanged,– e.g.,request,response

• Messagesyntax:– whatfieldsinmessages&

howfieldsaredelineated

• Messagesemantics– meaningofinformationin

fields

• Rulesforwhenandhowprocessessend&respondtomessages

Public-domainprotocols:• definedinRFCs• allowsforinteroperability• e.g.,HTTP,SMTPProprietaryprotocols:• e.g.,Skype

9

Whattransportservicedoesanappneed?

Dataloss• someapps(e.g.,audio)can

toleratesomeloss• otherapps(e.g.,filetransfer,

telnet)require100%reliabledatatransfer

Timing• someapps(e.g.,Internet

telephony,interactivegames)requirelowdelaytobe“effective”

Throughput❒ someapps(e.g.,multimedia)require

minimumamountofthroughputtobe“effective”

❒ otherapps(“elasticapps”)makeuseofwhateverthroughputtheyget

Security❒ Encryption,dataintegrity,…

MysterioussecretofTransport• Thereismorethansortoftransport layer

Shocked?Iseriouslydoubtit…

RecallthetwomostcommonTCPandUDP

Naming• Internethasoneglobalsystemofaddressing:IP

– Byexplicitdesign

• Andoneglobalsystemofnaming:DNS– Almostbyaccident

• Atthetime,onlyitemsworthnamingwerehosts– Amistakethatcausesmanypainfulworkarounds

• Everythingisnownamedrelativetoahost– Contentismostnotableexample(URLstructure)

10

LogicalStepsinUsingInternet• Humanhasnameofentityshewantstoaccess

– Content,host,etc.

• Invokesanapplicationtoperformrelevanttask– Usingthatname

• AppinvokesDNStotranslatenametoaddress

• Appinvokestransportprotocoltocontacthost– Usingaddressasdestination

11

Addressesvs Names• Scopeofrelevance:

– App/userisprimarilyconcernedwithnames– Networkisprimarilyconcernedwithaddresses

• Timescales:– Namelookuponce(orgetfromcache)– Addresslookuponeachpacket

• Whenmovingahosttoadifferentsubnet:– Theaddresschanges– Thenamedoesnotchange

• Whenmovingcontenttoadifferentlynamedhost– Nameandaddressbothchange!

12

13

Relationship Between Names&Addresses

• Addressescanchangeunderneath– Movewww.bbc.co.uk to212.58.246.92– Humans/Appsshouldbeunaffected

• NamecouldmaptomultipleIPaddresses– www.bbc.co.uk tomultiplereplicasoftheWebsite– Enables

• Load-balancing• Reducinglatencybypickingnearbyservers

• Multiplenamesforthesameaddress– E.g.,aliaseslikewww.bbc.co.uk andbbc.co.uk– Mnemonicstablename,anddynamiccanonicalname

• Canonicalname=actualnameofhost

MappingfromNamestoAddresses• Originally:per-hostfile/etc/hosts

– SRI(MenloPark)keptmastercopy– Downloadedregularly– Flatnamespace

• Singleservernotresilient,doesn’tscale– Adoptedadistributedhierarchicalsystem

• Twointertwinedhierarchies:– Infrastructure:hierarchyofDNSservers– Namingstructure:www.bbc.co.uk

14

15

Domain Name System (DNS)• Topofhierarchy:Root

– Locationhardwiredintootherservers

• NextLevel:Top-leveldomain(TLD)servers– .com,.edu,etc.– .uk,.au,.to,etc.– Managedprofessionally

• BottomLevel:AuthoritativeDNSservers– Actuallydothemapping– Canbemaintainedlocallyorbyaserviceprovider

16

Distributed Hierarchical Database

com edu org ac uk zw arpa

unnamed root

bar

west east

foo my

ac

cam

cl

in-addr

generic domains country domains

my.east.bar.edu cl.cam.ac.uk

Top-Level Domains (TLDs)

17

DNS Root• LocatedinVirginia,USA• Howdowemaketherootscale?

Verisign,Dulles,VA

18

DNS Root Servers• 13rootservers(seehttp://www.root-servers.org/)

– LabeledAthroughM• Doesthis scale?

BUSC-ISIMarinadelRey,CALICANNLosAngeles,CA

ENASAMtView,CAFInternetSoftwareConsortiumPalo Alto,CA

IAutonomica, Stockholm

KRIPELondon

MWIDETokyo

AVerisign,Dulles,VACCogent,Herndon,VADUMarylandCollegePark,MDGUSDoD Vienna,VAHARLAberdeen,MDJVerisign

19

DNS Root Servers• 13rootservers(seehttp://www.root-servers.org/)

– LabeledAthroughM• Replicationviaany-casting (localizedroutingforaddresses)

BUSC-ISIMarinadelRey,CALICANNLosAngeles,CA

ENASAMtView,CAFInternetSoftwareConsortium,Palo Alto,CA(and37otherlocations)

IAutonomica, Stockholm(plus29otherlocations)

KRIPELondon(plus16otherlocations)

MWIDETokyoplusSeoul,Paris,SanFrancisco

AVerisign,Dulles,VACCogent,Herndon,VA(alsoLosAngeles,NY,Chicago)DUMarylandCollegePark,MDGUSDoD Vienna,VAHARLAberdeen,MDJVerisign (21locations)

20

Using DNS• Twocomponents

– LocalDNSservers– Resolversoftwareonhosts

• LocalDNSserver(“defaultnameserver”)– Usuallyneartheendhosts thatuseit– Localhostsconfiguredwithlocalserver(e.g.,/etc/resolv.conf)orlearnserverviaDHCP

• Clientapplication– Extractservername(e.g.,fromtheURL)– Dogethostbyname()totriggerresolvercode

localDNSserverdns.cam.ac.uk

21

requestinghostcl.cam.ac.uk www.stanford.edu

rootDNSserver

1

23

4

5

6

authoritativeDNSserverdns.stanford.edu

78

TLDDNSserver

How Does Resolution Happen?(Iterative example)

Hostatcl.cam.ac.ukwantsIPaddressforwww.stanford.edu

iterated query:❒ Host enquiry is delegated

to local DNS server❒ Consider

transactions 2 – 7 only❒ contacted server replies

with name of next server to contact

❒ “I don’t know this name, but ask this server”

22

requesting hostcl.cam.ac.uk

www.stanford.edu

root DNS server

local DNS serverdns.cam.ac.uk

1

2

45

6

authoritative DNS serverdns.stanford.edu

7

8

TLD DNS server

3recursive query:❒ puts burden of name

resolution on contacted name server

❒ heavy load?

DNSnameresolutionrecursive example

23

Recursive and Iterative Queries - Hybrid case• Recursive query

– Askservertogetanswerforyou

– E.g.,requests1,2andresponses9,10

• Iterative query– Askserverwhotoasknext

– E.g.,allotherrequest-responsepairs

requestinghostmy-host.cl.cam.ac.uk

rootDNSserver

34

5

6

7

authoritativeDNSserverdns.stanford.edu

8

TLDDNSserver

SiteDNSserverdns.cam.ac.uk

2 9

1 10

SiteDNSserverdns.cam.ac.uk

24

DNS Caching• Performingallthesequeriestakestime

– Andallthisbefore actualcommunicationtakesplace– E.g.,1-secondlatencybeforestartingWebdownload

• Caching cangreatlyreduceoverhead– Thetop-levelserversveryrarelychange– Popularsites(e.g.,www.bbc.co.uk)visitedoften– LocalDNSserveroftenhastheinformationcached

• HowDNScachingworks– DNSserverscacheresponsestoqueries– Responsesincludea“timetolive” (TTL)field– ServerdeletescachedentryafterTTLexpires

25

Negative Caching

• Rememberthingsthatdon’twork– Misspellingslikebbcc.co.uk andwww.bbc.com.uk– Thesecantakealongtimetofailthefirsttime– Goodtorememberthattheydon’twork– …sothefailuretakeslesstimethenexttimearound

• But:negativecachingisoptional– Andnotwidelyimplemented

26

Reliability• DNSserversarereplicated(primary/secondary)

– Nameserviceavailableifatleastone replicaisup– Queriescanbeload-balancedbetweenreplicas

• Usually,UDPusedforqueries– Needreliability:mustimplementthisontopofUDP– SpecsupportsTCPtoo,butnotalwaysimplemented

• Tryalternateserversontimeout– Exponentialbackoff whenretryingsameserver

• Sameidentifierforallqueries– Don’tcarewhichserverresponds

DNSandSecurity• Nowaytoverifyanswers

– OpensupDNStomanypotentialattacks– DNSSECfixesthis

• Mostobviousvulnerability:recursiveresolution– Usingrecursiveresolution,hostmusttrustDNSserver– WhenatStarbucks,serverisundertheircontrol– Andcanreturnwhatevervaluesitwants

• Moresubtleattack:Cachepoisoning– Those“additional”recordscanbeanything!

27

Why is the web so successful?• Whatdotheweb,youtube,facebook,tumblr,twitter,flickr,

…..haveincommon?– Theabilitytoself-publish

• Self-publishingthatis easy,independent,free

• Nointerestincollaborativeandidealisticendeavor– Peoplearen’tlookingforNirvana(orevenXanadu)– Peoplealsoaren’tlookingfortechnicalperfection

• Wanttomaketheirmark,andfindsomethingneat– Twosidesofthesamecoin,createssynergy– “Performance”moreimportantthandialogue….

28

29

Web Components• Infrastructure:

– Clients– Servers– Proxies

• Content:– Individualobjects(files,etc.)– Websites(coherentcollectionofobjects)

• Implementation– HTML:formattingcontent– URL:namingcontent– HTTP:protocolforexchangingcontent

AnycontentnotjustHTML!

30

HTML: HyperText MarkupLanguage

• AWebpage has:– BaseHTMLfile– Referencedobjects(e.g.,images)

• HTMLhasseveralfunctions:– Formattext– Referenceimages– Embedhyperlinks (HREF)

31

URL Syntaxprotocol://hostname[:port]/directorypath/resource

protocol http,ftp,https,smtp,rtsp,etc.

hostname DNSname,IPaddress

port Defaultstoprotocol’sstandardporte.g. http:80https:443

directorypath Hierarchical,reflectingfilesystem

resource Identifiesthedesiredresource

Canalsoextendtoprogramexecutions:http://us.f413.mail.yahoo.com/ym/ShowLetter?box=%40B%40Bulk&MsgId=2604_1744106_29699_1123_1261_0_28917_3552_1289957100&Search=&Nhead=f&YY=31454&order=down&sort=date&pos=0&view=a&head=b

32

HyperText Transfer Protocol (HTTP)

• Request-responseprotocol• Relianceonaglobalnamespace• Resourcemetadata• Stateless• ASCIIformat

$ telnet www.cl.cam.ac.uk 80GET /~awm22/win HTTP/1.0<blankline,i.e.,CRLF>

Steps in HTTP Request• HTTPClientinitiatesTCPconnectiontoserver

– SYN– SYNACK– ACK

• ClientsendsHTTPrequesttoserver– CanbepiggybackedonTCP’sACK

• HTTPServerrespondstorequest• Clientreceivestherequest,terminatesconnection• TCPconnectionterminationexchange

HowmanyRTTsforasinglerequest?

33

34

Client-ServerCommunication

• twotypesofHTTPmessages:request,response• HTTPrequestmessage:(GETPOSTHEAD….)

GET /somedir/page.html HTTP/1.1Host: www.someschool.eduUser-agent: Mozilla/4.0Connection: close Accept-language:fr

(extracarriagereturn,linefeed)

requestline(GET,POST,

HEADcommands)

headerlines

Carriagereturn,linefeed

indicatesendofmessage

HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html

data data data data data ...

statusline(protocolstatuscode

statusphrase)

headerlines

data,e.g.,requestedHTMLfile

HTTPresponsemessage

35

Different Forms of Server Response

• Returnafile– URLmatchesafile(e.g., /www/index.html)– Serverreturnsfileastheresponse– Servergeneratesappropriateresponseheader

• Generateresponsedynamically– URLtriggersaprogramontheserver– Serverrunsprogramandsendsoutputtoclient

• Returnmeta-datawithnobody

36

HTTP Resource Meta-Data• Meta-data

– Infoabout aresource,storedasaseparateentity

• Examples:– Sizeofresource,lastmodificationtime,typeofcontent

• Usageexample:ConditionalGETRequest– Clientrequestsobject“If-modified-since”– Ifunchanged,“HTTP/1.1 304 Not Modified”– Nobodyintheserver’sresponse,onlyaheader

37

HTTP is Stateless

• Eachrequest-responsetreatedindependently– Serversnot requiredtoretainstate

• Good:Improvesscalabilityontheserver-side– Failurehandlingiseasier– Canhandlehigherrateofrequests– Orderofrequestsdoesn‘tmatter

• Bad:Someapplicationsneed persistentstate– Needtouniquelyidentifyuserorstoretemporaryinfo– e.g.,Shoppingcart,userprofiles,usagetracking,…

38

State in a Stateless Protocol:

Cookies• Client-side statemaintenance

– Clientstoressmall(?) stateonbehalfofserver– Clientsendsstateinfuturerequeststotheserver

• Canprovideauthentication

Request

ResponseSet-Cookie: XYZ

RequestCookie: XYZ

39

HTTP Performance• MostWebpageshavemultipleobjects

– e.g., HTMLfileandabunchofembeddedimages

• Howdoyouretrievethoseobjects(naively)?– Oneitematatime

• Putstuffintheoptimalplace?– Whereisthatprecisely?

• EntertheWebcacheandtheCDN

40

Fetch HTTP Items: Stop & WaitClient Server

Finish;displaypage

Startfetchingpage Tim

e

≥2RTTsperobject

41

Improving HTTP Performance:

Concurrent Requests & Responses

• Usemultipleconnectionsinparallel

• Doesnotnecessarilymaintainorderofresponses

• Client=J

• Server=J

• Network=LWhy?

R1R2 R3

T1

T2 T3

42


Pipelined Requests & Responses• Batch requestsandresponses

– Reduceconnectionoverhead– Multiplerequestssentinasingle

batch– Maintainsorderofresponses– Item1alwaysarrivesbeforeitem2

• Howisthisdifferentfromconcurrentrequests/responses?– SingleTCPconnection

Client Server


Persistent Connections

• Enablesmultipletransfersperconnection– MaintainTCPconnectionacrossmultiplerequests– Includingtransferssubsequenttocurrentpage– Clientorservercanteardownconnection

• Performanceadvantages:– Avoidoverheadofconnectionset-upandtear-down– AllowTCPtolearnmoreaccurateRTTestimate– AllowTCPcongestionwindowtoincrease– i.e.,leveragepreviouslydiscoveredbandwidth

• DefaultinHTTP/1.1

43

HTTPevolution

• 1.0– oneobjectperTCP:simplebutslow• Parallelconnections- multipleTCP,oneobjecteach:wastesb/w,maybesvr limited,outoforder

• 1.1pipelining– aggregateretrievaltime:ordered,multipleobjectssharingsingleTCP

• 1.1persistent– aggregateTCPoverhead:loweroverheadintime,increaseoverheadatends(e.g.,whenshould/doyouclosetheconnection?)

44

Scorecard:GettingnSmallObjects

Timedominatedbylatency

• One-at-a-time:~2nRTT• Persistent:~(n+1)RTT• Mconcurrent:~2[n/m]RTT• Pipelined:~2RTT• Pipelined/Persistent:~2RTTfirsttime,RTTlater

45

Scorecard:GettingnLargeObjects

Timedominatedbybandwidth

• One-at-a-time:~nF/B• Mconcurrent:~[n/m]F/B

– assumingsharedwithlargepopulationofusers• Pipelinedand/orpersistent:~nF/B

– Theonlythingthathelpsisgettingmorebandwidth..

46

47


Caching• Manyclientstransfersameinformation

– Generatesredundant serverandnetworkload

– Clientsexperienceunnecessary latency

Server

Clients

BackboneISP

ISP-1 ISP-2

48


Caching: How

• ModifiertoGETrequests:– If-modified-since – returns“notmodified” ifresourcenotmodifiedsincespecifiedtime

• Responseheader:– Expires – howlongit’ssafetocachetheresource– No-cache – ignoreallcaches;alwaysgetresourcedirectlyfromserver

49


Caching: Why

• Motiveforplacingcontentclosertoclient:– Usergetsbetterresponsetime– Contentprovidersgethappierusers

• Timeismoney,really!– Networkgetsreducedload

• Whydoescachingwork?– Exploitslocalityofreference

• Howwelldoescachingwork?– Verywell,uptoalimit– Largeoverlapincontent– Butmanyuniquerequests

50


Caching on the Client

Example:ConditionalGETRequest• Returnresourceonlyifithaschangedattheserver

– Saveserverresources!

• How?– Clientspecifies“if-modified-since” timeinrequest– Servercomparesthisagainst“lastmodified” timeofdesiredresource– Serverreturns“304NotModified” ifresourcehasnotchanged– ….ora“200OK” withthelatestversionotherwise

GET /~awm22/win HTTP/1.1Host: www.cl.cam.ac.ukUser-Agent: Mozilla/4.03If-Modified-Since: Sun, 27 Aug 2006 22:25:50 GMT<CRLF>

Requestfromclienttoserver:

51


Caching with Reverse ProxiesCachedocumentsclosetoserver

à decreaseserverload• Typicallydonebycontentproviders

• Onlyworksforstatic(*) content(*)staticcanalsobesnapshotsofdynamiccontent

Clients

BackboneISP

ISP-1 ISP-2

Server

Reverseproxies

52


Caching with Forward ProxiesCachedocumentsclosetoclients

à reducenetworktrafficanddecreaselatency• TypicallydonebyISPsorcorporateLANs

Clients

BackboneISP

ISP-1 ISP-2

Server

Reverseproxies

Forwardproxies

53


Caching w/ Content Distribution Networks

• Integrateforwardandreversecachingfunctionality– Oneoverlaynetwork(usually)administeredbyoneentity– e.g., Akamai

• Providedocumentcaching– Pull: Directresultofclients’ requests– Push:Expectationofhighaccessrate

• Alsodosomeprocessing– Handledynamic webpages– Transcoding– Maybedosomesecurityfunction– watermarkIP

54


Caching with CDNs (cont.)

Clients

ISP-1

Server

Forwardproxies

BackboneISP

ISP-2

CDN

55


CDN Example – Akamai

• Akamaicreatesnewdomainnamesforeachclientcontentprovider.– e.g.,a128.g.akamai.net

• TheCDN’sDNSserversareauthoritativeforthenewdomains

• TheclientcontentprovidermodifiesitscontentsothatembeddedURLsreferencethenewdomains.– “Akamaize” content– e.g.:http://www.bbc.co.uk/popular-image.jpgbecomes

http://a128.g.akamai.net/popular-image.jpg

• RequestsnowsenttoCDN’sinfrastructure…

56

Hosting: Multiple Sites Per Machine

• MultipleWebsitesonasinglemachine– HostingcompanyrunstheWebserveronbehalfofmultiplesites(e.g.,www.foo.com andwww.bar.com)

• Problem:GET /index.html– www.foo.com/index.html orwww.bar.com/index.html?

• Solutions:– Multipleserverprocessesonthesamemachine

• HaveaseparateIPaddress(orport)foreachserver– IncludesitenameinHTTPrequest

• SingleWebserverprocesswithasingleIPaddress• Clientincludes“Host” header(e.g., Host: www.foo.com)• Requiredheader withHTTP/1.1

57

Hosting: Multiple Machines Per Site• ReplicatepopularWebsiteacrossmanymachines

– Helpstohandletheload– Placescontentclosertoclients

• Helpswhencontentisn’tcacheable

• Problem:Wanttodirectclienttoparticularreplica– Balanceloadacrossserverreplicas– Pairclientswithnearbyservers

58

Multi-Hosting at Single Location• SingleIPaddress,multiplemachines

– RunmultiplemachinesbehindasingleIPaddress

– EnsureallpacketsfromasingleTCPconnectiongotothesamereplica

Load Balancer64.236.16.20

59

Multi-Hosting at Several Locations• Multipleaddresses,multiplemachines

– Samenamebutdifferentaddressesforallofthereplicas– ConfigureDNSservertoreturnclosest address

Internet64.236.16.20

173.72.54.131

12.1.1.1

CDNexamplesround-up

• CDNusingDNSDNShasinformationonloading/distribution/location

• CDNusinganycastsameaddressfromDNSnamebutlocalroutes

• CDNbasedonrewritingHTMLURLs(akami examplejustcovered– akami usesDNStoo)

60

SIP– SessionInitiationProtocol

61

Session?

AnyonesmellanOSI/ISOstandardsdocumentburning?

SIP- VoIP

EstablishingcommunicationthroughSIPproxies.

62

SIP?• SIP– bringingthefun/complexityoftelephonytotheInternet–Userlocation–Useravailability–Usercapabilities– Sessionsetup– Sessionmanagement

• (e.g.“callforwarding”)

63

H.323– ITU

• Whyhaveonestandardwhenthereareatleasttwo….

• ThefullH.323ishundredsofpages– Theprotocolisknownforitscomplexity– anITUhallmark

• SIPisnotmuchbetter

– IETFgrewupandbecametheITU….

64

MultimediaApplications

MessageflowforabasicSIPsession

65

The(still?)missingpiece:ResourceAllocationforMultimediaApplications

Ican‘differentiate’VoIPfromdatabut…IcanonlycontroldatagoingintotheInternet

66

MultimediaApplications• ResourceAllocationforMultimediaApplications

Admissioncontrolusingsessioncontrolprotocol.

67

ResourceAllocationforMultimediaApplications

Sowheredoesithappen?Insidesingleinstitutionsordomainsofcontrol…..

(Universities,Hospitals,bigcorp…)

WhataboutmyaDSL/CABLE/etc itcombinesvoiceanddata?Phonecompanycontrols themultiplexingontheline

andthroughouttheirownnetworktoo……

Co-ordinationofSIPsignalingandresourcereservation.

Comingsoon…19952000

2010whoarewekidding??

68

P2P– efficientnetworkusethatannoystheISP

69

70

PureP2Parchitecture

• no always-onserver• arbitraryendsystems

directlycommunicate• peersareintermittently

connectedandchangeIPaddresses

• Threetopics:– Filedistribution– Searchingforinformation– CaseStudy:Skype

peer-peer

71

FileDistribution:Server-Clientvs P2PQuestion :HowmuchtimetodistributefilefromoneservertoNpeers?

usu2d1 d2

u1

uN

dN

Server

Network(withabundantbandwidth)

File,sizeF

us: serveruploadbandwidth

ui: peeri uploadbandwidth

di: peeri downloadbandwidth

72

Filedistributiontime:server-client

usu2d1 d2

u1

uN

dN

Server


F• serversequentiallysendsNcopies:– NF/us time

• clienti takesF/ditimetodownload

increaseslinearlyinN(forlargeN)

=dcs =max{ NF/us,F/min(di) }i

TimetodistributeFtoN clientsusing

client/serverapproach

73

Filedistributiontime:P2P

usu2d1 d2

u1

uN

dN

Server


F• servermustsendonecopy:F/us time

• clienti takesF/ditimetodownload

• NFbitsmustbedownloaded(aggregate)❒ fastestpossibleuploadrate:us +Sui

dP2P =max{ F/us,F/min(di) ,NF/(us +Sui) }i

74

0

0.5

1

1.5

2

2.5

3

3.5

0 5 10 15 20 25 30 35

N

Min

imum

Dis

tribu

tion

Tim

e P2PClient-Server

Server-clientvs.P2P:example

Clientuploadrate=u,F/u=1hour,us =10u,dmin ≥us

75

Filedistribution:BitTorrent**ratheroldBitTorrent

tracker: trackspeersparticipatingintorrent

torrent: groupofpeersexchangingchunksofafile

obtainlistofpeers

tradingchunks

peer

❒ P2Pfiledistribution

76

BitTorrent (1)• filedividedinto256KBchunks.• peerjoiningtorrent:

– hasnochunks,butwillaccumulatethemovertime– registerswithtrackertogetlistofpeers,connectstosubsetofpeers(“neighbors”)

• whiledownloading,peeruploadschunkstootherpeers.• peersmaycomeandgo• oncepeerhasentirefile,itmay(selfishly)leaveor

(altruistically)remain

77

BitTorrent (2)PullingChunks• atanygiventime,different

peershavedifferentsubsetsoffilechunks

• periodically,apeer(Alice)askseachneighborforlistofchunksthattheyhave.

• Alicesendsrequestsforhermissingchunks– rarestfirst

SendingChunks:tit-for-tat❒ Alicesendschunkstofourneighbors

currentlysendingherchunksatthehighestratev re-evaluatetop4every10secs

❒ every30secs:randomlyselectanotherpeer,startssendingchunksv newlychosenpeermayjointop4v “optimisticallyunchoke”

78

BitTorrent:Tit-for-tat(1)Alice“optimisticallyunchokes” Bob(2)AlicebecomesoneofBob’stop-fourproviders;Bobreciprocates(3)BobbecomesoneofAlice’stop-fourproviders

Withhigheruploadrate,canfindbettertradingpartners&getfilefaster!

DistributedHashTable(DHT)

• DHT=distributedP2Pdatabase• Databasehas(key,value)pairs;

– key:ss number;value:humanname– key:contenttype;value:IPaddress

• Peersquery DBwithkey– DBreturnsvaluesthatmatchthekey

• Peerscanalsoinsert (key,value)peers

79

DistributedHashTable(DHT)

• DHT=distributedP2Pdatabase• Databasehas(key,value)pairs;

– key:ss number;value:humanname– key:contenttype;value:IPaddress

• Peersquery DBwithkey– DBreturnsvaluesthatmatchthekey

• Peerscanalsoinsert (key,value)peers

80

DHTIdentifiers

• Assignintegeridentifiertoeachpeerinrange[0,2n-1].– Eachidentifiercanberepresentedbynbits.

• Requireeachkeytobeanintegerinsamerange.• Togetintegerkeys,hashoriginalkey.

– eg,key=h(“GameofThronesseason4”)– Thisiswhytheycallitadistributed“hash” table

Howtoassignkeystopeers?

• Centralissue:– Assigning(key,value)pairstopeers.

• Rule:assignkeytothepeerthathastheclosest ID.

• Conventioninlecture:closestistheimmediatesuccessorofthekey.

• Ex:n=4;peers:1,3,4,5,8,10,12,14;– key=13,thensuccessorpeer=14– key=15,thensuccessorpeer=1

1

3

4

5

810

12

15

CircularDHT(1)

• Eachpeeronly awareofimmediatesuccessorandpredecessor.

• “Overlaynetwork”

CircleDHT(2)

0001

0011

0100

0101

10001010

1100

1111

Who’srespforkey1110?

Iam

O(N)messagesonavgtoresolvequery,whenthereareNpeers

1110

1110

1110

1110

1110

1110

Defineclosestasclosestsuccessor

CircularDHTwithShortcuts

• EachpeerkeepstrackofIPaddressesofpredecessor,successor,shortcuts.

• Reducedfrom6to2messages.• PossibletodesignshortcutssoO(logN)neighbors,O(logN)

messagesinquery

1

3

4

5

810

12

15

Who’srespforkey1110?

PeerChurn

• Peer5abruptlyleaves• Peer4detects;makes8itsimmediatesuccessor;asks8

whoitsimmediatesuccessoris;makes8’simmediatesuccessoritssecondsuccessor.

• Whatifpeer13wantstojoin?

1

3

4

5

810

12

15

•Tohandlepeerchurn,requireeachpeertoknowtheIPaddressofitstwosuccessors.• Eachpeerperiodicallypingsitstwosuccessorstoseeiftheyarestillalive.

87

P2PCasestudy:Skype(pre-Microsoft)

• inherentlyP2P:pairsofuserscommunicate.

• proprietaryapplication-layerprotocol(inferredviareverseengineering)

• hierarchicaloverlaywithSNs

• IndexmapsusernamestoIPaddresses;distributedoverSNs

Skypeclients(SC)

Supernode(SN)

Skypeloginserver

88

Peersasrelays• ProblemwhenbothAlice

andBobarebehind“NATs”.– NATpreventsanoutsidepeer

frominitiatingacalltoinsiderpeer

• Solution:– UsingAlice’sandBob’sSNs,

Relayischosen– Eachpeerinitiatessession

withrelay.– Peerscannowcommunicate

throughNATsviarelay

Summary.• Appsneedprotocolstoo

• Wecoveredexamplesfrom– TraditionalApplications(web)– ScalingandSpeedingtheweb(CDN/Cachetricks)

• InfrastructureServices(DNS)– CacheandHierarchy

• MultimediaApplications(SIP)– Extremelyhardtodobetterthanworst-effort

• P2PNetworkexamples89

Computer Networking Michaelmas/Lent Term M/W/F 11:00-12:00 ... · Computer Networking...

Documents

Transcript of Computer Networking Michaelmas/Lent Term M/W/F 11:00-12:00 ... · Computer Networking...