distributed systems mobile & iot compung · distributed systems mobile & iot compung rik...
TRANSCRIPT
DistributedSystems
Mobile&IoTCompu6ngRikSarkar
UniversityofEdinburgh
Fall2016
Distributed Systems, Edinburgh, 2016
MobileandUbiquitouscompu6ng
• Devices(computers)arecarriedbypeople(mobile)– Laptops,phones,watches…
• Theyareeverywhere– Carriedbypeople(mobile)– Embeddedintheenvironment
• Coffeemachines,cameras,sensorsforlightcontrol,elevators…
– Producelargeamountsofdata• Usage,sensing…
Distributed Systems, Edinburgh, 2016
Ubiquitous• Advantages:
– Therearecomputerseverywhere– Everythingis“smart”– Poten6allyusecomputa6onsonthesetomakethemevensmarter
• Challenges:– Therearemorethingstogowrong– Noteasytomakethingsworkwellcoherently– ConsistentplaUormsformanagingubiquitousdevicesdonotexist(yet)
– Devicesdonotinteroperateeasily
Distributed Systems, Edinburgh, 2016
Mobile
• Advantages:– Thesamedeviceiscarriedbytheperson–easytogiveconsistentservice
– Informa6onwhenever,wherevertheyneed– Deviceshavesensors–poten6alforsensingtheenvironmentandadap6ng
• Disadvantages:– Connec6vityischallenge:dataiscostly;networkdoesnotworkthesameway;mobilityinterfereswithcomunica6on
– LimitedbaYery:can’tdotoomuchcommunica6on– Howtomakeuseofsensors,notsowellunderstood
Distributed Systems, Edinburgh, 2016
Contextawarecompu6ng
• Adaptcomputa6onstothecircumstances– Timeofday– Istheuserpresent?– Isthephoneinhandorinpocket– Scanforwifionlywhenindoors– Turnoffringwhenincinema,mee-ng…– Recognizeac6vityandbringuprelevantinforma6on
– …
Distributed Systems, Edinburgh, 2016
Contextawarecompu6ng
• Adaptcomputa6onstothecircumstances• Basiccontextsareeasytoiden6fy,butitisnotalwaysclearhowtoadapt– Turndownvolumeatnight…butwhatifitisanimportantcall?
• Manycontextsareveryhardtodetectreliably
Distributed Systems, Edinburgh, 2016
Example:IndoorvsOutdoor
• Usesensorsonaphone,turnoffwifiscanningoutdoors
• Lightlevelsaremuchhigheroutdoors– Inday6meandifphoneisnotinpocket
• Citystreetsarenoisier• Cellularsignalstrengthsdropindoors
– Dependsonplace• Temperature,magne6cfield…
Distributed Systems, Edinburgh, 2016
Othercontextdetec6onexamples
• Usesoundtodetectuserinamee6ng• Detecttransportmode(walking,car,bus,tram..)– Usingaccelerometer
• Detectpresenceofotherusersnearbyfromwifiac6vity
Distributed Systems, Edinburgh, 2016
Contextdetec6on
• Generallyhard• Concernsaboutprivacy:youdonotwanttosendcontextinforma6ontoaserver
• Perhapsdistributedcomputa6oncanhelp– Usedatafrommanyphonestodetectcontext– Butagain,donotwanttosendalldatatoserver– Doasmuchofitaspossibleondevice–filter/processdataatsource
Distributed Systems, Edinburgh, 2016
Networkinginmobilesystems
• Difficulty:– Thenetworkgraphchanges– Anodeisnotalwaysconnectedtothesamerouter
• Examplesystem:Mobilead-hocnetworks– Ad-hoc:Unplanned– Devicessimplyconnecttonearbydevicesandroutepackets
– Alsoappliestosensornetworks
Distributed Systems, Edinburgh, 2016
Rou6nginadhocwirelessnetworks
• Findroutebetweenpairsofnodeswishingtocommunicate.
• Proac6veprotocols:maintainrou6ngtablesateachnodethatisupdatedaschangesinthenetworktopologyaredetected.
– Heavyoverheadwithhighnetworkdynamics(causedbylink/nodefailuresornodemovement).
– Notprac6calfornetworksthatchangefrequently
Distributed Systems, Edinburgh, 2016
Rou6nginadhocwirelessnetworks
• Reac6veprotocols:routesareconstructedondemand.Noglobalrou6ngtableismaintained.
• Moreappropriatefornetworkswithhighrateofchanges
– Adhocondemanddistancevectorrou6ng(AODV)– Dynamicsourcerou6ng(DSR)
Distributed Systems, Edinburgh, 2016
DynamicSourceRou6ng(DSR)
• NodeSwantstosendamessagetonodeD• Sini6atesaaroutediscovery• Sfloodsthenetworkwithrouterequest(RREQ)message
• Eachnodeappendsitsownidtothemessage
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscoveryinDSR
• Des6na6onDonreceivingthefirstRREQsendsaroutereply(RREP)
• RREPissentonarouteobtainedbyreversingtherouteinreceivedRREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
RouteDiscovery:RREQ
Distributed Systems, Edinburgh, 2016
When
• Whenalinkfails,anerrormessagewiththelinknameissentbacktoS.
• Sdeletesanyrouteusingthatlinkandstartsdiscovery.
Distributed Systems, Edinburgh, 2016
Routecaching
• Whenanodereceivesorforwardsamessage,itlearnsroutestoallnodesonthepath
• Advantage:– SmaynotneedtosendRREQ– IntermediatenodeonreceivingRREQ,canrespondwithcompleteroute
• Disadvantage:– Cachesmaybestale:Striesmanycachedroutesbeforestar6ngadiscovery.Or,intermediatenodesreturnoutdatedinforma6on.
Distributed Systems, Edinburgh, 2016
DSR:SummaryAdvantages:• Routescomputedonlywhenneeded–goodforchanging
networks• Cachingcanmakethingsefficient• DoesnotcreateloopsDisadvantages• En6reroutemustbecontainedinmessage:canbelongfor
largenetworks• Floodingcausescommunica6ontomanynodes• Stalecachescanbeaproblem• Notsuitablefornetworkswherechangesaretoofrequent
Distributed Systems, Edinburgh, 2016
AdhocOn-DemandDistanceVectorRou6ng(AODV)
• Maintainsrou6ngtablesatnodessothattherouteneednotbestoredinthemessage
• NoCaches:Onlyonerouteperdes6na6on
Distributed Systems, Edinburgh, 2016
AODVRouteDiscovery
• SourcefloodsthenetworkDistributed Systems, Edinburgh, 2016
AODVRouteDiscovery
• Othernodescreateparentpointer• AnodeforwardsaRREQonlyonce
Dst NxtHp Dist
S S 1
Dst NxtHp Dist
S S 1 Dst NxtHp Dist
S S 1
Distributed Systems, Edinburgh, 2016
AODVRouteDiscovery
• Othernodescreateparentpointer• AnodeforwardsaRREQonlyonce
Dst NxtHp Dist
S S 1
Dst NxtHp Dist
S E 2
Distributed Systems, Edinburgh, 2016
AODVRouteDiscovery
• RREPisforwardedviareversepath
Dst NxtHp Dist
S E 2
Dst NxtHp Dist
S S 1
Dst NxtHp Dist
S F 3
Distributed Systems, Edinburgh, 2016
AODVRouteDiscovery
• RREPisforwardedviareversepath• Createsaforwardpath
Dst NxtHp Dist
S E 2
D D 1
Dst NxtHp Dist
S S 1
D F 2
Dst NxtHp Dist
S F 3
D D 0
Dst NxtHp Dist
S S 0
D E 3
Distributed Systems, Edinburgh, 2016
Routeexpiry
• Apathexpiresifnotusedforacertain6me.• Ifanodeseesthatarou6ngtableentryhasnotbeenusedbythis6me,itremovesthisentry
• Evenifthepathitselfisvalid• Goodfornetworkswithfrequentchanges• Badforsta6candstablenetworks
Distributed Systems, Edinburgh, 2016
Cancreateloops
• AssumeC->Dlinkhasfailed,butAdoesnotknowbecausetheERRmessagewaslost
• CisnowtryingtofindpathtoD• ArespondssinceAthinksithasapath• Createsloop:C-E-A-B-C
Distributed Systems, Edinburgh, 2016
SequencenumbersinAODV
• IfAhasaroutetoD,Akeepsasequencenumber.
• Aincrementsthisnumberperiodically:tellshowoldtheinforma6onis
Distributed Systems, Edinburgh, 2016
Usingsequencenumbers
• Rule:sequencenumbermustincreasealonganyroute
Distributed Systems, Edinburgh, 2016
Sequencenumberruleavoidsloop
• Adoesnotreply,sinceitssequenceno.islessthanthatofC
Distributed Systems, Edinburgh, 2016
AODV
• Rou6ngtables,messagedoesnotcontainroute
• Freshroutespreferred• Oldunusedroutesexpire• Stalerouteslessproblema6c• Needssequencenumberstopreventloops• BeYerformoredynamic,changingenvironments
Distributed Systems, Edinburgh, 2016
Rou6nginadhocnetworks
• Reac6veprotocols:routesareconstructedondemand.Noglobalrou6ngtableismaintained.
• Moreappropriatefornetworkswithhighrateofchanges
– Adhocondemanddistancevectorrou6ng(AODV)– Dynamicsourcerou6ng(DSR)
• Needflooding– Inefficientinlargenetworks
Distributed Systems, Edinburgh, 2016
Geographicalrou6ng:Usingloca6on
• Geographicalrou6ngusesanode’sloca6ontodiscoverpathtothatnode.
Distributed Systems, Edinburgh, 2016
x
y
Greedy Routing: Forward to the neighbor that is nearest to the destination
Geographicalrou6ng
• Assump6ons:– Nodesknowtheirowngeographicalloca6on– Nodesknowtheir1-hopneighbors– Rou6ngdes6na6onsarespecified
geographically(aloca6on,orageographicalregion)
– Eachpacketcanholdasmallamountofrou6nginforma6on.
Distributed Systems, Edinburgh, 2016
Sensornetwork
• Sensorsenabledwithwireless– Cancommunicatewithnearbysensors– Communica6ontoserverrela6velycostly
• Lowpower,butlotsofdata– Notworthsendingeverythingtoserver
• Tryusethedatadirectlyinsidethenetwork– In-networkdistributedcompu6ng
Distributed Systems, Edinburgh, 2016
Problem:Howtofindtherelevantdata?
• Atouristinaparkasks• “Whereistheelephant?”• Outofallthesensors/cameraswhichoneisclosetoanelephant?
Distributed Systems, Edinburgh, 2016
Datacentricrou6ng• Tradi6onalnetworkstrytoroutetoanIPaddress• Findpathtothenodewithapar6cularID• Butwhatifwetrytofinddata,notspecificnodes?
• Alerall,deliveringdataistheul6mategoalofrou6ngandnetworks
• Datacentricstorage– Storagedependsonthedata(elephant,giraffe,song…)
• Datacentricrou6ng(search)– Routetothedata
Distributed Systems, Edinburgh, 2016
DistributedDatabase
• Informa6onProducer– Canbeanywhereinthenetwork– Maybemobile– Manyproducersmaygeneratedataofthesametype
• UserorInforma6onConsumer– Canbeanywhere– Maybemany
Distributed Systems, Edinburgh, 2016
DistributedDatabase:Challenges
• Consumerdoesnotknowwheretheproduceris,andviceversa
• Needtosearch:Mustbefast,efficient
Basicmethods:• Push:Producerdisseminatesdata• Pull:Consumerlooksforthedata• Push-pull:Bothproducer,consumersearchforeach-other
Distributed Systems, Edinburgh, 2016
Distributedhashtables
• Useahashonthedata:h(song1.mp3)=node#26
• Anyonethathassong1.mp3informsnode#26• AnyonethatneedsSong1.mp3checkswithnode#26
• UsedinpeertopeersystemslikeChord,pastryetc
Distributed Systems, Edinburgh, 2016
GeographicHashTables• Contentbasedhashgivescoordinates:– h(lion)=(12,07)
• Producersendsmsgto(12,07)bygeographicrou6ngandstoresdata
• Consumersendsmsgto(12,07)bygeographicrou6ngandgetsdata
Distributed Systems, Edinburgh, 2016
GHT
• Whatifthereisnosensorat(12,07)?
• Usethesensornearesttoit
Distributed Systems, Edinburgh, 2016
Faulthandling
• Whatifhomenodeadies?• Replicashavea6merthattriggersanewcheck• Anewnodebecomeshome
Distributed Systems, Edinburgh, 2016
GHT
• Advantages– Simple– Handlesloadbalancingandfaults
• Disadvantages– Notdistancesensi6ve:everyonehastogotohashnodeevenifproducerandconsumerareclose
– Ifadataisqueriedorupdatedolen,thatnodehasalotoftraffic–boYleneck
Distributed Systems, Edinburgh, 2016
RumorRou6ng
• Producer:Senddataalongacurveorrandomwalk,leavedataorpointersonnodes
• Consumer:Routealonganothercurveorrandomwalk,hopetomeetdataorpointer
Distributed Systems, Edinburgh, 2016
Rumorrou6ng
• Eachnodemaintainsalistofevents• Addseventsastheyhappen
• Agents:Packetsthatcarryeventsinthenetwork– Aggregateeventsofeachnodetheypassthrough
• Agentsmoveinrandomwalk.From1-hopneighborsselectonethathasnotbeenvisitedrecently
Distributed Systems, Edinburgh, 2016
• D
Distributed Systems, Edinburgh, 2016
Mobile,Ad-hocandSensornetwork
• Adifficultmodel–leastinfrastructure,lowpowernodes,communica6on/computa6onexpensive
• Noten6relyrealis6c• However,itmakesleastnumberofassumptons
– usefulasabasisfordevelopingdistributedprotocols/algorithms
– Whichcanthenbeenhancedusingavailableinfrastructureinspecificcases
Distributed Systems, Edinburgh, 2016