More disp

disps.org

@@ -507,10 +507,12 @@
 - WoT fokuserer mere på at alting skal fremstille et Web API på den ene eller anden måde og derved opnå en måde alting kan snakke sammen på
 **** Hvordan kan de snakke?
 - RESTful(ly) !
+- Så hver ting kan kommunikere over REST med hinanden og dette er klart defineret hvordan
 **** Så lad os da bygge det!
 *** Udvikling af WoT
 **** Forklaring af hvorfor REST
 - Det maksimerer interoperability and scalability
+- REST giver en række arkitektoniske constraints, der giver dette
 - De fem REST constraints
 1) Client/server
 2) Uniform interfaces
@@ -521,12 +523,40 @@
 - Maksimerer decoupling, klient skal intet vide om hvordan serveren virker og det samme gælder for serveren ift klienten
 - Forbedrer også scalability, eftersom de to ting kan udvide og udvikle uafhængigt af hinanden
 ***** Uniform interfaces
-- Yderligere fire principper; 
+- Basalt set bare at alle ting har cirka det samme interface
+- Dette betyder også at det er meget nemmere at tilføje nye elementer, eller scrape eller sådan
+***** Stateless
+- Klientens kontekst og state skal kun være på klienten, serveren skal intet kende til det.
+- Alle requests til serveren skal så indholde den state serveren skal bruge for at kunne svare på requesten.
+- Dette giver mere robusthed, da det intet ændre for klienten, hvis serveren crasher.
+- HATEOAS kan lidt også bruges her, da det siger at URL'en skal indholde information ift applikationen
+***** Cacheable
+- Når man bruger REST kan serveren bestemme hvor ofte ting skal caches og hvornår disse skal udløbe
+***** Layered
+- Man kan bruge en proxy som en load balancer (hvilket vi også kommer ind på senere)
+- Man kan også have en gateway som mellemlag, der så kan oversætte til andre protokoller (også noget vi kommer ind på)
+- Til sidst giver det mulighed for at have et lag der cacher.
+**** Vi kan definere fire principper til at bygge dette
+- Hvad REST og HTTP har gjort for nettet ift deling, kan også også bruges i WoT
+- Vi kan komme op med en række principper der kan bruges til at bygge dette for WoT
   1) adresserbare resource: URI, gode navne, hierachical naming
   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å.
-**** Det er en fem-skridts proces
+**** Event-baseret stads i stedet
+- REST kald er meget sådan request response, ift hvis du nu laver et REST kald til en ting, så får du bare det data der nu engang er. 
+- Det kan være man er interesseret i at få at vide når der er nyt data i stedet. Hvordan kan dette gøres?
+***** Publish/subscribe
+- Oplagt til cloud med en messagebus
+***** Webhooks
+- Implementation af publish subscribe, kræver at både server og client har et REST API
+***** Comet 
+- Polling, serveren holder en request til der kommer data og derefter returnerer requesten.
+***** Websockets
+- En kommunikationskanal imellem to enheder. Den skal jo så være åben permanent. Kan være nederen for svage enheder.
+***** http/2 
+- Server-push er ret snazzy.
+**** Det er en fem-skridts proces at bygge WoT
 - Integrations strategi   (Directly, proxy(gateway) eller cloud)
 - Resource design         (Identificer funktionaliteten or organiser hierarkiet af de forskellige services)
 - Repræsentations design  (Hvilken repræsentation skal returneres? Content-negotation, JSON)
@@ -535,29 +565,32 @@
 **** Integrations strategi. En del forskellige fremgangsmåder, der alle giver det samme
 ***** Directly
 - Ting hostes på pi'en selv
+- Fungerer fint hvis enheden ikke er f.eks. batteridrevet og derfor behøves tænke over at løbe tør for strøm
+- Kræver at enhenden har en fornuftig internet forbindelse, da den jo selv skal håndtere requests og sådan
+- Ligeledes RAM, CPU og storage
 ***** Proxy
 - 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.
+- De kan også tilføje et ekstra lag af sikkerhed, da kommunikation går igennem proxien
+- Et eksempel er CoAP (constrained application)
+- Protokol baseret på REST, men bruger ikke HTTP eller TCP og har derfor brug for en gateway for at oversætte det til HTTP kald
 ***** Cloud
+- 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.
-**** Event-baseret stads i stedet
+
-- Publish/subscribe: Oplagt til cloud med en messagebus
-- Webhooks: Implementation af publish subscribe, kræver at både server og client har et REST API
-- Comet: Polling, serveren holder en request til der kommer data og derefter returnerer requesten. 
-- Websockets: En kommunikationskanal imellem to enheder. Den skal jo så være åben permanent. Kan være nederen for svage enheder.
-- http/2: Server-push er ret snazzy. 
 ** Discovery and Security for the Web of Things
 *** Hvad er Web of things?
 - Hurtig intro
-- Mange små ting basically
+- Små maskiner der indsamler data eller bare er 'augmented' med sensorer, actuators eller sådan
 - Hjælper på motivationen til hvorfor vi ønsker det her discovery stads
 *** Så hvorfor er discovery relevant?
-- At have en enkelt og delt data model til alle Things vil gøre integration og sådan markant nemmere ift nye apparater.
+- 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
 - Vi har brug for en måde at finde Things lokalt
-- Vi har brug for at kunne bruge API'et der tilhører de forskellige Things, via kode
 - Vi har brug for at kunne søge på Things rundt omkring på internettet
 - HTTP har ingen "discovery" mekanisme
 *** Findability problemet
-- For at vi kan bruge HTTP til at interagere med Things are der tre fundamentale problemer
+- For at vi kan bruge HTTP til at interagere med Things er der tre fundamentale problemer
   1) Hvordan ved vi hvor vi skal sende til?
   2) Hvordan ved vi hvad vi skal sende og hvordan?
   3) Hvordan forstår vi meningen med requests og responses?
@@ -569,15 +602,27 @@
 - Bliver brugt af mDNS, DLNA og UPnP
 - Bonjour også, der bliver brugt af apple
 - Nemmere at få routeren til at udstille alle IP-adresser for ting der er forbundne til den.
+***** mDNS
+- Man kigger efter mDNS beskeder over netværket
+- Basically bare multicasting af beskeder ud til folk
+- Dette giver adgang til en .local hjemmeside, man kun kan tilgå fra ens lokale netværket
+***** Bonjour
+- Bruger mDNS
+- Kan bruges til at automatisk finde ting som printere 
+- Ikke så meget mere at sige om dette
+***** Installation af software på routeren
+- Det ville være federe at have routeren til at udstille alting der er forbundet til den. Så er man ikke afhængig af at kunne bruge mDNS.
 **** Resource discovery på internettet
+- Men ok, intet af det forrige virker på internettet uden for vores eget lokalnet.
 - Crawling
+- Så vi skal kunne indexes
+- RFC5988 tillader os at have specielle tags i HTTP responses, så vores Thing ikke behøves at have en hjemmeside, for at kunne indexes.
 - 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.
@@ -589,7 +634,28 @@
   + Både klient og server autentificering.
   + Klienten har oplagt ikke noget certificat eller noget
 - Access Control: Log hvilke brugere der må hvad
+**** TLS
+- Serveren har et certifikat der bekræfter hvem serveren er.
+- Dette certifikat kommer af en eller anden autoritet som vi stoler på
+- Let's Encrypt kan give os de her certifikater gratis.
+- Det bruges også til at kryptere kommunikationen imellem server og client.
+**** Autentificering
+- Så nu kan vi kryptere ting imellem os og klienten ved hvem serveren er
+- Nu skal vi så håndtere at de forskellige Things og enheder også ved hvem de snakker til
+***** Server baseret autentificering
+- Stateful, eftersom man logger ind og nu er i en state
+- Har dog sine formål
+***** Token baseret
+- Man giver en token med i sin request
+- stateless
 *** Social Web of Things
+**** Kort hvad er OAUTH
+- Åben standard for autentificering
+- Tillader en web app eller app af en art at uddelegere opgaven at autentificere til en third-party service som f.eks. facebook, google eller LinkedIn
+- Kræver oplagt at man stoler på disse services
+- Ligeledes kræver at at man faktisk har en konto der.
+**** Social WoT
+- Idéen at vi kan bruge sociale netværk hvor folk allerede har konti, som autentificering
 - Brug en gateway til at håndtere access control
 - Brug OAuth til autentificering og login
 - Ret nemt, hvis man altså stoler på de sociale medier til ikke at fucke deres login systemer op og leake ting.

notes.org

@@ -1001,7 +1001,7 @@ For verbs other than GET/HEAD, or when using POST with representations other tha
 - a web Thing can act as a gateway between the web and devices that aren’t connected to the internet. In this case, the gateway can expose the resources—properties, actions, and metadata—of those non-web Things using the web Thing.
 - The web Thing then acts as an Application-layer gateway for those non-web Things as it converts incoming HTTP requests for the devices into the various protocols or interfaces they support natively. For example, if your WoT Pi has a Bluetooth dongle, it can find and bridge Bluetooth devices nearby and expose them as web Things.
 - The resource that contains all the web Things proxied by a web Thing gateway is {WT}/things, and performing a GET on that resource will return the list of all web Things currently available
-**** The WoT pie model
+**** The WoT pi model
 - A new tree structure, fitting the discussed model, where the different sensors end up in /properties, setLedState ends up in /actions, we have no /things and /model is the metadata as well as all sensor data, their properties, the actions, everything.
 - Following the model allows for dynamically creating routes and such, as all information is maintained in the model of the Thing, /model, /properties, /actions, /things.
 **** Summary
@@ -1799,7 +1799,7 @@ environment.
 * Pastry and its applications
 ** PAST
 - Large-scale peer-to-peer persistent storage utility
-- Based on self-organizing, internet-based overlay network of storage nodes that can coop route fil equeries, store multiple replicas of files and cache additional copies of popular files.
+- Based on self-organizing, internet-based overlay network of storage nodes that can coop route fil enqueries, store multiple replicas of files and cache additional copies of popular files.
 - Storage nodes and files are uniformly distributed IDs
 - Files are stored at node whose ID matches the best
 - Statistical assignment balances number of files stored
@@ -1811,7 +1811,7 @@ environment.
 - PAST had nodes connected to the internet, where each node can iniate and route client requests to insert or retrieve files.
 - Nodes can contribute storage to system
 - With high probability, a file is replicated on nodes which are diverse in geographic location, ownership, administration, network connectivity, rule of law, et.c.
-- PAST is attractive since; it exploits multitude and diversity (geographi, ownership, the same as before ..)
+- PAST is attractive since; it exploits multitude and diversity (geographri, ownership, the same as before ..)
 - Offers persistent storage service via a quasi-unique fileId which is generated when the file is inserted. 
   + This makes files stored immutable, since a file can't be inserted with the same fileId
 - Owner can share fileId to share file and a decryption key if needed
@@ -1845,7 +1845,7 @@ environment.
 - The purpose of replica diversion is to balance the remaining free storage space among the nodes in a leaf set.
   + A chooses a node B in its leaf set t h a t is not among the k closest and does not already hold a diverted replica of the file. A asks B to store a copy on its behalf, then enters an entry for the file in its table with a pointer to B
 - Ensuring that the pointer doesn't disappear, can be done by entering a pointer to the replica stored on B, into the file table of C with the k+1th closest nodeId to the fielId. 
-- PAST has three policites to control replica diversion
+- PAST has three policies to control replica diversion
   1) acceptance of replicas into a node's local store
   2) selecting a node to store a diverted replica
   3) deciding when to divert a file to a different part of the nodeId space