*** Hvorfor er vi interessede i strukturerede P2P netværk?
- Ofte bruger ustrukturerede P2P netværk flooding til at finde ting
- Man kan også bruge Expanding Ring eller Random Walk
- Gnutella viser sig at bruge en powerlaw graph (sikkert fordi nogle enkelte noder sender mere ud)
- Random walkers er ret nice, men vi kan stadigvæk ikke helt garantere noget som helst, da vi ikke aner hvor data er placeret. Derfor bruger vi blandt andet strukturerede netværk i stedet!
- Det kommer vel an på om overheadet ved at holde strukturen er acceptabelt ift reduktion i søge tid og besked overheadet ved at søge i et ustruktureret netværk
- Strukturerede P2P netværk kan ofte give en form for Load balancing, bedre skalering, bedre søgehastigheder
- Dette opnås ved at bruge en DHT og lade noderne hver stå for en del af netværket, så ting bliver specifikt associeret med enkelte noder
*** Chord
**** Strukturen i Chord
***** En stor cirkel
***** Consistent hashing (IDs)
- Et ID er baseret på en hash, f.eks. SHA-1, af noders IP-adresse eller ved at hashe nøgler for ting.
- Consistent Hashing er en teknik der betyder at hver node kun kommer til at indholde O(log N) ting
- Det er basalt set bare et resultat at at tingene bliver placeret rundt omkring på cirklen, der i øvrigt er 2^m stor. Vi hasher til ID af størrelsen m.
- Modulo er blot nødvendigt således vi kan hoppe fra slutningen af cirklen til starten!
**** At søge i Chord
- En naiv måde at query på, ville være bare at loope igennem alle noder
- I stedet kan man bruge hver nodes finger tables
- Man kigger efter succ(k), hvis k er id'et for tingen
- Finger tables er opbygget på en sådan måde, at en søgning tager O(logn) i stedet for O(n)
- Man bruger finger tables ved at node n bare tager den node i sit finger table, der har er den tætteste successor eller predeccesor for ID k.
***** Fingertables
- Indholder m elementer, m er bit størrelsen
**** At joine Chord
- Af en eller anden årsag bliver predecessoren brugt når en node joiner. Not quite sure why.
- Vi har to invarianter vi ønsker at vedligeholde
1) Hver node's succ er holdt ved lige
2) For hver nøgle k, succ(k) skal håndtere k
- Desuden ønsker vi også at holde Finger Tables halvvejs fornuftige, for at vedligeholde at man kan søge ordentligt
- Hvis node n vil joine og kender node n', så beder n n' om at finde predecessor og fingers for node n. Hvis n' var nødt til at naivt spørge om alle m fingers, ville det tage for lang tid, der udregnes nogle ting med nogle intervaller, for at reducere den forventede tid til O(log N), således en node f.eks. kan ende som flere fingers nemmere og hurtigere.
- De noder der skal have den nye node n i deres finger tables, findes ved at gå baglæns i relativt store hop og så spørge om predecessors. Det er derfor den skal holdes opdateret.
- Til sidst skal n have sine nøgler. Den kan kun indholde nogle af de nøgler som noden der er succ(n) har nu, så node n skal kun spørge denne node.
- Alting her tager i øvrigt O(log^2(n)) <- Hvad end det så betyder
**** Hvad sker der hvis en node forsvinder?
- For at queries kan fortsætte, holder alle nodes en succ-list opdateret for denne nodes r tætteste succs, så hvis et kald fejler til en node, kan de kontakte dennes succ i stedet.
- Ydermere, der kaldes i ny og næ en stabiliseringsmetode. Dennes formål er at holde succs opdateret, tjekke predecessors og opdatere finger tables. Det er via denne fix_fingers metode, at de nye succs vil blive opdaget.
- Dette betyder dog, at hvis der ikke er replication og sådan, så vil den forsvundne nodes nøgler umiddelbart gå tabt.
*** Kademlia
**** Kritik af Chord
- Finger tables kigger kun fremad, så man lærer intet af beskeder der ankommer
- Man er ydermere nødt til at sætte ekstra kontrol beskeder. Man kan ikke bruge queries til noget ift status
- Relativt rigid søge struktur, eftersom en node kun kan spørge den ene node man har i sin finger table for en given værdi af i
**** Strukturen i Kademlia
- Et stort binært træ
- Buckets
- 160bit ID for både noder og filer (Bare en hash, as is tradition)
- XOR for distance mål (Så ID1 XOR ID2 = distancen mellem ID1 og ID2)
- Ingen konkret idé om geografisk lokation, eftersom IP'en hashet ingenting giver.
***** XOR
- XOR distance målet er smart, fordi XOR er symmetrisk, så d(X,Y) = d(Y,X)
- dette betyder at hvis vi får en request fra en node, som vi ikke kendte på forhånd, så kan vi med fordel bruge den information, fordi vi bare kan udregne distancen på noden nu her, givet dens ID. Desuden er oddsene at noden er langt væk, eftersom man vil forsøge at tage så lange hop som muligt.
- Desuden får vi trekants-uligheden, hvilket giver os at den mest direkte vej vi kender, altid vil være den hurtigste. Altså. Det giver ikke mening at tage et lille hop fra A til B og så fra B til C, hvis vi kan hoppe fra A til C.
**** Node state
- Hvis hashing funktionen er SHA-1, så er der 160 bit
- For 0 <= i <= 159 opretholder hver node en liste a IP adresse, UDP port og Node ID for k noder mellem distance 2^i og 2^i+1 fra den selv. Disse lister hedder k-buckets.
- Giver i princippet en least-recently-seen eviction policy, bortset fra noder i live bliver aldrig fjernet
**** At søge i Kademlia
***** Fire forskellige kald der er relevante
***** Find en Node
- Tager et ID (ofte 160-bit) some argument. Modtageren af et find_node kald returnerer de k tætteste noder den kender. Den skal returnere k, så hvis noden findes, så er noden deriblandt.
- Kaldet er rekursivt og går ud til alpha noder. Hvis alpha er 1, så er det ret meget ligesom Chord.
- Når nogle af disse alpha noder svarer med deres k bedste bud, så rekurserer vi ud og vælger alpha af de k og spørger dem.
- Hvis en runde hvor vi spørger alpha ikke finder nogen der er tættere på, så spørger vi i stedet alle k
- Dette stopper når alle k har svaret eller ikke kan hjælpe.
***** Find en "Værdi"
- Fungerer stort set ligesom find_node, men i stedet stopper vi så snart vi modtager det rigtige svar.
- Alting er unidirectional, altså, vi spørger nogle specifikke, får svar fra dem, spørger nogle nye. Vi vælger alting de tætteste alpha, så derfor kan caching klart udnyttes her.
- Når en lookup har success, så gemmer requesteren (key,value) på den tætteste node den fandt, der ikke havde nøglen i forvejen. (Ting der er cachet udløber baseret på distancen imellem de to noder)
***** Gem data
- Brug find_node til at finde de k tætteste på nøglen og bed opbevare et (key,value) par.
- Ting bliver republished i ny og næ, for at de bliver holdt i live.
***** Ping
- Bliver bare sendt til specifikke noder.
- Kan bruges til at tjekke om noder er i live, ift at holde ens buckets i live.
***** Refreshing af buckets
- Desuden refresher noder også lige buckets, hvis de ikke har kontaktet denne bucket i lang tid.
**** At "joine" kademlia
- Man skal kende en node i forvejen (GLHF)
- Hvis node u vil joine og u kender node w, så indsætter node u node w i den passende k-bucket.
- u laver så et node lookup på sig selv (her udnyttes symmetrien af XOR, fordi nu lærer de andre noder at kende u), og vil af dette lære at kende sine k naboer.
- u opdaterer dernæst sine egne buckets via find_node kald.
- I forbindelsen med disse opdateringer, så udfylder node u sine egne buckets og bliver også indsat i andre noders buckets.
**** Hvad sker der hvis en node forsvinder?
- Buckets opdateres ret ofte i Kademlia pga symmetrien, så hver gang man modtager en query, er der potentiale for at opdatere.
- Derfor opdages det hurtigt, hvis en node ikke svarer længere.
- Den fejlende node kan så smides ud af de forskellige buckets og en ny kan hentes ind fra replacement listen.
*** Pastry er i øvrigt også en ting
- Bruger et circular ID space ligesom Chord
- Hver node har tre lister. Leaf set, neighbourhood set og et routing table
- Leafset indholder L/2 ID'er der kommer lige før node n og L/2 ID'er lige over.
- Routing table indholder et element for hver bit i ID'et. Så 128 bits = routing table af størrelse 128
- Routing tager forventet O(logn) hop (giver intuitivt mening, eftersom du altid vil komme én bit tættere på
** Mobile Ad-hoc Networks and Wireless Sensor Networks
*** Hvad er specielt ved mobile ad-hoc netværk
**** Hvad er ad-hoc netværking overhovedet?
- Vi ønsker at transportable enheder skal kunne dele information og samarbejde.
- Ingen infrastruktur, base stations, wired links eller noget
- Udfordringer er:
1) Begrænset kommunikations rækkevide
2) Begrænset båndbredde
3) CPU kraft
4) Begrænset opbevaringsplads
5) Batteri liv
6) Transportable enheder bæres sjovt nok rundt, formentligt høj churn rate og skiftende forbindelser.
- Normalt forventer strukturerede netværk at topologien er nogenlunde stabil og det samme gælder båndbredden
- Systemer som Kademlia kan godt håndtere at noder forsvinder, f.eks. har Kademlia sin k-variable, der er sat efter at man håber at k noder ikke fejler indenfor kort tid, men det er der markant højere risiko for i et ad-hoc netværk. Derfor kan det også være svært at overhovedet skabe en struktur.
**** Hvad bruges MANETs så?
- Basically på grund af de udfordringer nævnt lige før.
- Fjerntliggende områder, uplanlagt opsætninger
- Militær hvor infrastruktur måske er ødelagt
- Infrastruktur er måske bare for dyrt at opsætte.
**** Udfordringer ved wireless links
- De er broadcast (så alle kan lytte med)
+ Ret nederen for sikkerhed
- Can be uni-directional (måske pga styrke?)
- Signal styrke kan variere meget
*** Routing
- En graf hvor edges er længder
- Djikstra and Bellman-Ford designede algoritmer der fungerer bedst i stabile netværk
- Derfor skal der ændres lidt på tingene
- Kort ting, vi har både Link State og Distance Vector.
**** Link State
- Alle nodes og vægte på edges er kendt for allen oder
- Kan f.eks. bruges til at skabe Djikstra og SSSP
- Skalerer dårligt, eftersom beskeder skal sendes ud til alle, når en update til netværket sker.
- Proactive
**** Distance Vector
- Ingen "global sandhed" er nødvendig.
- Noderne samarbejder om at udregne den korteste vej
- Skalerer bedre, eftersom man ikke er nødt til at sende beskeder ud til alle, ved hver update til netværket
- Reactive
- Så hvis man SKULLE vælge imellem Link State og Distance Vector til MANET, så skal man vælge DV.
**** Der er fem ting man skal være opmærksom på
1) Minimal control overhead (limited energy and bandwidth)
2) Minimal processing overhead (small processors)
3) Multihop routing capability (no infrastructure, nodes must act as routers)
4) Dynamic topology maintenance (high churn rate)
5) Loop prevention
**** To slags routing + sådan lidt en hybrid ting (Den med zoner)
- Reactive
- Proactive
***** Proactive
- Noder vil dele routing information med hinanden periodisk eller når en opdatering til netværket sker
- Dette leder til at en node altid vil have en rute til en anden node, hvis denne node skal sende noget.
- Sådan lidt en afslappet form for Link State
***** Reactive
- Såkaldte on-demand protokoller
- Holder ikke styr på routing tables hele tiden
- En rute er opdaget, når der er brug for den
***** Hybrid
- Bruger sjovt nok begge ting
**** En proactive metode er Destination-Sequenced Distance Vector (DSDV)
**** Optimised Link State Routing er proactive
**** Dynamic Source Routing er reactive
**** Zone Routing Protocol er hybriden
**** En reactive metode er Ad-Hoc On-Demand Distance Vector (AODV)
- Kræver symmetriske links
- Denne bliver også brugt til SPAN + BECA/AFECA senere
- Reactive
- Routes are acquired when they are needed
- Assumes symmetrical links
- Uses sequence numbers to avoid loops
***** Path Discovery
- When a node wishes to send something, a path discovery mechanism is triggered
- If node x wishes to send something to node y, but it doesn't know a route to y, a route request (RREQ) message is send to x's neighbours. The RREG contains:
1) Source address
2) Source seq no
3) Broadcast id - A unique id of the current RREQ
4) Destination addr
5) Destionation seq no
6) Hop count - The number of hops so far, incremented when RREQ is forwarded
- (source addr, broadcast id) uniquely identifies a RREQ. This can be used to check if RREG has been seen before.
- When RREQ is received, two actions can be taken
1) If a route to the destination is known and that path has a sequence number equal or greater than the destination seq no in the RREQ, it responds to the RREQ by sending a RREP (route reply) back to the source.
2) If it doesn't have a recent route, it broadcasts the RREQ to neighbours with an increased hop count.
- When a RREQ is received, the address of the neighbour from whom this was received, is recorded. This allows for the generation of a reverse path, should the destination node be found.
- RREP contains source, destination addr, destionation seq no, the total number of hops from source to dest and a lifetime value for the route.
- If multiple RREPs are received by an intermediary node, only the first one is forwarded and the rest are forwarded if their destination sequence number is higher or they have a lower hop count, but the same dest seq no.
- When the RREP is send back to the source, the intermediary nodes record which node they received the RREP from, to generate a forward path to route data along.
***** Sequence number shenanigans
- On receiving an update message, these rules apply:
1) If the sequence number of the updated route is higher than what is currently stored, the route table is updated.
2) If the numbers are the same, the route with the lowest cost is chosen.
- If a link break is noticed, the noticer sets the cost to be inf to that node and increments the gone node's sequence number by one and sends out an update.
- Thus, the sequence number is odd, whenever a node discovers a link breakage.
- Because of this, any further updates from the disappeared node, will automatically supersede this number
- This makes DSDV loop free
- Sequence numbers are changed in the following ways
1) When a line breaks. The number is changed by a neighbouring node. Link breakage can't form a loop
2) When a node sends an update message. The node changes its own sequence number and broadcasts this. This information is passed on from the neighbours.
- Thus, the closer you are, the more recent sequence number you know.
- When picking routes, we trust the routers who knows the most recent sequence number, in addition to picking the shortest route.
***** Evaluation
- Tries to minimise control traffic flowing, by having nodes only maintain active routes.
- Loops prevented with sequence numbers
- No system wide broadcasts of entire routing tables
- Every route is only maintained, as long as it's used. It has a timeout and is discarded, if this timeout is reached.
- Path finding can be costly, as a long of RREQ gets propagated through the network
- Eftersom der ikke er system-wide broadcasts når netværket ændrer sig, er man nødt til at gøre det når en ny rute skal findes. Dette kan være dyrt og det forårsager beskedduplikationer.
- Expanding ring algorithm can help control the amount of messages going out, but if the receiver isn't close, this can be even more costly than the standard way
- Upon link failure; Upstream neighbour sends RREP with seq. no. +1 and hop count set to infinity to any active neighbours—that is neighbours that are using the route.
**** Promiscious mode er måske en ting, hvis der er tid til at snakke om Dynamic Source Routing
- Reactive
*** Spar Strøm!
**** To hovedtilgange
1) Power-save
2) Power-control
***** Power-control
- Man bruger mindre strøm, jo kortere man skal sende signalet og det stiger ofte ikke lineært, så jo længere du skal sende des meget mere dyrere bliver det
- Derfor vil man hellere sende flere gange end sende en meget lang gang
***** Power-save
- Man lader noder sove når de ikke skal lave noget arbejde
- Dette betyder at denne slags protokoller er nødt til:
1) Sende beskeder flere gange for at være sikker på at beskeden når frem
2) Alle noder må ikke sove på samme tid, således arbejdet kan fordeles på de vågne noder
- Så disse protokoller beskriver måder at maksimere mængden af tid noder kan sove, samtidig med de bibevarer at ting kan sendes rundt.
**** IEEE bruger sådan en pudsig måde intervaller hvori der besluttes hvem der skal sende, modtage og sove
**** BECA/AFECA
- Måder at beregne på hvor længe noder må sove.
***** BECA
- Bliver brugt til at beregne hvor lang tid en node skal sove
- Bliver brugt til at beregne hvor mange retransmissions man skal udføre
- Noder har tre states; sovende, lyttende og aktiv
- En del regler opsat for at sørge for at beskeder ikke går tabt:
1) Mængden af tid man skal forsøge at gensende beskeder
2) Mængden af tid man må sove er bundet af mængden af tid hvori man forsøger at gensende, samt en parameter k
3) Mængden af forsøg man skal bruge på at gensende, skal være større end k+1
4) Mængden af idle tid skal være større end eller lig mængden af tid man skal forsøge at gensende
- k = 1 er fint.
- Ellers ønsker man at finde en fin balance med k, da en høj k værdi gør at ting sover længere, men det giver også højere latency ift hvornår ting når frem, samtidig med en lav k værdi gør at systemet kører hurtigere, men ting sover ikke lige så lang tid.
***** AFECA
- Samme idé som med BECA
- AFECA tager tætheden af noder in mente, når sove-tiden skal udregnes.
- Altså er sove-tiden nu variabel efter hvor stor tæthed der er rundt om den enkelte node.
- Begrundelsen er, at hvis tætheden er høj, vil en anden node formentligt kunne route i stedet. Det er selvfølgelig lidt uheldigt, hvis du er modtager af beskeden, men det bliver der ikke nævnt noget om.
- Mængden af gange man forsøger at gensende er også nødt til at blive gjort variabel, ellers vil beskeder oplagt gå tabt.
- AFECA giver en forventet besparelse i stedet, eftersom man ikke ved hvor et neighbourhood de enkelte noder har, på forhånd.
**** SPAN
- Ikke en routing protokol
- Ikke en måde at bestemme på hvor lang tid ting må sove.
- En metode man kan påføre andre power saving algoritmer.
- Dette er fordi SPAN ikke faktisk udregner hvornår ting skal sove og sådan, men blot hvem der kan sove!
- SPAN bruger en idé om "connected dominating sets (CDSs)", forbundne dominerende sæt??
- En CDS er en forbunden delgraf S af en graf G, således at alle noder u i G enten er i sættet S eller kan nås fra node i S.
- Så alle noder kan nås fra en CDS.
- Idéen om CDS, betyder at vi kun behøves bruge disse noder som routere i netværket
- Noder i CDS hedder koordinatere.
- Dvs. ikke-koordinater noder skal ikke bruges til routing og kan derfor få lov til at sove
- SPAN definere en måde at vælge koordinator noder på, baseret på batteri levetid og nodes "utility".
+ Utility definerer nodes "rækkevide" i netværket. Dvs. hvor mange noder der kan nås fra denne.
- Ligeledes defineres der også en tid hvori de enkelte noder er koordinatorer.
- De potentielle koordinator noder har brug for information om sine naboer og sine to-hop naboer, således vi kan finde ud af om vores to-hop naboer er koordinatorer. Denne information indsamles pro-actively via HELLO beskeder.
*** SPAN + BECA/AFECA
- Så vi har hvilke der må sove for at systemet stadigvæk kan køre rundt
- Vi har en routing protokol og power saving algoritme i form af BECA + AODV
- Fordi koordinator sættet i SPAN ofte ændrer sig, vil en masse ruter forsvinde i AODV. En udvidelse til AODV kunne være at tillade noder at have flere alternativer ruter, der kunne prøves, inden man giver op og må bygge en ny rute.
- Alle MANET protokoller har brug for en idé om sit nabolag. Dette findes normalt ved at periodisk sende HELLO beskeder ud.
- SPAN skal også sende sådan HELLO beskeder ud for at bruge sin koordinator udvælgelses algoritme. Disse HELLO beskeder kan piggy-backes på de HELLO beskeder AODV bruger.
- Dernæst lader vi blot koordinatorer være de eneste der kan forware RREQ beskederne i AODV
- Måden AODV bygger sine veje frem og tilbage, passer fint til at det alligevel kun er koordinatorer der sender beskeder videre i RREQ og RREP, så stien vil også blot blive bygget på dem.
- Der er yderligere ingen grund til at retransmitte beskeder, eftersom det alligevel kun er koordinatorer der modtager dem og disse må ikke sove.
*** Wireless Sensor Networks
**** Lige kort, hvorfor er det anderledes?
- MANETs are intended to handle ad hoc communication from one arbitrary node to another
- Wireless Sensor Networks (WSN) is about sensing, collecting, and shipping data in one direction—the sink
- Består normalt af en pokkers masse sensorer der ofte er relativt tæt på hinanden
- Random deployment skal være muligt. Dette betyder der skal være en form for selv-organiserende opførsel.
- Sensor noder har ofte en lille processor, så de kan udføre simple beregninger og dermed kun skal sende det nødvendige data, i stedet for alt det de opsamler
- Der er en del forskelle mellem ad-hoc netværk og sensor netværk
1) Der er ofte markant flere sensorer i et sensor-netværk, end der er noder i et ad-hoc netværk
2) Sensor nodes er meget dense deployed
3) Sensor nodes kan nemt risikere at fejle
4) Topologien skifter ofte i et sensor netværk
5) Sensor nodes har meget begrænset strøm, regnekraft og hukommelse
6) Sensor nodes har ikke nødvendigvis et globalt ID
7) Sensor nodes broadcaster normalt, hvor de fleste ad hoc netværk bruger point-to-point kommunikation
**** Hvad skal man overveje når de skal designes?
- Ting man skal overveje
1) Fault tolerance
2) Scalability
3) Production costs
4) Operation environment
5) Sensor network topology
6) Hardware constraints
7) Transmission media
8) Power consumption
*** Routing i WSN
**** Energy-concerned routing
***** Maximum Available Power (PA) Route
- Ruten med maksimum PA er valgt.
- Den totale PA er udregnet ved at summere PA fra hver node over en rute
- Man skal ikke medregne ruter hvor vi tager en normal rute, men så tager en omvej for at forhøje den totale PA, da vi kunne risikere at bare gå igennem alle noder, da dette oplagt vil give den højeste PA
- Kan være brugbar, men det minder ret meget om at den der er stærkest bære mest
***** Maximum Energy (ME) Route
- Den rute der bruger mindst energy til at sende pakkerne mellem sinken og sensor noden
- Energien brugt, er betegnet som det der står på kanterne mellem noderne, altså kosten for at tage en kant
***** Minimum Hop (MH) Route
- Den rute med færrest hop (no shit sherlock)
- ME og MH vælger samme rute, hvis kosten på alle kanter er ens.
***** Maximum minimum PA node route
- Den rute hvor den mindste PA på en node, er større end den mindste PA på de andre ruter. Det vil altså sige at den svageste på den rute vi vælger, er stærkere end den svageste på de andre ruter vi havde mulighed for.
- Altså, hvis en node er meget svag på en rute med ellers stærke noder, så vil den node bliver opbrugt meget hurtigt. Denne metode at vælge rute på sikre sig at dette ikke sker.
**** Data-centric routing
- I data-centric routing snakker man om at være interesseret i specifik data.
- Dette kan gøres på flere måder
1) Sinken broadcaster hvilket data den er interesseret i
2) Noderne broadcaster de har noget data. Metadata er billigt at sende.
- Kræver attribut-baseret navngivning. Her er brugere ofte mere interesserede i at spørge om en specifik attribut ved et fænomen, i stedet for bare at spørge en specifik node.
+ F.eks. kan man spørge om områder hvor temperaturen er over 35 grader celcius, i stedet for at spørge en enkelt node hvor varmt det er ved den
- I data-centric routing er data-aggregation ofte vigtigt
**** Data-aggregation
- Når data bevæger sig fra sensor noder til sinken, så kan dette data blive samlet ved knudepunkter, således der skal sendes færre beskeder. Dette er meget mere effektivt, end hvis alle noderne skulle sende beskeder.
- Det fungerer således at et sensor netværk bliver et reversed multicast tree hvor sinken spørger sensor noderne om en eller anden attribut ved et fænomen. Data der kommer fra de forskellge sensor noder bliver så samlet og aggregeret, eftersom de alligevel er om den samme attribut, når de når den samme routing node på vej tilbage til sinken.
- Det kan også hedde data fusion
** Cloud Computing
*** Hvad er cloud computing?
- Cloud computing er en model der tillader on-demand computing, man altid kan tilgå og stiller til rådighed en stor pool af computerkraft, der kan konfigureres til ens formål med minimal management, givet nogen hoster det.
- Dette betyder man ofte kan skalere hvor meget compute-power man skal bruge og i nogle tilfælde kan cloud computing selv tilpasse mængden af kraft der skal bruges.
- Ofte bred adgang til sin regnekraft, da det normalt kan tilgås som server
**** Hvorfor har man brug for cloud computing?
- Cloud løsningen giver en skalerbar løsning, hvilket der er brug for ift IoT, da det kan flukturere meget, hvor mange IoT ting der lige er eller hvor mange man skal bruge.
- Det kan bruges til opbevaring, analyse, netværk og adgang.
- Clouden er dyr og kan have latency problemer, eftersom man skal sende signaler markant længere væk for at få lavet en beregning og derefter vente på svar, for at reagere på ting.
- Man kan udføre noget Edge Computing (det vil sige, beregne ting på selve tingen) i stedet.
- En kombination af disse to er nice, da man kan bruge clouden til nogle ting og selve IoT enheden til resten.
*** Hvad er Fog Computing?
- Pioneret af Cisco
- Det er stadigvæk ikke noget der gøres direkte på IoT enheden, men det er rykket markant tættere på, end Clouden.
- En række karakteristika for Fog Computing:
1) Lav latency og lokations opmærksomhed
2) Geografisk fordelt
3) Mobilt
4) En meget stor mængde af noder
- Plus lidt flere, men pointen er at Fog Computing er overalt, har lav latency og opfører sig ens overalt.
- Formålet er ikke at one-uppe Clouden, men at opnå en form for symbiose med det.
**** Hvilke problemer løser det?
- Cloud computing kan have problemer med latency, på trods af man forsøger at have store data centre i forskellige lokationer
- Dette er et problem for IoT, eftersom de ofte kræver at kunne være mobile, distribueret geografisk samt at være klar over lokation og have lav latency.
- Clouden kan kun klare mobilitet og adgang overalt
- Fog Computing er defor svaret, ved at være en cloud tættere på jorden (derfor navnet!)
**** Hvordan løser det disse problemer?
- Typisk placeret ved edgen af netværket (det vil sige ofte der hvor tingen alligevel går på nettet, netværks tårne, mobile biler og sådan)
- Cloud Computing er godt til batch processing, men IoT og interaktive enheder har ofte brug for real-time interactions.
- Support for analyse og interplay med Clouden. Fog er ofte i den position at skulle ingeste og processere data tættere på sourcen, men kan derefter sende ting videre til Clouden.
**** Eksempel på hvad det kan bruges til?
- Streaming af data der interageres med, kræver lav latency
- Wireless Sensor Networks og Wireless Sensor Actuator Networks
+ Constrained ift sendestyrke osv, så man kan med fordel have en Fog Computing node tæt på, der så står for alt snak med Clouden.
**** Konklusion
- While Fog nodes provide localization, therefore enabling low latency and context awareness, the Cloud provides global centralization. Many applications require both Fog localization, and Cloud globalization, particularly for analytics and Big Data.
- Fog collectors at the edge ingest the data generated by grid sensors and devices. Some of this data relates to protection and control loops that require real-time processing (from milliseconds to sub seconds).
- This first tier of the Fog, designed for machine-to-machine (M2M) interaction, collects, process the data, and issues control commands to the actuators. It also filters the data to be consumed locally, and sends the rest to the higher tiers
*** EdgeIoT
**** Intro
- En fleksibel og effektiv IoT arkiktektur baseret på Fog Computing og Software Defined Networking
+ Vi kan styre netværket og routing med software
- Så det her skal bruges til at modtage den rå data strøm fra IoT enheder, der kan bruges til at lokalt samle, klassificere og analysere denne.
- Et svært problem, eftersom meget af data fra IoT enheder som wearables kan have privat information og bevæger sig rundt meget
**** Hvordan?
- Man kan udnytte eksisterende base stations for netværk, eftersom disse i forvejen giver høj coverage og er distribueret overalt.
- Vi kan tilføje forskellige wireless interfaces, således man kan forbinde til forskellige potentielt proprietære protokoller
- De kan også sidde ved core netværket, således flere base stations kan dele den samme fog node
- Det er her SDN og noget der hedder OPenFlow bruges til at tilføje mere kontrol over hvordan routing foregår.
- Herfra kan Fog Nodes offloade arbejde til Clouden, hvis dette kan gøres uden tab af latency osv.
- Ydermere kan IoT applikationer blive deployed direkte på de her Fog nodes.
**** Hvordan løses privatheds problemet?
- Hver bruger har en proxy VM, der er situeret ved den nærmeste Fog Node.
- Dette giver fleksibel storage og compute power
- IoT enheder eget af brugeren, er registreret til denne VM, der står for indsamlingen af data
- Denne VM kan ydermere være dynamisk, så hvis brugeren bevæger sig væk fra Fog noden og en ny bliver den nærmeste, så kan Proxy VMen rykke med.
- Kan også splitte, hvis man har brug for IoT enheder derhjemme stadigvæk har en proxy VM.
- Der findes også applikations VM. Det er disse der modtager information fra Proxy VMs
- Disse applikations VMs kan deployes på tre forskellige måder; lokalt, remote eller add-on.
***** Lokalt er på Fog Noden ved en Base Station
***** Remote er en i Clouden og bliver brugt til at indsamle information fra potentielt større områder
***** Add-on er event-triggered og bliver deployet, givet et event.
** BitTorrent
*** Hvad er BitTorrent?
- Fil distribuerings protokol
**** Hvorfor bruge BitTorrent?
- Det kan bruges til at downloade store filer (endda lovligt)
- Det kan bruges til at dele filer
- Smart fordi en fil bliver distribueret over flere peers (givet de downloader denne)
+ Dette medfører at filen ikke kun kan fås et sted og den kan derfor stadigvæk distribueres, selv hvis den oprindelige deler forsvinder)
*** Hvordan fungerer BitTorrent?
**** Torrent Files
- Man definerer torrent filer der indholder metadata og tracker information enkodet i et specifikt format der hedder bencoding
- Formålet er, man kan dele en torrent fil og denne kan så bruges til at downloade filen
- Normalt indholder de information til trackeren der koordinerer torrenten, men man kan godt bygge uden om dette, ved at requeste filen direkte hos forskellige peers, som vi f.eks. gjorde i vores system
- Metadataen indholder altid navn, længden på de forskellige stykker, hashen for de enkelte stykker og længden af hele filen.
**** Peers
- BitTorrent bruger Kademlia til at organisere sine peers
- I Kademlia må peers selv vælge deres ID på 160-bit
- Der er dog forslag i BitTorrent Extension Proposals om at ens ID nu skal være en hash af ens IP og Port. Dette vil effektivt ødelægge nogle af de angreb der kommer senere.
- Når man får en liste af peers fra trackeren, så forbinder man bare til disse. I vores projekt gjorde vi det manuelt uden om trackeren, fordi vi også havde en idé om hvem filen lå hos, når vi loggede at filen eksisterede.
***** Seeders
- Peers der har downloadet filen helt
- Peers skifter løbende fra leachers til seeders, som de downloader filen
- Ofte er det en god gestus at lade ens torrent klient kører lidt længere efter man har downloadet filen.
***** Leachers
- Peers der stadigvæk downloader
- Selvom man er en leacher, så deler man stadigvæk de dele af file man allerede har downloadet
**** Tracker
- En centraliseret komponent som bliver brugt for at finde peers
- Den eneste centraliserede komponent
- Bliver brugt til at bootstrappe systemet
- Vælger en liste af peers helt tilfældigt
- Lavet intet andet, så hjælper på ingen måde med downloading processen
- Når man normalt henter en .torrent fil, så kontakter man trackeren der står listet deri og får så en liste af peers tilbage, som er valgt tilfældigt
- Bortset fra dette, så kontakter man kun lige trackeren for at sige man er i live.
**** Swarm
- En samling af peers der sammen downloader/deler en fil
**** Peer Distribution
**** Piece Selection
- Et bitfield der beskriver hvilke filer du har og hvilke du mangler. Blot en streng af bits, så 0 hvis du ikke har filen, 1 hvis du har.
- Dette bitfield sendes ud til ens neighbourhood. Dette tillader de forskellige peers at downloade fra hinanden, da alle nu ved hvad alle har.
- Forskellige måder man kan vælge og fordele på:
***** Generalt tilfældigt
- Man bare downloader tilfældigt hvad man lige mangler.
- Kan fungere ok, fordi delene bliver fordelt godt ud over swarmen.
- Man risikerer nogle dele forsvinder
***** Strict Priority
- Always finish a particular piece, before ordering subpieces from another
- Essentially what we do in SilverStream. This allows for streaming.
***** Rarest First
- When selecting which piece to start downloading next, peers generally download pieces which the fewest of their own peers have first, a technique we refer to as ’rarest first’.
- It also makes sure that pieces which are more common are left for later, so the likelihood that a peer which currently is offering upload will later not have anything of interest is reduced.
- It also makes it easier for the seeder, as leachers will see the others already have the old pieces and as such they will download the new pieces from the seed.
- Additionally, if the seeder stops seeding, it's important that the entire file is circulating still. This is helped by the leachers downloading the "rare" pieces first, such that together, they have the entire file.
***** Random first piece
- An exception to rarest first is when downloading starts. At that time, the peer has nothing to so it’s important to get a complete piece as quickly as possible.
- Rare pieces tend to only be on one peer, so these would be downloaded slower, than pieces on multiple peers.
- As such, random pieces are selected until a complete piece is made. Then rarest first is used.
***** Endgame mode
- Used in the end when a few sub-pieces are missing
- Just starts broadcasting what it's missing, in an attempt to finish
- In practice doesn't waste much bandwidth, as endgame is short.
**** Tit-for-tat
- Man skal give filer, for at kunne få filer.
- Man giver alle peers i ens neighbourhood to bits.
1) Interesseret/Uinteresseret i ens filer
2) Choked/Unchoked beskriver om vi pt. choker denne peer
- Man sender choke, unchoke, interesseret og ikke interesseret til hinanden
**** Choking
- BitTorrent laver ingen central resource allokering, så hver peer er ansvarlig for at maksimere sin egen download rate
- Choking er er midlertidigt afslag på at lade en anden peer downloade fra en selv, men man kan stadigvæk selv downloade.
- Baseret på økonomisk princip der hedder Pareto Effektivitet (Is this even important? :P)
- Basalt set er det blot en lokal optimeringsalgoritme, således at et par ikke kan forstørre deres glæde.
- Peers vil helst uploade til peers der uploader til dem.
***** BitTorrents unchoking
- BitTorrents egen choking algoritme vil altid have fire (default, kan ændres) peers unchoked.
- Hvem der skal unchokes er baseret på download rate. Så dem vi downloader mest fra, bliver unchoked.
- Denne udregning sker hvert tiende sekund (igen, bare et default)
***** Optimistisk unchoking
- For at vi også kan lære nye peers at kende, der må ikke har uploadet så meget til os endnu (Det kan ske de choker os fordi vi chokede dem), så findes der også et optimistisk unchoke.
- Det optimistiske unchoke roterer hver tredje rechoke periode (så 30 sekunder default)
***** Anti-snubbing
- Man kan også "snubbe" folk, hvis de ikke uploader til én i over et minut. Så stopper vi også bare med at uploade til den person, medmindre den bliver optimistisk unchoked.
-
*** Problemer med BitTorrent?
- Høj churn rate
- Free Riders
- Nogle nodes risikerer at stå med en stor del
*** Hvordan kan man angribe BitTorrent?
**** Sybil Attack
- Et sybil attack i et P2P netværk fungerer således at en enkelt peer (person) indsætter sig selv med mange virtuelle noder
- Dette tillader en enkelt person at blive størstedelen af et netværk
- Et certifikations system kan stoppe dette, da dette vil betyde personen skal kunne vise certifikater for alle sine virtuelle peers. Dette er dog ikke så fedt, hvis idéen er, at systemet skal være helt decentraliseret.
- Vi spawner en pokkers masse noder og opfører os træls
- Der er præsenteret to slags sybil angreb:
***** Lying Piece Possession
- Bygger på at snyde omkring sine bitfields.
- Eftersom BitTorrent bruger Rarest First protokollen, eftersom dette sikrer en hvis uniform fordeling over hvilke peers der har hvilke dele. Når alle forsøger at downloade de sjælne dele først, skifter den sjælndeste dele ofte, så delene bliver godt fordelt.
- Et Piece-Lying angreb forsøger at ødelægge den uniformitet (lel ord?)
- Så vi lyver om hvilke filer vi har, for at snyde denne "sjældneste først" protokol, der forsøger at downloade "sjældne" filer først. Ved at lyve, kan vi få sjældne filer til at virke ikke sjældne, hvilket i sidste ende kan få filen til helt at forsvinde fra netværket, fordi ingen downloader den.
- De "onde" peers påstår derfor alle sammen de har de sjældne dele, så folk stopper med at downloade disse fra de faktiske peers. Desuden så holder de onde peers alle andre peers permanent choked, da vi jo faktisk ikke kan uploade filen.
- Des flere peers, des værre et angreb (oplagt), da vi kan gøre de sjældne ting endnu mindre sjældne.
- Dette blev testet med 25 løjnere der blev indsat, der løj omkring de samme fire stykker og resultatet var rigtigt nok at delene forsvandt fra netværket og effektivt gjorde at det gik i stå.
***** Eclipse
- Vi kan omkranse områder af netværket, eftersom BitTorrent tillader os at vælge vores eget ID, så vi kan vælge det på en smart måde!
- Målet er at sørge for at en helt område eller blot enkelte peers kun kommunikerer med vores onde peers
**** BitTyrant
- Man fandt ud af at det ofte er nogle få peers der giver virkelig meget til swarmen (en form for power-law). Dette betyder at disse peers er nødt til uploade til peers der giver mindre til dem selv og nøjes med at søge for gode peers via optimistiske unchokes.
- Dette betyder således at de peers der uploader meget lidt, får meget mere tilbage, end de burde, i gennemsnittet.
- Det vil sige, hvis man kender equal split rate (et konservativt lower bound på upload kapacitet for en peer), så kan man udregne ens optimale active set størrelse (hvor mange peers man snakker med, ens neighbourhood).
- Det viser sig at hvis man blot uploader ~14KB/s, så er reciprocation (altså vi selv får noget fra den person) næsten garanteret, hvilket tyder på at alt upload over de ~14KB/s er altruistisk og ikke nødvendigt.
- Så hvis man forsøger at optimere hvor meget man selv får, så ligger det op til en oplagt måde at gøre det på, nemlig BitTyrants unchoking algoritme
- BitTyrant vedligeholder en parameter for hver peer, der betegner hvor meget vi skal uploade til den peer, for at få lov til at downloade fra den, samt hvor meget vi downloader fra den. BitTyrant rangerer derefter peers efter ratioen download_rate_fra / upload_rate_påkrævet og unchoker peers fra toppen af den rang liste.
- Ligeledes konkluderer de at et større active set -> bedre download. Dette giver mening, fordi jo flere vi snakker med, jo bedre er chancen for at blive optimistisk unchoked af peers i ens neighbourhood.
- De konkluderer følgende:
- Få BitTyrant peers klarer sig glimrende
- Mange ødelægger lidt det hele
- although TFT discourages free riding, the bulk of BitTorrent’s performance has little to do with TFT. The dominant performance effect in practice is altruistic contribution on the part of a small minority of high capacity peers.
- More importantly, this altruism is not a consequence of TFT; selfish peers—even those with modest resources—can significantly reduce their contribution and yet improve their download performance.
2) Manipulering af resourcers via repræsentation: En udfordring er hvordan man kan enkode information således alle kan forstå det? MIME-Typer (png, json ...), Content-negotiation, Accept-headers, x-extension for uofficielle MIME typer som f.eks. msgpack
3) Selvbeskrivende beskeder: CRUD, HEAD, GET, POST, PUT, so on so forth. Fejlkoder 200, 201 .., CORS for at snakke sammen med javascript fra f.eks. python.
4) HATEOAS (Hypermedia as the Engine of Application State): Hvordan man kan bevæge sig rundt på en side, links til relaterede ting, application state skal være en resource man kan tilgå.
- Hvis man f.eks. har enheder der er nødt til at køre propritære protokoller eller blot ikke er kraftige nok til selv at hoste, så kan man bruge en gateway der så kan snakke sammen med enheden og så kan gatewayen udstille informationen omkring enheden.
- Clouden opfører sig lidt som en gateway, men det er lidt besværligt, fordi den tilgås via HTTP eller andre protokoller der kan køre over nettet, så ofte ender du med at Clouden snakker sammen med gateways.
- F.eks. kan en pi snakke til en cloud server over MQTT
- Hvis man skal samle data fra mange WoT eller gateways. Samlingen af data'en kan oplagt også bare gøres på en gateway eller lignende. Ofte er gateway'en dog en fysisk genstand, så clouden er mere skalerbar.
- At have en enkelt og delt data model til alle Things vil gøre integration og sådan markant nemmere ift nye apparater. Dette bliver relevant ift Web Discovery
- Eftersom vi har brug for at kunne bruge API'et der tilhører de forskellige Things, via kode
- HATEOAS (Alle de der links, model, actions, UI, den slags ting)
- Dette giver også en struktur over hvad de forskellige links beskriver
- Man behøves desuden kun at requeste headeren for at få de her informationer, da LINKS ligger i HEAD.
- For at alt det her kan virke, skal man dog have en delt unik model, således vi ikke behøves kode unikke ting til hver Thing
**** Unik model
- /actions, /properties osv.
*** Sikkerhed
- Ting skal kunne deles på sikker vis uden folk der ændrer på dataen
- Der står fysiske objekter i alles huse, det ville være skidt hvis alle folk kunne forbinde til disse. F.eks. hvis folk kunne slukke for køleskabe og sådan.
- Wearables og sådan samler meget følsom information om folk. Det skal helst ikke deles.
- Share Layer i den der fire-lags model
**** Tre store problemer
- Kryptering: Reddet af TLS og certificater
- Autentificering: pk/sk system eller OAuth eller blot et login system
+ Både klient og server autentificering.
+ Klienten har oplagt ikke noget certificat eller noget
- Ret nemt, hvis man altså stoler på de sociale medier til ikke at fucke deres login systemer op og leake ting.
** Pastry and its Application
*** Introduktion til Pastry
**** High level forklaring
- Pastry er et effektivt, distribueret objekt lokations og "routing substrate" for P2P netværk.
- Med routing substrate menes at pastry ikke som sådan er en applikation, men blot et API der kan bruges af andre applikationer.
- Pastry kan finde ting i O(log N) hop
- Der er ydermere ingen centraliserede servere. Den eneste information der er, er de forskellige noders leafsets, routing tables og neighbourhood sæt.
- Node ID'er består af 128 bits (hvadend noder lige skal holde og hvordan dets ID produceres, er op til applikationen)
- Pastry bruger netværks lokation og forsøger at minimere den totale distance, ved altid at tage et hop til den tætteste node. Det er applikationen der skal give dette mål.
- Node IDer er fordelt uniformt over de 128-bit og er f.eks. en hash af en IP. Dette betyder at man ingen information får fra node IDerne.
**** Hvilken information opbevarer noderne?
- Alle pastry noder har et routing table, et neighbourhood set og et leaf set
- Routing table indholder log_(2^b) N (hvor N må være mængden af noder) rækker og 2^(b-1) entries.
- Disse entries er per række noder der har samme n-længde prefix som noden der har routing tablet, for række n.
- Hver entry indholder IP adressen på noden
- I praksis vælges noder der er tættest på noden, jf. med hvadend proximity metric man får fra applikationen
- Leaf sættet indholder de L elementer. L/2 af dem er dem der har de numerisk tættest på node IDer, men er højere end den specifikke node. Tilsvarende er L/2 numerisk tættest mindre.
- Leaf sættet bruges til at slå op i først når man router, fordi hvis nogen har sendt noget til os, er der en chance for vi er tæt på det der skal findes, men de kendte ikke dem der er i vores leaf set.
- Neighbourhood sættet M indholder nodeIDs og IP adresser på de |M| noder er der tættest på os, baseret på hvadend proximity metric vi får fra applikationen. Dette bruges ikke til routing, men det bliver brugt til at vedligeholde lokations egenskaben, specifikt ved når en node joiner og man ønsker at lokations egenskaben bliver opretholdt.
**** Hvordan fungerer routing?
- Routing fungerer i flere faser
- Man tjekker først om den søgte node er i ens leafset
- Hvis noden ikke er at finde i leafset, kigger man derefter i ens routing table
- Man ønsker at videresende requesten til en node der har et prefix af længde minst 1 mere end os, med tingen der bliver requestet. Dette er hvad giver os O(log N) kompleksiteten.
- Kan man ikke finde en sådan node, så videresendes requesten til en node der deler samme prefix, men er numerisk tættere på.
- Worst case tid er N, hvis mange noder fejler samtidigt. Sikkert fordi man vandrer rundt i leaf sets?
**** Node joiner
- ny node X skal kende en eksisterende, tæt på, node A.
- X beder A route en "join" message med nøgle X
- Pastry router denne besked til node Z med nodeId numerisk tættest på X
- Alle noderne på routen fra A til Z, sender deres state information til X.
- X kan ud fra dette bygge sit routing table og neighbourhood set, ved at kigge på noderne i rækkefølgen fra A til Z's routing table og bygge sine egne rækker ud fra dette. X's neighbourhood sæt er blot A's.
- Leafset er baseret på Z's.
- X sender derefter beskeder til alle noder i routing table og neighbourhood set, for at tjekke at lokations egenskaben er opretholdt.
**** Node forsvinder
- Leafset kan genopbygges ved at spørge en node fra siden af den fejlede node om dets leafset. Ud fra dette kan vi finde en udskiftning
- Routing table kan genopbygges ved at spørge en node med samme præfiks som den fejlede node
- Neighbourhood set kan genopbygges ved at spørge andre noder i ens neighbourhood set om en udskiftning.
**** Brister
- Eftersom routing er deterministisk, kan en ond node fucke ting op. Dette fikses af randomiseret routing.
- IP routing kan give problemer, hvis nogle IP hosts er unreachable fra nogle specifikke IP hosts, men ikke alle. Dette betyder vi har nogle dele af netværket der ikke kan snakke med alle dele, hvilket oplagt giver problemer.
**** Et API
- Pastry kræver at tre metoder bliver implementeret:
1) deliver - bliver kaldt når nodens nodeId er nummerisk tættest på nøglen, af alle noder i live
2) forward - Kaldes af pastry lige inden en besked bliver forwarded til et nextId. Dette tillader brugeren af pastry, at ændre på beskeden, terminere den ved at sætte nextId til null eller logge ting. Basically gøre hvad personen vil.
3) newLeafs - Kaldes af pastry når der skal ændres på leafsettet. Dette betyder brugeren kan lave applikationsspecifikke ting.
*** PAST
**** Hvad er PAST?
- Et P2P netværk til opbevaring af filer
- Resistent overfor fejl
- skalerbart
- selv-organiserende (i.e. hvis en node joiner eller forsvinder, så "adapter" netværket sig)
- Kan route fil queries
- Gemmer kopier af filer
- Cacher populære filer
- Baseret på Pastry
**** PAST design
- Man kan godt vælge ikke at route og gemme ting, men blot minimalt være et access point for brugeren, således brugeren kan bruge systemet og sådan
- Noder har et 128 bit random-ish ID. Dette er 128 bit af en hash af nodens public key. Dette gør at man ikke selv kan vælge sit ID, men også at IDet intet har med din lokation at gøre, eller noget som helst andet.
- Dette sikrer at noder ved siden af hinanden ikke nødvendigvis er tæt på hinanden (altså, filer bliver delt "diversely", når filen bliver opbevaret ved k noder der er ved siden af hinanden)
- fil publishers har pub/private keys
- Filer er immutable siden dets ID blandt andre er produceret ud fra dens navn. Der kan ikke indsættes to ting med samme ID.
- Hvis man requester en fil, ender man ofte hos en node der er tæt på, grundet pastrys lokations egenskab.
- PAST exposer tre operationer:
1) Insert, hvor et ID bliver udregnet og filen bliver gemt på k forskellige noder, der er nummerisk tæt på IDet
2) Lookup, hvor, hvis filen kan findes, denne bliver returneret.
3) Reclaim, der tillader at pladsen filen optager, bliver overskrivet. Filen bliver ikke som sådan slettet af dette.
- Filer bliver oplagt uniform fordelt i netværket, grundet måden IDerne bliver udregnet på.
- PAST cacher også, udover at gemme filen på de k noder. Disse caches kan discardes når som helst.
- En cache gemmes ved de noder man traverserer når man søger efter en fil eller udfører en insert operation, såfremt denne node har en plads ratio over et threshold
**** Storage håndtering
- PAST ønsker oplagt at filer bliver optimalt fordelt, således at alt pladsen i netværket, bliver brugt.
- Dette kan være svært i en decentraliseret verden, da man ideelt set bare kunne have en koordinator, men det skal løses uden et for stort kontrol overhead.
- Der er to måder dette problem løses på
***** Replica Diversion
- Man balancerer fri storage space via noder i leafset
- Hvis en node ikke kan have en kopi af en fil lokalt, spørger man noder i sit leafset, der ikke allerede er en af de k noder der skal have en kopi, om de kan store den. Dernæst opbevarer den oprindelige node en pointer til den node i sit leafset, der har filen.
- Denne pointer kan ydermere gemmes på den k+1 tætteste nummerisk node, således vi kan overleve hvis den oprindelige node crasher. (Hvad fuck gør man hvis den k+1'te node så crasher samtidig?)
- For at regne ud om man skal acceptere en kopi af en fil, er der defineret et mål baseret på størrelsen af filen divideret med ledig plads. Denne ratio skal være under et vidst threshold, for at filen accepteres.
- Thresholdet er laveret for diverted replicas (dem du er blevet bedt om at holde), eftersom der skal være plads til primære replicas.
***** File Diversion
- Hvis hele leafsettet er fyldt hos en node der forsøger at udføre replica diversion, så udføres file diversion i stedet
- Her udregnes et nyt ID for filen og man forsøger igen, således noden ender i et nyt nabolag.
- Bliver forsøgt tre gange, før man bare giver op og konstaterer der ikke er mere plads i netværket.
**** Generelt ekstra stuff
- Storage håndtering var ret nice, eftersom man gik fra at udnytte 60% af netværkets kapacitet (uden håndtering), til omkring 95%
- Der er en hvis form for sikkerhed, i at noder også kan have checksums på filer, som blot kan udregnes igen.
- Ligeledes kan filer være signeret med udgivers private key. Denne kan også opbevares, eller man kan spørge udgiveren selv.
- Når en node joiner i systemet og denne node ender i et leafset og derfor skal have en masse kopiere af filer, så kan denne node i stedet for blot opbevare pointers til de noder der faktisk har filerne. Ellers ville kontrol overhead være tosset.
*** SCRIBE
**** Hvad er SCRIBE?
- Et P2P baseret multicast system
- Tillader at multicaste til grupper, via et multicast træ der bygges af Pastry routes for de forskellige noder, fra en rendez-vous node.
- Enhver scribe node kan starte en gruppe, hvorefter andre noder kan joine denne gruppe og/eller multicaste beskeder til hele gruppen
- SCRIBE garanterer ingen specifikt rækkefølge på beskeder
- Man kan åbenbart bygge bedre garantier oven på SCRIBE
**** Grupper
- Grupper kan have flere sources og mange medlemmer
- Hver gruppe har et unikt gruppe ID
- Den SCRIBE node med et nodeId nummerisk tættest på groupId, er rendezvous punkt for denne gruppe. Dette er roden for multicast træet.
- For at oprette en gruppe, routes en besked via Pastry efter groupId. Den node der til sidst er tættest på, bliver rendezvous punkt.
- Man kan gøre processen deterministisk, ved at vælge at have den specifikke node man ønsker som rendezvous punkt, ved at lave gruppens navn med hashen på noden og så noget concat derpå, således den specifikke node deler præfiks med groupId. Dette kan have fordele som hvis man f.eks. ved noden ligger geografisk godt.
- Scribe noder der er med i en gruppes multicast træ hedder forwarders. De er ikke nødvendigvis et medlem af gruppen
- Hver forwarder har en children table for gruppen, der indholder IP og nodeId for dets børn i multicast træet.
**** Joining
- Når en Scribe node ønsker at joine en gruppe, så routes en JOIN bedsked med groupId.
- Denne besked ender ved rendez-vous noden.
- Alle noder der ligger på ruten til rendez-vous noden, bliver forwarders.
- Hvis de allerede er det, tilføjes den nye node blot til deres children table
- Ellers oprettes en children table og så tilføjes den node der sendte beskeden til dig, som et element deri og noden opretter sin egen "JOIN" besked og sender den efter groupId. Dette betyder at man danner en vej fra rendez-vous noden, til den nye node.
**** Leaving
- Man markerer man ikke længere er et medlem, men blot en forwarder
- Hvis man ingen elementer har i sit children table for den gruppe, så sendes en leave message til forældreren og vi fucker af.
- Hvis man har elemtner, så gør man intet og bliver blot som en forwarder.
**** Afsendelse af beskeder
- Man finder rendez-vous noden og dennes IP. Dette kan caches fremadrettet, så man ikke skal gøre dette hver gang.
- Eftersom alle opretholder IP'er på sine children osv, så bruges Pastry kun til at finde rendez-vous noden og dannelse af træet. Dernæst kan beskeder bare sendes via IP.
- Rendez-vous noden er et sådan pseudo centraliseret element og denne kan potentielt korrumperes? Specielt når man faktisk kan "bestemme" groupId.
- Dette betyder dog også man kan bruge denne node til access control og sådan, for gruppen.
**** Reparation af træet
- Ikke-leafs sender heartbeats til sine children
- Multicast beskeder er implicitte heartbeats
- Et child mistænkers ens parent er fejlende, hvis man ingen beskeder modtager (multicast eller heartbeats)
- Hvis dette sker, sendes en ny JOIN besked via pastry, således man kan fikse træet
- Rendez-vous nodens state opbevares ved et x antal af de nummerisk tætteste noder på rendez-vous noden. Disse noder må være i leafsettet af rendez-vous noden og disse vil derfor blive fundet, når children opdager noden er væk og derfor sender en ny "JOIN" besked.
** Security and Privacy
*** Hvorfor er det nødvendigt?
- Vi har f.eks. Kademlia der ikke er bygget til at være sikker
*** S/Kademlia
**** Hvorfor?
- Kademlia har deterministisk routing
- Peers har ret vigtig information ift hvordan routing skal foregå
- Peer ID bestemmer position i netværket og dette må vælges selv
- Information er blot opbevaret ved noden hvis ID er tættest på tingen. Dette kan derfor bestemmes, hvis man kender nodens ID.
**** Angreb på Kademlia
***** Sybil attack
***** Eclipse Attack
***** Churn attack
- Forsøg at ødelægge Kademlia's stabilitet ved at producere churn
***** Adversarial routing
- Route ind i noget gøgl, i stedet for det rigtige
**** Hvad ændrer vi?
- I S/Kad har alle peers pub/priv keys
***** NodeID Generation
- Dette skal ødelægge sybil attacks, der af afhængige af at kunne producere en voldsomt masse noder med forskellige nodeIds.
- Ligeledes er nodeId nu en hash af pubkey. Dette gør også bare sybil attacks bliver svære.
- Man bruger nu også Weak Signatures og Strong Signatures, for at signe beskeder og nogle metode kald.
- Dette kan enten gøres med central authority (hvilket man ikke vil)
- Eller et crypto puzzle. Dette vil man, da det er svært at udregne, men nemt at verificere.
***** Sibling List (Find lige ud af noget om det her ..)
- I stedet for at binde parameteren k til mængden af elementer i en bucket og mængden af kopier af en fil, findes en ny parameter
- Denne hedder s og beskriver hvor mange kopier af en fil der skal uploades
- Ligeledes gemmes en ekstra liste ved noder der hedder en sibling list. Denne har størrelse n * s
- Det er noget med at disse lister returneres i stedet og man så sammenligner denne information
- Det skal blandt andet også hjælpe på, at det kan være svært at beslutte om filen er ok, baseret på den information man får, når man kalder lookup på en fil og ender med en liste af k elementer.
***** Routing table maintenance
- Der defineres tre klasser af beskeder:
1) Incoming signed RPC requests
2) Svar
3) Unsigned beskeder
- En afsender adresse er valid hvis den er signeret og actively valid, hvis den er valid og kommer som svar på en besked.
- Actively valid adresser bliver tilføjet med det samme, givet der er plads
- Valid afsender adresser bliver kun tilføjet til en bucket, hvis afsender ID er tilpas meget anderledes fra modtagerens ID. Dette er således en attacker ikke kan fylde en nodes tætteste buckets. Disse er ofte tilnærmelsesvis tomme, da det er sjældent en node kan finde k andre noder der kun er anderledes med et par enkelte bits.
- Man ignorerer blot unsigned beskeder
***** Lookup via disjoint paths
- For at undgå at en ond node blot styre vores query ind i et nederen område, ved at sende nogle "gøglede" k noder tilbage til os
- Den der ønsker at query vælger k tætteste noder og querier dem. Starter derved k forskellige paths
- Man querier kun hver node én gang, således man sikrer sig de forskellige paths forbliver disjoint
- Man ender til sidst med en masse sibling lists. Disse kender alle hele denne liste, så selv hvis k-1 af de noder er onde, så ender man med den komplette liste.
**** Evaluering
- Hvis man forøger mængden af disjoint paths man querier, så rammer man oftere det man leder efter, selv hvis der er en del onde noder. Dog stiger mængden af arbejde også lineært med mængden af disjoint paths.
- Ting virker fint!
*** Freenet
- Freenet bruger en decentraliseret P2P arkitektur for at lave et uncensorerbart og sikkert globalt informations opbevarings system
- Basically, man kan dele filer med det på en cool måde :D
- Blevet testet på 200.000 noder og det virkede fint.
- Freenets design er fokuseret omkring:
1) Privathed for udgivere, forbrugerere og holdere af information
2) Resistent mod informations censorship
3) Høj tilgængelighed og pålidelighed
4) Effektivt, skalerbart og adaptive
**** Freenet arkitektur
- Filer har et assigned globally unique identifier (GUID)
- Et GUID er en 160-bit SHA1 hash
- Disse GUID bruges som:
***** Content-Hash keys
- Brugt til primære data filer
- Altså udregnes det over de filer der indsættes i Freenet
***** Signed-subspace keys
- Beregnet ud fra en pubkey og en tekstuel beskrivelse af hvadend der er under det.
- Derefter signeres filen med privkey. Dette sikrer at kun egeren af subspacet kan ændre på det, da kun han kan producere en valid signatur.
- Alle kan verificere at denne signatur er korrekt ud fra pubkeyen
- Alle kan tilgå filer fra det specifikke subspace, ved kun at have pubkey
- De her SSKs bruges normalt til samlinger af data, der omhandler det samme emne
- Ofte gemmer de bare pointere til CHKs, i stedet for reelt set at gemme filerne. Det har også den fordel at folk kan opdatere filerne der bliver peget på
***** Privacy, Messaging and Routing
- Eftersom Freenet udnytter et mix-net scheme, lidt ligesom Onion routing, kender noder kun deres direkte naboer
- Dette medfører at routing kan tage ret lang tid, da man skal igennem en del noder på vejen, for at sikre at ingen ved hvor filen kom fra eller skal hen.
- Hvert lad er i øvrigt krypteret, så folk kan heller ikke læse filen på vejen
- Alle noder har et routing table med adresser af andre noder og de GUID keys man tror de noder holder
***** Request af fil
- Routing fungerer med noget de kalder en "steepest-ascent hill-climbing search". Ideen er at man forwarder queries til den node man tror er tættest på målet.
- Hvis man ikke kender noden eller har et gæt, så forwardes routes til den node med den nøgle der tættest (sådan nummerisk?) til den requestede.
- Hvis en request er succesfuld, så sendes beskeden tilbage over kæden, hvor noder kan cache og logge filen.
- For at skjule identiteten af data holderen, ændres disse reply beskeder i ny og næ, ved at noden sætter sig selv på som dataholder. Den faktiske dataholder kan stadigvæk findes i den "nye" falske dataholders routing table, så filen kan stadigvæk findes.
- Requests har også en TTL. Denne kan også blive ændret på af noder på vejen.
- Desuden, hvis man ikke har nogen at forwarde til eller opdager der er et loop, så sender man failure tilbage til hvemend der sendte dig requesten.
***** Indsætning af fil
- Samme som routing
- Man udregner GUID og sender en insert besked til sig selv, der indholder GUID nøglen og en TTL
- Denne TTL repræsenterer hvor mange kopier man gerne vil have.
- Hvis der opstår kollisioner af CHKen, så afbrydes indsættelsen.
- Det samme gælder for kollisioner af SSK
- Filen bliver published til den sidste node i kæden af insert beskeden.
***** Joining
- Man producerer først en pub/priv key
- Dernæst sendes en join besked der indholder pubkey, IP adresse og TTL til en kendt node (GLHF)
- Denne besked sendes tilfældigt rundt til TTL udløber. Disse noder skaber et GUID, der vil repræsentere den nye node
- Dette gøres via en random number generation som alle kan være en del af. Dette sikrer at en enkelt ond node ikke kan bestemme GUID til noget specifikt, da alle skal være enige.
***** Træning af ruter
- Fordi ens routes vil gå mod det samme, bliver områder af netværket trænet i at håndtere specifikke filer.
- Fordi noder rundt omkring dataholderen cacher og husker på lokationen, så vil systemet udvikle sig til at bedre kunne håndtere det, hvis der kommer mange requests for en enkelt fil.
**** Generelt
- Man kan med fordel kryptere filer og sådan, hvis man har lyst til det. Så skal personer have nøglen for at kunne dekryptere det igen.
*** Kort note om Tarzan I guess
- P2P anonymt IP netværk overlay
- Bruger layered kryptering og multihop routing (lidt ligesom Onion Routing)
- Bruger cover traffic, således det kan være besværligt at skelne reel kommunikation fra støj
- Så det ultimative mål er at en host kan kommunikere med en arbitrær server uden at nogen kan bestemme hosten's identitet.
- Noder har en liste af mimics de udveksler cover trafik med
- Pakker kan kun routes igennem disse mimics og deres cover trafik flukturerer således at trafikken altid bare er monotom imellem to noder.
- Såvidt jeg kan se, er vi ligeglade med om en adversary ved nogen snakker med en specifik server, altså, beskeden fra PNAT'en til webserven, kan vi ikke gøre noget ved
- Hvem der lavede den oprindelige request tilgengæld, er skjult af cover traffic og at ingen i løbet af ruten ved om beskeden kom fra deres nabo eller dennes nabo osv.
- Alt trafik er krypteret ligesom Onion Routing
- Man kan joine netværket ved at spørge en kendt node om en peerlist fra denne
