ddist Noter Michael Lind Mortensen, , DAT4 25. marts 2009

Størrelse: px
Starte visningen fra side:

Download "ddist Noter Michael Lind Mortensen, 20071202, DAT4 25. marts 2009"

Transkript

1 ddist Noter Michael Lind Mortensen, , DAT4 25. marts 2009

2 Indhold 1 Fundamental Concepts Disposition Subject details Definitions Structure Motivations & Goals Transparency Pitfalls in development Scalability Distributed System Types Architectures Disposition Subject details Definitions Software architecture styles System architecture styles Multitiered (Centralized) P2P (Decentralized) BitTorrent (Hybrid) Communication Disposition Subject details Definitions OSI Model Middleware OSI Model RPC Message-Oriented Communication Multicasting Epidemic Protocols Naming Disposition Subject details Definitions Flat naming Structured naming DNS Attribute-based naming LDAP

3 5 Time Disposition Subject details Definitions Global tid Fysisk tid Synkronisering Happens-Before Relation Logical Clocks Vector Clocks Synchronization Disposition Subject details Definitions Multicasting JGroups Mutual Exclusion Consistency Disposition Subject details Definitions Replication Consistency Models Continious Consistency (FEJLBEHÆFTET, KIG I BO- GEN) Conit size Consistent Ordering Reliable Multicast Virtual Synchrony Fault Tolerance Disposition Subject details Definitions Types of failures Reliable Client-Server Communication Agreement in faulty systems Distributed Commit Recovery

4 9 Hand-ins G1-G Disposition Subject details Definitions Transparency Hand-in G1 (HTTP) Hand-in G2 (HTTP-Server) Hand-in G3 (RPC HTTP-Server) Hand-in G4 (Reliable Multicast RPC)

5 1 Fundamental Concepts 1.1 Disposition 1. Definitions 2. Structure Def. Distributed System Middleware 3. Motivations & Goals Making resources available Hiding Distribution Openness Scalability 4. Transparency Access, Location, Migration, Relocation Replicaton, Concurrency, Failure 5. Pitfalls in development Transparency impossible Wrong assumptions 6. Scalability Centralization/Decentralization 7. Distributed System Types Computing Systems Information Systems Pervasive Systems 1.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. 5

6 Def. Distributed System A collection of independent computers that appears to its users as a single coherent system Structure Hvordan er et distribuerede system så struktureret? Vha. middleware! Som vi kan se nedenfor laver vi et middleware lag som alle maskiner i systemet har, således de hver interegerer på samme interface. Det er så i dette middleware vi skal implementere alt funktionaliteten i det distribuerede system Motivations & Goals Når vi konstruerer distribuerede systemer, så er der visse ting vi gerne vil opnå for at have et effektivt system. Overordnet har vi følgende 4 mål: Gøre resourcer tilgængelige - Systemer skal tillade effektiv og kontroleret adgang til, og deling af, distribuerede resourcer. Skjule distribution - Systemer skal virke som om det kun er et enkelt computer system der kører. Åbenhed - Systemer skal levere tjenester i forhold til standard regler, som beskriver syntax og semantik for disse tjenester. Scalability - Systemer skal kunne skalere i forhold til størrelse, geografi og administration. 6

7 Men der er et ekstra mål vi så ikke har taget fat i her, da det fortjener en lidt større gennemgang - nemlig Transparency Transparency Transparency relaterer sig til hvilke ting det distribuerede system skal skjule for brugeren. Optimalt set vil vi gerne opnå alle tænkelige former for transparency, men i praksis er det blot ikke muligt. Typisk vil forskellige teknologier blot understøtte nogle få af disse transparencies Pitfalls in development Alle disse ting lyder selvfølgelig fine og vi har jo nærmest nu opskriften på det perfekte distribuerede system. Men hvad kan så gå galt når vi udvikler alt det her? En hel del faktisk! Førstegangs udviklere laver en række forkerte antagelser. Først og fremmest har vi antagelsen om fuld transparency - Det kan kort sagt bare ikke lade sig gøre! Dernæst har vi en lang række forkerte antagelser omkring netværket: Netværket er pålideligt Netværket er sikkert Netværket er homogent Netværkstopologien ændrer sig ikke Latency eksisterer ikke Båndbrede er uendelig Alt i alt leder disse fejl til distribuerede systemer der ikke passer til virkeligheden og derfor ikke opnår de mål vi har, som f.eks. skalering. 7

8 1.2.6 Scalability Vi vil så nu tage et ekstra kig på skalerbarhed, da det ofte er en af de ting der er uhyre vigtigt for successen af et distribueret system. Skalerbarhed er afhængig af, at alle delkomponenter i et system kan tilpasse sig til et forhøjet load, så derfor får vi logisk nok problemer hvis vi har bottlenecks et eller andet sted i systemet - også selvom det så blot er en lille del af systemet. Skalerbarhed bliver således begrænset af centralisering, hvor vi kan dele centralisering op i 3 dele: Centraliserede tjenester: Ex. En enkelt server til alle brugere Centraliserede data: Ex. En enkelt online telefonbog Centraliserede algoritmer: informationer Ex. At lave routing baseret på komplette Nøglen til skalerbarhed er således at decentralisere tjenester, data og algoritmer! Men at gøre dette skaber et helt nyt sæt af problemer vi er nød til at tage os af: Consistency, Synkronisering og Fejlhåndtering. Af eksempler på skalarbare systemer kan nævnes DNS, hvor data og tjenester distribueres ud i DNS zoner og algoritmen til lookups desuden bruger lokale data på DNS-serverne. The holy trinity of awesomeness! Distributed System Types Grundlæggende er der 3 forskellige typer distribuerede systemer: Distribuerede beregningssystemer (Fokus på beregning) Distribuerede informationssystemer (Fokus på samarbejde) Distribuerede pervasive systemer (Fokus på mobilitet og embedded communication) Hvilke ting vi fokuserer på som vigtige mål, afhænger meget af typen af system. 8

9 Distributed Computing Systems Et beregningsystem vil f.eks. fokusere på throughput - altså: Hvor mange operationer kan vi udføre pr. sekund. Et sådant system kunne typisk blive implementeret som f.eks. et computing cluster, hvor vi har en række maskiner koblet sammen i et højhastighedsnetværk, med en Master Node der kontrollerer og tilgår en række Slave Nodes, og hvor alle disse tilsammen så løser et større beregningsproblem. Som det ses herunder har Master Node nogle parallel libraries, hvilket faktisk er hele Middleware implementationen af det distribuerede system, således Slave Nodes typisk faktisk blot er helt normale maskiner med normale OS. Distributed Information Systems Et informationssystem vil i højere grad fokusere på andre ting end computing systemer, og kan have mange forskellige mål i forhold til deres anvendelsesfelt. Et transactionssystem vil f.eks. fokusere på at kunne tage transaktioner fra forskellige lokationer og inkorporer dem i et samlet system, således al tilgang til dataene vil være konsistent. Distributed Pervasive Systems Et pervasive system er mange ting, men relaterer sig generelt til systemer der interagere med omverden, hvad end denne omverden er en person, en bil, et område osv. Et eksempel på dette er Sensor netværk, som ofte bruges til at opsnappe information om et område eller en struktur. F.eks. har man udviklet små MOTES, som er små sensorer der kan tjekke fugtighed, temperatur mm. Disse MOTES placeres så, f.eks. i en bro, for at se om der ændrer noget i strukturen, som kunne være til fare for broens stabilitet. Alle disse informationer kan så sendes tilbage til en operator på en af to måder. Først mulighed er at de sender al data direkte når de læser det: 9

10 Dette antager dog, at et operatorsystem konstant sidder og samler data fra sensorerne. En anden løsning giver sensorerne en smule lagerplads til data og giver dem mulighed for selv at processere dette, således de kan nøjes med at returnere resultater: Denne løsning vil selvfølgelig ikke altid virke, da det antager sensorerne rent faktisk har lagerplads af en art og processeringskraft. De fleste sensorer kan ikke andet end blot at sende data ud. 10

11 2 Architectures 2.1 Disposition 1. Definitions Distributed System Software Architecture System Architecture 2. Software architecture styles Layered arkitektur Object-based arkitektur Event-based arkitektur Shared data-space arkitektur 3. System architecture styles 4. Multitiered (Centralized) 5. P2P (Decentralized) Struktureret P2P Ustruktureret P2P Superpeers 6. BitTorrent (Hybrid) 2.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen eller slides såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system. 11

12 Def. Software Architecture How our software components are organized. Def. System Architecture How to realize our software architecture Software architecture styles Vi vil så kigge på de typiske software arkitekturer vi har gennemgået. Fælles for alle arkitekturerne er, at de hver beskriver de pågældende komponenter i softwaresystemet, disse komponenters indbyrdes forbindelser og kommunikationen herimellem. Layered arkitektur En layered (eller lags ) arkitektur strukturerer komponenter i lag, hvor specifikke lag kun må kalde lag lige under eller over sig selv. På den måde går requests ned igennem strukturen og responses op igennem igen. Object-based arkitektur En object-based (eller objektorienteret ) arkitektur strukturerer komponenter i systemet som objekter der kalder metoder på hinanden vha. en RPC lignende struktur. Altså har vi basalt set et client-server systemarkitektur. 12

13 Event-based arkitektur En event-based (eller hændelsesbaseret ) arkitektur lader komponenter subscribe til events og publish hertil, igennem en fælles bus. Det er således middlewarelaget der sørger for kun de tilmeldte nodes modtager events. Denne arkitektur har én stor fordel, nemlig det at komponenter er løst koblet, da de teoretisk set slet ikke behøver kende til hinandens eksistens, men blot til event-bussen på middlewaren. Shared data-space arkitektur En shared data-space (eller delt lagerrum ) arkitektur er en kombination af en event-based arkitektur og et datalager, i det at det giver komponenter et fælles persistent dataområde hvor der kan publishes data til og komponenter kan tilmelde sig forskellige events. Den store fordel ved shared data-space arkitekturen er, at komponenter faktisk ikke behøver være online når der skrives til fælles data-space. Når komponenter bliver live igen, så kan de blot hente alle nye event updates der har været. Et typisk eksempel på denne slags struktur er revisionsstyringssystemet SVN. 13

14 2.2.3 System architecture styles Systemarkitekturen relaterer sig, som sagt, til hvorledes vi realiserer vores software arkitektur - det er altså et spørgsmål om hvilke fysiske rammer vores software kører på. Her har vi grundlæggende tre forskellige måder at tænke på, som hver har forskellige typer arkitekturer der bygger på disse tankegange. De 3 grundtankegange er: Centralized, Decentralized og Hybrid arkitekturer Multitiered (Centralized) En arkitektur kaldes centraliseret, hvis vi i et givent view af arkitekturen har én veldefineret serverrolle. Dette gælder typisk klassiske client-server arkitekturer. Men i alle tilfælde har vi et komponent der har en større rolle end andre komponenter, typisk en server eller koordinator. Et eksempel på en centraliseret arkitektur, er en såkaldte Multitiered arkitektur. Her vil en klient maskine implementere dele af, eller hele, userinterfacelaget, alt imens en server implementerer processeringslaget og kalder endnu et datalag, typisk på en anden server. Denne struktur ses ofte ved Web applikationer, da man her implementerer et visuelt lag af XHTML der sendes til klienten, hvor requests til serveren så bliver håndtereret af et processeringslag (typisk noget PHP, RoR,.Net el. Java Servlets) på en server, som så yderligere sender data til en MySQL el. PostgreSQL database på en server på datalaget. 14

15 Præcis hvor mange, og hvor meget af hvert, lag der implementeres på klienten afhænger af applikationen. I en websides tilfælde er det typisk ikke andet end nogle statiske sider der sendes til klienter, hvorimod ved nogle applikationer kan det være hele userinterfacelaget og hele processeringslaget, hvor logdata og opdateringer så køres ind over en database hos producenten (f.eks. ved Anti-virus programmer) P2P (Decentralized) Omvendt kaldes en arkitektur for decentraliseret, hvis vi i et givent view af arkitekturen ikke har én veldefineret serverrolle, men derimod spreder rollen udover flere eller alle komponenter. Struktureret Peer-to-peer Et typisk eksempel på dette er Peer-to-Peer netværk, hvor alle nodes i netværket fungerer som klienter såvel som servere, der så hver især har en række entities (data, processer, alfer eller hvad nu end det er). Et sådan Peer-to-Peer netværk er således struktureret som et overlay netværk ovenpå det eksisterende netværk, hvor overlayet konstrueres på to forskellige måder afhængig af om det er et struktureret peer-to-peer 15

16 netværk eller et ustruktureret. Eksemplet ovenfor er Chord, som er et struktureret peer-to-peer DHTbaseret system (Distributed Hash Table), hvor alle nodes og entities får tildelt unikke identifikationsnøgler i et 128bit eller 160bit addresserum og struktureres i en ring. Entities bliver herefter placeret således at entiteten med nøgle k bliver placeret i den node hvis id k er mindst. Denne node bliver herefter kaldet succ(k). Når så man vil lave et lookup på en bestemt entity, så laver man lookup på nøglen vha. LOOKUP(k), som så returnerer addressen for succ(k). Såfremt vi herefter tilføjer en pred(k), således k ved hvem sin predecessor er, så er det pludselig nemt at tilføje og slette nodes i netværket. At tilføje vil så blot være følgende trin: 1. Generer et tilfældigt id til noden. 2. Kør LOOKUP(id) for at få succ(id). 3. Kontakt succ(id) og pred(id) og indsæt noden her imellem. 4. Alle entities der nu tilhører id, overføres fra succ(id). At slette en node fra systemet bliver herefter ligeledes simpelt: 1. Informer succ(id) og pred(id) om sletningen. 2. Overfør entities til succ(id). At håndtere ustrukturerede peer-to-peer netværk er dog knap så simpelt. 16

17 Ustruktureret Peer-to-Peer Ustrukturede peer-to-peer netværk har samme principper med nodes og entities struktureret i et overlay netværk, men det er måden hvorpå dette overlay netværk skabes og håndteres der varierer. I ustrukturerede peer-to-peer netværk benytter man sig af tilfældighedsalgoritmer til at konstruere en tilfældig graf. Herefter har nodes så en lokal liste af nabo nodes, kaldet dens partial view af netværket. Dette partial view bliver så konstant udvidet, vha. to threads i hver node: en aktiv og en passiv. Den aktive thread i en node kontakter så en anden node, og disse to begynder herefter at udveksle partielle views ved at sende med deres aktive thread og modtage med deres passive (pushpull). (alternativer hvor man kun sender (push) eller modtager (pull) eksisterer også, men er ikke optimale). Hele processen ses her: Initial partial view Select random node 17

18 pushpull() views New partial view Superpeers Da det ikke er ordentligt skalerbart at søge efter entities i ustrukturerede peer-to-peer netværk (man flooder blot netværket med requests), så har man lavet en hierakisk løsning oven på ustrukturerede peer-to-peer netværk, for at give dem mulighed for at skalere bedre. Denne hierakiske løsning er superpeers! Superpeers er særlige broker nodes der indeholder et index af entities på et givent partielt view af netværket. Dette partielle view bliver herefter kaldet for et superpeer netværk, således denne del af netværket basalt set bliver en samling af klient nodes, med en superpeer server. Alle requests imellem peers sendes herefter til superpeeren der er ansvarlig for det netværk. Strukturen ser således ud: 18

19 Denne form for struktur er også ofte den man ser på de onde onde fildelings P2P netværk som Kazar, edonkey og hvad de nu alle sammen hedder ; ) BitTorrent (Hybrid) Sidst, men ikke mindst, har vi også en mellemting, hvor både centraliserede og decentraliserede komponenter er en del af arkitekturen. (Man kunne argumentere for at Superpeer P2P netværk egentlig også havde en hybrid arkitektur og ikke en decentraliseret arkitektur). Det bedste eksempel på en hybrid arkitektur, især når vi lige har snakket om ond ond fildeling, er BitTorrent. BitTorrent er et peer-to-peer fil downloading system, der benytter sig af såkaldte trackers til at finde brugere der lige nu henter en bestemt fil, således BitTorrent klienten kan hente dele af denne fil fra de aktive brugere. BitTorrent er dog speciel i den forstand, at den kræver du sætter dine data til rådighed for andre brugere. I normale onde fildelings P2P-netværk var det fint muligt at hente en masse gøjl, uden nogensinde at uploade noget som helst. Men BitTorrent kører ud fra en tit-for-tat tankegang, hvor en given node P kan sænke hastigheden hvormed Q må hente fra den, såfremt den opdager Q downloader mere end den uploader. Grunden til man kalder BitTorrent for en hybrid er, at den benytter sig af.torrent filer hentet fra en HTTP-server (typisk hvor disse.torrent filer så refererer til en tracker der holder styr på aktive nodes. På den måde kombineres en client-server arkitektur og en decentraliseret peer-to-peer arkitektur. En grafisk illustration kan ses her: 19

20 20

21 3 Communication 3.1 Disposition 1. Definitions Distributed System 2. OSI Model DoD Model 3. Middleware OSI Model 4. RPC 5. Message-Oriented Communication Transient Persistent 6. Multicasting IP Multicast Application-level Multicast 7. Epidemic Protocols Anti-entropy Gossiping 3.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system. 21

22 3.2.2 OSI Model OSI modellen, eller Open Systems Interconnection Reference Model, er en abstrakt beskrivelse af layered kommunikation til netværksprotokoldesign. Dette er den normale OSI model, hvor netværkspakker kører ned gennem strukturen ved afsendelse og får ved hvert lag en ekstra header, som så fjernes lag for lag ved modtagelse. Hvert lag har desuden en række responsibilities, som er blevet defineret således producenter har kunnet bruge OSI modellen til at lave standardiseret netværksteknologier. TCP/IP Model aka. DoD modellen Da vi udelukkende kigger på TCP/IP kommunikation i dette kursus, så kunne det måske også være godt lige at nævne DoD modellen kort, som er den model der blev skabt af Department of Defence til brug sammen med TCP/IP Protokol Suiten til ARPANET. Den beskriver, modsat OSI, kun 4 abstraktionslag og bliver tilsyneladende også indirekte brugt i jeres slides om Communication, der hvor I laver et eksempel på kommunikation mellem en browser og en webserver. 22

23 Så tænkte jeg ville nævne den, nu hvor I ikke direkte gør det! Middleware OSI Model Da en 7-lags OSI-model er lidt for generel i vores tilfælde, så har vi dog en ændret OSI model hvor Presentation og Session er erstattet med et Middleware lag, der er abstraktionen for hele det distribuerede systems softwaredel RPC RPC (Remote Procedure Call) er en kendt teknologi fra UNIX-verdenen til at udføre operationer på andre servere på en transparent måde (specifikt access transparency). Det fungerer ved at man udfører et RPC kald, således det ligner et normalt procedurekald og blot skjuler alle detaljer om den distribuerede udførsel. I den objektorienterede verden bliver det ofte kaldet RMI (Remote Method Invocation) og i Java s tilfælde Java RMI. Man kan så vælge om RPC kaldet skal foregå synkront eller asynkront, i det om den skal vente på den fulde udførsel af operationen på serveren, eller blot på en bekræftelse af modtagelsen af ordren. Disse to scenarier er vist herunder: Synkron RPC 23

24 Asynkron RPC Java RMI Java RMI ( Remote Method Invocation ) er Java s måde at implementere RPC på. For at få RMI til at virke, skal følgende være gjort: Server side - Design og implementation af Remote interfaces vha. UnicastRemoteObject Client side - Definer og implementer security policy - Brug Naming.rebind til at binde server objekt til et navn - Alle metoder kaster RemoteException - Brug Naming.lookup til at finde server objekt - Kør metoder på server objekt Alle parametre til metoder er passed by reference, medmindre de er java.io.serializable, hvor de så er passed by value. 24

25 3.2.5 Message-Oriented Communication Message-Oriented Communication består af flere ting, men er generelt den mest normale måde at udveksle meddelser mellem servere. Normalvis foregår meddelsesudveksling transient, hvilket vil sige meddelser udelukkende bliver gemt i de millisekunder det tager at sende dem. Så hvis en server er nede hvor der bruges transient kommunikation, så meldes der enten fejl eller meddelsen forkastes simpelthen blot. Transient kommunikation er f.eks. det vi har når vi skaber en direkte socket til maskinen vi vil kommunikere med. Men hvad nu hvis server og client ikke nødvendigvis begge er online? Jo, så kan vi bruge Persistent kommunikation, eller såkaldte Message Queuing Systems. Message queuing går, som navnet antyder, ud på at have en kø implementeret på en form for middleware failure-mæssigt uafhængigt af server og klient. Server og klient kan så tilgå denne kø, ved at serveren f.eks. placerer beskeder derpå vha. put() og klienten henter disse vha. get(). Det er præcis denne slags struktur man ser på servere som Postfix eller sendmail. Det kan i visse tilfælde være nødvendigt at oversætte sendte meddelser til et andet format, for at klienten skal kunne forstå dem. Til dette formål implementerer man en Message Broker i middlewaren, hvor denne har en række oversættelsesregler, sørger for at oversætte meddelserne og sender dem videre Multicasting Multicast adressering er en netværksteknologi ment til at muliggøre samtidig kommunikation til en større gruppering af modtagere igennem multicast grupper. Multicast er egentlig to ting. I løbet af kurset har vi fokuseret på Multicast 25

26 implementeret på applikations-lags niveau, men ægte multicast kaldes e- gentlig IP Multicast og er væsentligt mere lowlevel. IP Multicast Selvom IP Multicast faktisk ikke er noget vi har snakket meget om, så vil jeg alligevel lige nævne grundlæggende hvordan det virker, da jeg finder det relevant for forståelsen af teknologien. Det er sådan, at ligesom vi har LAN adresserum i IPv4, så har vi også Multicast adresserum, som ifølge RFC3171 er En adresse i dette rum bliver så tildelt en specifik gruppe, som man så kan tilmelde sig til ved at sende en IGMP pakke (Internet Group Management Protocol). Herefter kan man sende en pakke til gruppen, ved at sende pakken til gruppens adresse, hvorefter routere så sørger for at sende pakkerne til de rette adresser. Store dele af adresserummet er dog reserveret, så i realiteten kan man kun rigtigt benytte sig af /24 netværket, som udelukkende er ment til multicast på det lokale netværk og ikke bør videresendes af en router. Application-level Multicast Application-level Multicast er lidt mere interessant, da vi har langt flere muligheder og ikke er begrænset af trælse adresserum. Multicast bliver på dette niveau implementeret som en abstraktion på det underliggende netværk vha. et overlay netværk. Dette overlay netværk kan laves på to forskellige måder: 1. Mesh-netværk (flere ruter mellem nodes) (Mere robust! Bryder ikke ned hvis en node crasher og ikke passerer pakker videre) 2. Træstruktur (en unik rute mellem nodes) (Hurtigere og skalerer bedre, men mindre robust.) Typisk vil man konstruere overlay-netværket som et minimal-spanning-tree imellem de indvolverede noder, således overlay-netværket er konstrueret optimalt i forhold til linkstress på det underliggende netværk. Når nye nodes tilføjes til multicast-gruppen, så køres der blot en algoritme der igen laver et minimal-spanning-tree for det nye sæt af nodes. Her ses et ikke-optimeret overlay netværk: 26

27 3.2.7 Epidemic Protocols Epidemic protokoller er en særlig form for dessiminationsprotokol jeg personligt synes er fantastisk interessante, da det er et element af evil mastermind i dem : P. De bygger, som navnet antyder, på virkelighedens sygdomme og hvordan de spredes imellem mennesker. Men i stedet for at sprede sygdom, så bruger man dem til at sprede information (medmindre man er en russisk ormeprogrammør, hvorved man rent faktisk ville bruge dem til at sprede sygdom.. men det ser vi bort fra). Man bruger så en særlig terminologi, inspireret af virkelighedens sygdomsmønstre: Inficerede: Nodes der indeholder information der skal spredes. Modtagelige: Nodes der ikke indeholder dataene endnu. Fjernede: Nodes der er opdaterede og uvillige eller uistand til at sprede deres data Der er så 2 forskellige måder at sprede dataene på. Anti-Entropy Anti-Entropy er den typiske måde at sprede data på, og går ud på at en node P vælger en anden node Q tilfældigt og forsøger at udveksle data med denne på en af følgende måder: 1. Ved at push data til Q 2. Ved at pull data fra Q 3. Ved at P og Q sender opdateringer til hinaden (pull & push) 27

28 Hvor den først måske minder mest om en sygdom, så er den ineffektiv, da der efter noget tid vil være rigtig mange inficerede og rigtig få modtagelige, så langt hovedparten af tiden vil den tilfældigt valgte node Q allerede være inficeret. Anden løsning lider under samme problemer, blot omvendt, i det at sandsynligheden for at pull fra en inficeret i starten er lav, men bliver højere som flere nodes bliver inficeret. Den bedste løsning er derfor at gøre begge dele på en gang, hvortil det kan vises, at mængden af tid dette tager er O(log(N)) hvor N er antallet af nodes. Gossiping En anden løsning er også baseret på virkeligheden, men i en lidt anden forstand! Nemlig sladder! Gossiping går ud på, at når en node P modtager en opdatering, så prøver P at kontakte en anden tilfældig node Q og push denne opdatering til Q. Men, hvis Q allerede har fået denne opdatering fra en anden node, så er der 1/k sandsynlighed for P mister interesse i at sprede opdateringen mere. Gossiping er en hurtig måde at sprede information på, men der er ingen garanti for at alle modtager opdateringerne. Faktisk gælder der, at for tilstrækkeligt store mængder nodes, så er fraktionen af disse nodes, som stadig er modtagelige udregnet som: Hvilket for k = 4 giver 0.7%. s = e (k+1)(1 s) 28

29 Tricket er, at man sammensætter anti-entropy og gossiping, således de sidste 0.7% også får opdateringen. 29

30 4 Naming 4.1 Disposition 1. Definitions Distributed System Name, Address & Identifiers Naming System 2. Flat naming Forward pointers Home-based solution 3. Structured naming 4. DNS File systems DNSSEC Primary/Secondary servers Iterativ/Rekursiv opslag Caching 5. Attribute-based naming 6. LDAP 4.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system. 30

31 Def. Name A string of bits or characters that is used to refer to an entity. Def. Address A name that refers to an access point of an entity. Def. Identifiers A name that uniquely identifies an entity. (OBS: Navnet identifier bliver ofte misbrugt, så definitionen overholdes ikke rigtigt. Et eksempel er URI, Uniform Resource Identifier, som i virkeligheden er et name.) Def. Naming System A system that maintains a name-to-address binding Flat naming Flat names er ofte bare tilfældige strenge af bits, så som et NIC s MAC addresse. Disse har så nogle tilknyttede naming systemer, som f.eks. i MACaddressers tilfælde er ARP (Address Resolution Protocol) der oversætter fra IP til MAC og RARP (Reverse Address Resolution Protocol) hvis vi skal fra MAC til IP. ARP og RARP virker dog kun på lokale netværk, da de benytter sig af broadcasting. For at lokalisere maskiner på større netværk, skal vi bruge andre typer naming systemer. Forward pointers Forward pointers er en løsning, hvor en resource efterlader en pointer hvis den skifter position. På den måde kan man altid følge disse pointere for at finde resourcen. 31

32 Metoden lider dog under nogle problemer: 1. Kæden bliver meget lang. 2. Mellemliggende nodes skal vedligeholde links i lang tid. 3. Hvis en pointer forsvinder er resourcen umulig at finde. Af fordele ved metoden kan nævnes, at den giver Migration Transparency, da det skjules at resourcen til tider skifter position. Home-based solution En anden løsning er at definere et hjemstad (såkaldt Home -adresse) for en resource og så oprette en Home Agent der holder styr på positionen af resourcen og sørger for at route data dertil. Når så en klient vil kontakte resourcen, så kontakter den i stedet dens Home -adresse. Her sender Home Agent så adressen på resourcen tilbage til klienten og sender desuden den initielle pakke til resourcen for klienten. På den måde kan klienten lave direkte kontakt til klienten herefter. 32

33 Denne løsning lider dog også under problemer: 1. Hvis Home går ned, kan resourcen ikke lokaliseres. 2. Forøget initiel kommunikation, da Home Agent først skal skabe forbindelsen mellem klient og resource Structured naming Hvor flat names er nemme for maskiner, så er de en anelse upraktiske for mennesker, da det er svært at gennemskue hvad flat names refererer til. I stedet har vi structured names som: /users/mw/public_html/.. eller Som begge giver hints om hvad resourcen er. Vi vil så tage et kig på disse specifikke eksempler. File systems Et eksempel på structured naming er filsystemer. I moderne filsystemer, som f.eks. BSDs UFS eller Linuxs ext3fs, så tilgår man filer vha. en simpel struktur som: /usr/home/illio/somerandomfile Man kan således opstille hele direktivsystemet som en directed graph, som herunder: 33

34 Filsystemerne på Linux/BSD er tilmed også gode til at skabe transparency i forhold til distribuerede filsystemer, som NFS og Samba shares, da en given share på det fjerne system blot mountes i det lokale system og derefter tilgås ligesom enhver anden mappe - Det eneste der muligvis detekteres er lidt latency. Disse shares giver faktisk Access-, Location- og Concurrency transparency. (Sidstnævnte fordi du ikke lokalt kan se brugerne der benytter sharen og derfor ikke ved om andre sidder og tilgår samme data - Men du opdager det selvfølgelig hvis de sletter det du lige pillede ved) DNS DNS (Domain Name Service) er et naming system fra domæne til ip, men faktisk også fra ip til domæne og en masse andre ting. Alle disse informationer gemmes i en heirakisk DNS træstruktur, hvor nodes er domæner og disse domæner så samles som zones, som bliver serviceret af en autorativ DNS server. En DNS server kan desuden godt servicere adskillige zones. Hver af disse domænenodes indeholder så en række resource records (RR), der beskriver nogle informationer om domæner. Nogle af de mere normale RR typer er: NS: Navneserver for et domæne A: IPv4-adresse for et domæne AAAA: IPv6-adresse for et domæne CNAME: Et alias for domænet MX: Mailserver for et domæne PTR: Reverse DNS (IP->domæne) (OBS: ikke altid up-to-date) 34

35 RRSIG: Digital signatur af DNS RR sættet (OBS: Kun ved brug af DNSSEC) DNSSEC DNSSEC (Domain Name System Security Extensions) er en teknologi til at sikre integriteten på verdens DNS-servere. Det fungerer ved at tilføje et RRSIG resource-record, som er en Digital signatur af et RR-sæt og levere dette sammen med alle svar for det pågældende domæne. Klienter kan så tjekke denne værdi ved at tjekke nogle offentligt tilgængelige public keys i form af DNSKEY records. Altså benytter man PKI til at skabe integritet i DNS og derved gøre, f.eks. Kaminsky, umulig. Der er så dog en hel række politiske problemer i at implementere DNSSEC globalt, såvel som en række tekniske. Eksempelvis skal rodserveren implementere DNSSEC før det ordentligt giver mening at gøre det på ens egen DNS-server. DIFO skal desuden også gøre det for.dk domænet - Alt tyder så dog på, at de gør dette snart. Primary/Secondary servers I et RR sæt vil der typisk fremstå adskillige NS records. Dette skyldes at navneservice for et domæne sjællendt blot er en server. Det drejer sig typisk om adskillige servere, hvor den primære server så replikerer sit indhold periodisk til de sekundære servere vha. såkaldte zone-transfers. Som eksempel kan tages min egen webside som har hele 5 navneservere: ns1.gratisdns.dk ns2.gratisdns.dk ns3.gratisdns.dk ns4.gratisdns.dk ns5.gratisdns.dk Replikation her giver jo så dog nogle potentielle consistency problemer, i det at records på den primære server på et givent punkt i tid godt kan variere fra de records der er at finde på de sekundære servere. Iterative/Recursive name resolution Når man så vil slå et givent domæne op, så kontakter man sin pågældende DNS-server (typisk ens ISP, eller OpenDNS i mit tilfælde). Denne ser så om den er autorativ dns server for domænet, hvis ikke sender den requested til 35

36 en rodserver. Denne rodserver vil typisk kun tillade iterativ navneopslag, så den vil finde.tld domænet og give information tilbage til den første DNSserver ang.tld DNS-serverne. Herefter kontakter DNS-serveren.tld og får adressen på DNS til det pågældende domæne osv. osv. Dette er tilfældet hvis hele processen er iterativ. Hvis en DNS server derimod understøtter rekursive opslag, så vil den selv videreføre requested til den næste DNS-server i rækken og til sidste returnere resultatet til klienten. Hvis rekursivitet kunne udnyttes i alle led, ville man teoretisk set kunne få et triple boost på performance ved opslag. Caching For at forbedre performance vil mange DNS resolvere cache værdier de får fra øvreliggende DNS-servere. På den måde vil DNS-servere kunne huske records for domæner i en given mængde tid defineret af den pågældende autorativ DNS-server for det pågældende domæne. 36

37 Desuden vil man, hvis man requester f.eks. måske at vide den er et CNAME for og DNS-serveren vil herefter automatisk give A records for dette domæne også. Denne form for hjælpsomhed kan udnyttes ved at sende fake svar til DNSserveren, som Kaminsky også fremviste Attribute-based naming Det kan nogle gange være nødvendigt at søge på mere end blot et navn, for at få et givent resultat. Derfor har vi også Attribute baserede naming systemer, som mapper en eller flere attributer til en værdi. Det mest normale eksempel på dette er LDAP LDAP LDAP (Lightweight Directory Access Protocol) er en applikationsprotokol til at tilgå og ændre biblioteker over TCP/IP, med data strukturerede i træer. Typisk drejer det sig om organisationsdata som afdelinger, printere, dokumenter, personer, grupper mm., hvor man så kobler LDAP med DNS, således DNS klarer de øverste niveauer af hierakiet og LDAP så tager de lavere organisationsmæssige lag. Til at repræsentere attribute/værdi par bruger man typisk nogle standard forkortelser, som vist herunder: For at søge i træstrukturen laver man så queries med adskillige attributer: search("&(c=nl)(o=vrije Universiteit)(OU=*)(CN=Main server)") LDAP bliver ofte brugt som OpenLDAP til Linux/BSD og Active Directory til Microsoft Windows. Begge benyttes især til bruger-authentication på domænet, således brugerdatabasen kan gemmes på en centraliseret LDAP 37

38 server. 38

39 5 Time 5.1 Disposition 1. Definitions Def. Distributed System 2. Global tid 3. Fysisk tid 4. Synkronisering NTP The Berkeley Algorithm 5. Happens-Before Relation 6. Logical Clocks 7. Vector Clocks 5.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system Global tid I et distribuerede system har vi ofte brug for at analysere aspekter om tid. F.eks. at se hvorvidt en given operation fandt sted før en anden operation? Eller måske sørge for at to operationer sker på præcis samme tidspunkt? Eller måske endda en helt tredje ting? Fælles for alle disse mål er, at de udnytter ideen om en global tid som alle komponenter i et distribueret system er enige om - Problemet er blot, at 39

40 en fuldkommen global enighed om tid er umulig at få, og en rimelig præcis global enighed om tid er svær at få! Fysisk tid Lad os kigge på den fysiske tid på en given maskine. Normale maskiner har en timer på bundkortet. Denne timer bruger så en quartz krystal som oscillerer ved en velkendt frekvens, som får en counter til at tælle ned ved hver oscillerering og når den rammer 0 laves der en interrupt og counteren bliver kørt tilbage til startværdien vha. et holding register. På den måde får man implementeret et ur på en maskine, ved at passe det således at en interrupt sker, f.eks. 60 gange i sekundet. Problemet ved dette ur er blot, at visse krystaler oscillerer ved en minimalt anderledes frekvens, men alligevel anderledes nok til at uret løber for langsomt eller for hurtigt over tid. Dette kaldes clock skew! Men hvordan kan vi effektivt sætte uret til en korrekt tid, som alle kan være enige om? Den nemmest løsning: Synkronisering! Synkronisering Der findes flere forskellige algoritmer til at synkronisere tid, hvor nogle er væsentligt mere brugte end andre. Den første jeg vil kigge på er NTP (Network Time Protocol), som nok er verdens absolut mest brugte løsning til dette problem. NTP NTP (Network Time Protocol) er en protokol til synkronisering af ure henover netværk med variable latency. Det fungerer ved, at man opsætter en dedikeret NTP server, som så får tiden sat korrekt i forhold til UTC (Universal Coordinated Time) på en eller anden måde. For internt brug betyder dette ofte blot, at NTP-serveren også fungerer som NTP-klient for en større server et andet sted. Men for nogle NTP-servere betyder dette, at de får tiden igennem brugen af f.eks. atomiske ure. Klienter kontakter så denne NTP-server når de skal synkronisere, men NTPserveren kan selvfølgelig ikke blot returnere den korrekte tid, da tilfældig netværks latency ville gøre den returnerede tid forældet. NTP bruger derfor en algoritme til at estimere de forsinkelser der bliver ved kommunikation 40

41 over netværket. Kig derfor på nedenstående diagram. Som det ses ovenfor, så sender klient A et request til NTP-serveren B med en timestamp T 1. Når B modtager beskeden, vil den gemme et timestamp med sin lokale tid som T 2. Herefter sender B så en besked tilbage til A, hvor B sender et timestamp for afsendelsen som T 3 og besuden giver værdien for T 2 sammen med T 3. Klienten A modtager så beskeden ved T 4 og noterer denne tid. Herefter udregnes to værdier. Et offset θ og en forsinkelse δ. Dette gøres 8 gange, således man har 8 (θ, δ) par, hvor man så vælger det par med den mindste værdi for forsinkelsen δ og konkluderer, at det mest præcise offset, må være dette δ s makker. Hvis offsettet er negativt kan den pågældende klient dog ikke blot uden videre stille sit ur tilbage, da det ville give problemer i forhold til timestamps på systemet. I stedet gøres tiden langsommere på systemet, således klienten stille og roligt falder bagud til sin korrekte tid. Det skal desuden siges, at NTP kun opdaterer tiden på node A, såfremt den kontaktede node B har en lavere stratum-værdi end A selv. Hvis A s stratum-værdi var højere end B, så vil A s stratum-værdi efter synkroniseringen blive sat til B s + 1. Som referencepunkt kan siges, at præcise ure selv har stratum-værdi 0 og maskiner direkte koblet op af disse har stratum-værdi 1. The Berkeley Algorithm En anden algoritme til tidssynkronisering kommer fra de gæve BSD-gutter i Californien og har en lidt anden fokus. Denne algoritme antager nemlig, at ingen server har en præcis tid og algoritmen prøver derfor ikke på at opnå en præcis tid! I stedet gør Berkeley Algoritmen det, at den sætter en Time Daemon op, som så aktivt anmoder maskiner på netværket om deres tidsdifference i forhold til den selv. Herefter kalkulerer den et gennemsnit og anmoder alle maskiner på netværket om at ændre deres ure til denne nye gennemsnitstid. 41

42 På den måde får alle maskiner i systemet en enighed om tiden, til trods for denne tid så måske ikke passer overens med UTC - men ofte er dette heller ikke nødvendigt! Happens-Before Relation Ofte er det slet ikke nødvendigt at bekymre sig om hvornår præcis en operation fandt sted. Det eneste der ofte er vigtigt er i stedet, hvorvidt operationen fandt sted før en anden operation. Dette bringer os til Happens-Before relationen. Hvis A og B er begivenheder, P er en proces og M er en besked, så siger vi at A happens-before B (A B), hvis en af følgende gælder: 1. A P B ifølge P s lokale ordning 2. A er en afsender og B er en modtager, og A M B 3. A B er en transitiv effekt af 1 og 2. Som eksempel kan vises følgende situation: 42

43 Her kan det, jvf. ovenstående regler, konkluderes at: A p B C q D snd p (m) M rcv q (m) A p snd p (m) M rcv q (m) q D A D Dette er selvfølgelig blot rent matematisk logisk notation, så lad os omdanne det til noget brugbart Logical Clocks Vi kan bruge happens-before relationen i praksis ved at inkorporere nogle af tankerne i en slags logisk ur. Vi kigger først på en ret simpel udgave, som blot består af en enkelt counter (64bit eller større), således at hver proces p har en counter C p, som den vedligeholder, og enhver meddelse m har en counter C m. Når så en proces p har en event af betydning inkrementerer den C p. H- vis p så herefter sender en meddelse m, så sætter den C m = C p, således meddelsen får dens nuværende counter værdi. Når så en anden proces q modtager denne meddelse m, så sætter den C q = max(c q, C m ) + 1, således at tiden bliver sat til den maksimale af de to processers tider og så efterfølgende inkrementeret. Brugen af logiske ure vises nedenfor: Således kan man konkludere at hvis A B så er C(A) < C(B). Desværre kan vi med logiske ure ikke lave den omvendte, og sige at fordi C(A) < C(B), så må A B. For at kunne det må vi forbedre lidt på vores logiske ur, og dette kan vi vha. Vector Clocks. 43

44 5.2.7 Vector Clocks Vektorure er en udvidelse på de logiske ure, hvor to processer så har en counter hver i vektoruret (men hver dog har deres eget lokale vektorur). V C(A) = [q, p] Ligesom før inkrementerer en proces p dens counter ved en event, men nu gøres dette ved udelukkende at inkrementere i vektoruret på p s position. Når vi sender en meddelse sætter vi så V C(m) = V C p, ligesom før og når der modtages en meddelse sættes V C q = max(v C q, V C(m)), næsten ligesom før. Dette lyder måske meget ligesom før, men det har en afgørende forskel. Først og fremmest viser vi lige samme eksempel igen: Som det kan ses ser det jo nogenlunde ligesådan ud som sidst, bortset fra hver proces nu holder styr på den andens tid (eller rettere, deres kendskab til den andens tid). Men den afgørende forskel ligger i, at man nu kan konkludere at hvis A B så er V C(A) < V C(B). Men man kan også konkludere at hvis V C(A) < V C(B) så er A B. Vektorurer kan herefter bruges til et hav af ting, som f.eks. totally ordered multicasting. 44

45 6 Synchronization 6.1 Disposition 1. Definitions Def. Distributed System 2. Multicasting 3. JGroups IP Multicasting Application-level Multicasting Reliable Multicasting Virtual Synchrony Implementationen i Hand-in G4 4. Mutual Exclusion Centralized Algorithm Distributed Algorithm 6.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system Multicasting Når man vil synkronisere imellem flere komponenter, så kan man vælge flere måder at gøre det på, men uanset metoden kommer man ikke uden om at skulle overføre data henover det eksisterende netværk. Der er dog måder at gøre dette nemt, også selvom der skal overføres til adskillige modtagere, og dette er Multicasting. 45

46 Multicast adressering er en netværksteknologi ment til at muliggøre samtidig kommunikation til en større gruppering af modtagere igennem multicast grupper. Multicast er egentlig to ting. I løbet af kurset har vi fokuseret på Multicast implementeret på applikations-lags niveau, men ægte multicast kaldes e- gentlig IP Multicast og er væsentligt mere lowlevel. IP Multicast Selvom IP Multicast faktisk ikke er noget vi har snakket meget om, så vil jeg alligevel lige nævne grundlæggende hvordan det virker, da jeg finder det relevant for forståelsen af teknologien. Det er sådan, at ligesom vi har LAN adresserum i IPv4, så har vi også Multicast adresserum, som ifølge RFC3171 er En adresse i dette rum bliver så tildelt en specifik gruppe, som man så kan tilmelde sig til ved at sende en IGMP pakke (Internet Group Management Protocol). Herefter kan man sende en pakke til gruppen, ved at sende pakken til gruppens adresse, hvorefter routere så sørger for at sende pakkerne til de rette adresser. Store dele af adresserummet er dog reserveret, så i realiteten kan man kun rigtigt benytte sig af /24 netværket, som udelukkende er ment til multicast på det lokale netværk og ikke bør videresendes af en router. Application-level Multicast Application-level Multicast er lidt mere interessant, da vi har langt flere muligheder og ikke er begrænset af trælse adresserum. Multicast bliver på dette niveau implementeret som en abstraktion på det underliggende netværk vha. et overlay netværk. Dette overlay netværk kan laves på to forskellige måder: 1. Mesh-netværk (flere ruter mellem nodes) (Mere robust! Bryder ikke ned hvis en node crasher og ikke passerer pakker videre) 2. Træstruktur (en unik rute mellem nodes) (Hurtigere og skalerer bedre, men mindre robust.) Typisk vil man konstruere overlay-netværket som et minimal-spanning-tree imellem de indvolverede noder, således overlay-netværket er konstrueret optimalt i forhold til linkstress på det underliggende netværk. Når nye nodes tilføjes til multicast-gruppen, så køres der blot en algoritme der igen laver 46

47 et minimal-spanning-tree for det nye sæt af nodes. Her ses et ikke-optimeret overlay netværk: Reliable Multicast Når vi benytter multicast til at kommunikere til en gruppe modtagere, så vil vi også ofte gerne have at denne kommunikation er til at regne med. Man kunne f.eks. sagtens få fejl i situationer som disse: Et medlem joiner/forlader gruppen imens der multicastes. Et medlem crasher midt i at multicaste Der findes et par simple løsninger til problemet. En løsning er hvor alle medlemmer skal returnere en acknowledgement på modtagelsen af en pakke og internt holde styr på den sidste pakke modtaget. Hvis medlemmet så får en pakke der er større end den sidste pakke + 1, så ved vi der mangler en pakke og dette medlem anmoder så på ny om denne pakke. Denne løsning giver dog et kraftigt overhead på acknowledgements hvis der er mange medlemmer. Derfor er det bedre med en lidt anden løsning hvor afsender kun modtager negative acknowledgements, og desuden kun modtager en af disse, da andre medlemmer holder deres NACK tilbage hvis de 47

48 allerede har modtaget en i multicastgruppen - Der vil altså derved altid kun blive sendt 1 NACK, som så resulterer i et komplet gen-multicast af den pågældende pakke. Virtual Synchrony Virtual Synchrony er egentlig blot én anden måde at lave Reliable Multicast på, men med lidt ekstra garanti for at pakker fra nodes der crasher midt i afsendelse enten bliver sendt til alle eller ingen. Virtual Synchrony bruges bl.a. til distribuerede opdateringer. Det går basalt set ud på, at man discarder ikke-fuldendte multicasts, således at hvis en afsender f.eks. crasher midt i at sende, så discardes pakkerne medmindre alle kørende medlemmer har modtaget dem. Alt dette gøres vha. såkaldte views. Så hvis proces 4 lægger mærke til proces 7 er død (hvilket den gør vha. pings eller heartbeats), så kan den multicast et view change request. 48

49 Andre processer, som f.eks. her proces 6, sender alle dens ustabile meddelser, efterfulgt af en flush meddelse. På den måde bliver meddelser der kun nåede en modtager alligevel sendt til alle. Processer, igen her proces 6, installerer så det nye view når den har modtaget flush meddelser fra alle andre. Virtual Synchrony har desuden mulighed for adskillige forskellige former for ordninger af meddelser, fra ingen ordning overhovedet, til ordning af meddelser fra samme proces (FIFO) helt til total ordning af alle meddelser fra alle processer (Totally-Ordered Delivery) JGroups JGroups er et Java toolkit til Reliable Group Communication. Det er således et nemt værktøj at bruge til pålidelig multicast kommunikation. 49

50 JGroups virker ved at man kan oprette Channels, som så er forbundet til en indbygget protokolstak. Denne indbyggede protokolstak har så nogle muligheder for at styre ordningen af meddelser, fra ingen ordning, til Causal og helt til Totally-Ordered. Den måde man bruger det på, er ved at man beslutter sig for et channel navn i fællesskab. Herefter gør hver proces følgende: 1. Skab en ny channel 2. Forbind til denne channel med det førvalgte navn (Dette starter protokolstakken) 3. Send og modtag meddelser fra denne channel. (Den konkrete multicast afhænger af protokolstakken) 4. Eventuelt disconnect fra den pågældende channel (Hvilket stopper den protokolstakken) Lad os så lige kort kigge på hvordan vi brugte JGroups i Hand-in G4 for at få Totally-Ordered Reliable Multicast, da vi skulle synkronisere en række replikationer af vores RPC HTTP-server. Implementationen i Hand-in G4 Til at implementere multicast på vores G3 project med JGroup har vi lavet en ny ResponseConstructor strategi, som så kalder over i noget særligt kode, på en JGroupFacade, som styrer processor i JGroup. Her oprettes en forbindelse til multicastgruppen på en channel, som vi kalder "DAMPd- Dist". Ved oprettelsen af den nye JChannel giver vi den en xml-fil med som parameter. Denne beskriver hvordan vi ønsker at JGroup protokolstakken skal være opsat. Idet man tilkobler sig gruppen, så modtager man en liste med states for at 50

51 sikre, at man er synkroniseret med de andre processor, der også er tilkoblet den pgl. multicastgruppe. Dette gøres vha. JGroups indbyggede funktionalitet til at hente tilstandsinformationer fra andre medlemmer. På den måde har vi lavet et cluster, hvor adskillige RPC-servere kan modtage requests og JGroups sørger så for de konstant er synkroniseret mht. data. En optimal sidste ting man burde have gjort var at smide en load balancer e.lign. foran, således den redirectede til de pågældende servere på en fair måde Mutual Exclusion Præcis som mutual exclusion er et problem på en enkelt maskine, så er det også et problem med distribuerede systemer. Sålænge der er en critical section involveret, så vil mangel på mutual exclusion fucke ting op! Så hvordan implementerer vi Mutual Exclusion distribueret? Der er adskillige løsninger, men jeg vil kun kigge på nogle få. Centralized Algorithm Den simpleste løsning er hvor vi har en koordinator, som alle så kontakter for at bede om tilladelse til at tilgå en critical section, hvorefter koordinatoren så giver acknowledgement tilbage hvis der gives tilladelse. Hvis der ikke gives tilladelse svarer koordinatoren blot ikke. Lad os lave en lille turboanalyse! + Det er en simpel løsning + Mutual exclusion er garanteret + Der kan ikke opstå deadlocks + Der kan ikke opstå starvation + Løsningen er fair (FIFO tilladelse) 51

52 + Kun 3 meddelser pr. resource - Single point of failure - Skalerer som crap! Lad os kigge på en anden løsning. Distributed Algorithm En anden, distribueret løsning, er hvor beslutningen tages ved at udsende requests til alle nodes i en gruppe vha. totally ordered multicast. Man kan således have 3 forskellige situationer: 1. Modtager har ikke bedt om samme resource: Send OK tilbage til afsender 2. Modtager er i gang med at bruge resource: Vent og sæt request i kø 3. Modtager har selv sendt request, gør en af følgende: kø Modtager har nyere timestamp end afsender: Send OK tilbage Modtager har ældre timestamp end afsender: Vent sæt request i Kun når afsenderen har fået OK fra alle andre kan den tilgå resourcen. Når den er færdig sender den OK til alle der venter i en kø. Igen laver vi os en lille turboanalyse! + Mutual exclusion er garanteret + Der kan ikke opstå deadlocks + Der kan ikke opstå starvation + Løsningen er fair (timestamps) 52

53 - Hele n points of failure (Alle venter på OK fra en node, men modtager aldrig da noden er død) - Hele n bottlenecks! Så denne algoritme var ikke just fantastisk! Faktisk viser det sig, at ud af de 4 algoritmer vi har gennemgået i kurset, så er det i sidste ende alligevel den centraliserede der er bedst. Problemerne med skalerbarhed og single-point-of-failure er nemlig fint løselige, da de kan løses ved at implementere redundans. Hvis en koordinator går ned, kan en anden blot overtage. 53

54 7 Consistency 7.1 Disposition 1. Definitions Def. Distributed System Def. Conit 2. Replication 3. Consistency Models 4. Continous Consistency 5. Conit Size 6. Consistent Ordering 7. Reliable Multicast 8. Virtual Synchrony 7.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system. Def. Conit A consistency unit. OBS: Bruges til at betegne den unit for hvilken consistency skal måles. Dette kan være en aktie i et aktiesystem, eller en række i en tabel. 54

55 7.2.2 Replication For at kunne snakke ordentligt om consistency, så er vi nød til først at kigge på hvorfor det i det hele taget er et problem. Consistency problemer er her nemlig kun af en simpel grund, nemlig Replication! Replication går, som navnet antyder, ud på at replikere systemer på flere fysiske maskiner. Hvorfor ønsker man så denne redundans? Jo, det gør man af flere grunde!. Først og fremmest ønsker man redundans for at gøre et system mere fault tolerant, da et redundant system kan tage over hvis det primære system går ned. Men herudover giver det også ekstra muligheder for at skalere systemet simpelthen blot ved at tilføje nye maskiner. Der er dog en grænse for hvor længe dette stadig er praktisk, da vi er nød til at opretholde consistency henover replikationerne, så hvis datamængderne er store og serverne mange, så kan den forøgede pris i båndbrede være for stor i forhold til fordelene Consistency Models Når vi taler om consistency, så mener vi selvfølgelig konsistent data. Men hvad for noget data er det vi taler om? Er det en distribueret database? Et distribueret filsystem? Eller måske noget helt andet? Faktum er, at det er vi faktisk ret ligeglade med, da consistency problemerne er de samme uanset tilfælde. Så længe vi har at gøre med et dataområde man kan læse og skrive til, så har vi samme problemer uanset hvad. Derfor bruger vi en mere generel beskrivelse om et data store, som tillader read/write og desuden spreder data indbyrdes imellem de redundante komponenter. På sådan et data store definerer vi så en såkaldt Consistency Model. En sådan model er blot en kontrakt mellem processer og data storet, således at hvis processer overholder en række definerede regler, så lover data storet at virke korrekt. Så lad os kigge på hvad der skal være indeholdt i sådan en consistency model. 55

56 7.2.4 Continious Consistency (FEJLBEHÆFTET, KIG I BO- GEN) Desværre er komplet 100% konsistens henover replikationer sjællendt muligt. Derfor er man normalt nød til at gå på kompromi og vælge hvilke ting man mener er vigtige for ens system altid at være konsistent om og hvilke ting der kan slækkes på. Derfor definerer vi 3 hovedkategorier af inkonsistens i systemer: Numerical inconsistency (Ex. 0,2 DKK forskel mellem aktiekurser på replikationer) Staleness inconsistency (Ex. Forskelle i hvornår aktiekurser sidst blev opdateret) Order inconsistency (Ex. Forskel i rækkefølgen af opdateringer på replikationer) Dette bringer os så til at bestemme størrelse af vores conit Conit size En conit er, som tidligere nævnt, en consistency unit der betegner den enhed for hvilket consistency skal måles. Vi skal have bestemt en størrelse til vore conits i vores consistency model, således vi kan bestemme hvor stor fejlmargin vi vil acceptere på vore systemer. Vælger vi en for lille conit bliver der konstant kørt opdateringer imellem replikeringer, men vælger vi en for stor conit kan fejlmarginen blive så stor at det måske kan være skadeligt for brugen af vores system. Man kunne måske blive fristet til blot at vælge en lille conit altid, men problemet er kort og godt, at netværket så ville floodes fuldstændig med data og replikering så pludselig ikke ville give mening, da båndbrede prisen ville være for høj. Pointen er derfor: Conits skal være af passende størrelse. Eksempel fra bogen og slides I vore slides tilfælde har vi en conit bestående af to variable x og y. 56

57 Her kan ses to replikeringer af samme system, som så skriver på denne conit, hvor vi antager begge variable blev initaliseret til 0. Replica A har så modtaget en opdatering fra Replica B og har derfor committet den permanent. Desuden har replica A hele 3 usendte opdateringer og derved en ordering deviation (staleness) på 3. Desuden er dens tid nu 15, da den sidste operation blev udført 14. Ved Replica B har vi kun 1 opdatering Replica A ikke har set, hvorfor vi siger Replica B har en numerisk deviation på 1 mht. antal operationer. Flere ting kan siges om denne situation. For mere, se side. 279 i bogen Consistent Ordering Ligesom vores tilladte fejlmargin er vigtig, så er det også vigtigt at definere hvornår vi forventer writes på systemer skal være tilgængelige. Vi har adskillige muligheder her, hvor jeg vil tage nogle stykker af dem og fremvise: Sequential Consistency Sekventiel consistency går ud på at alle processer skal se den samme sammenfletning af operationer, således at read/write operationer kan foregå i en hvilken som helst lovlig rækkefølge ude i de concurrent processer, men alle processer skal se den samme sammenfletning. Dette gør, at absolut tid ikke bliver respekteret, da vi i nedenstående eksempel f.eks. har en write på a, inden en write på b, men de andre processer læser den sidste write først. Det vigtige ligger ikke i, om operationer kom før eller efter hinanden, men blot at processer er enig om hvornår de kom. 57

58 Causal Consistency Causal Consistency er en lidt svagere model end Sequentiel, da denne faktisk tillader forskellige rækkefølger af operationer på forskellige processer, sålænge disse operationer ikke er potentielt kasualt påvirket af hinanden. Hvis disse er kasualt påvirket af hinanden, kræves der dog det samme som ved sequentiel, netop at alle processer ser samme sammenfletning af operationer. Derved er situationen nedenfor lovliv jvf. Causal Consistency modellen: Eventual Consistency Den sidste consistency model jeg vil kigge på er Eventual Consistency, som basalt set anerkender at ikke alle systemer opdaterer konstant og det kan derfor være, at write-write konflikter blot aldrig sker. Derfor har vi i disse systemer, at det eneste man behøves bekymre sig om er read-write konflikter, altså situationen hvor nogen forsøger at læse en entity der er ved at blive skrevet til. Eventual consistency gør så det, at opdateringer bliver kørt ud til replikeringer i en doven fashon, hvor nogle klienter så vil se den gamle værdi og nogle andre vil se den nye, men før eller siden vil alle se den nye, når opdateringen er propageret ud på hele systemet. Netop denne consistency-model bruger DNS, hvor opdateringer til ens DNSrecords kan tage op til 43200s (12 timer) om at propagere ud i hele systemet. 58

59 7.2.7 Reliable Multicast Nu har vi så kigget på hvordan vi gerne vil have vores replikering til at virke og hvordan vores consistency models skal håndtere write-write konflikter osv. osv. Men hvordan udføres opdateringer egentlig på systemkomponenter? Det vil vi kigge på nu! Når vi benytter multicast til at kommunikere til en gruppe modtagere, så vil vi også ofte gerne have at denne kommunikation er til at regne med. Man kunne f.eks. sagtens få fejl i situationer som disse: Et medlem joiner/forlader gruppen imens der multicastes. Et medlem crasher midt i at multicaste Der findes et par simple løsninger til problemet. En løsning er hvor alle medlemmer skal returnere en acknowledgement på modtagelsen af en pakke og internt holde styr på den sidste pakke modtaget. Hvis medlemmet så får en pakke der er større end den sidste pakke + 1, så ved vi der mangler en pakke og dette medlem anmoder så på ny om denne pakke. Denne løsning giver dog et kraftigt overhead på acknowledgements hvis der er mange medlemmer. Derfor er det bedre med en lidt anden løsning hvor afsender kun modtager negative acknowledgements, og desuden kun modtager en af disse, da andre medlemmer holder deres NACK tilbage hvis de allerede har modtaget en i multicastgruppen - Der vil altså derved altid kun blive sendt 1 NACK, som så resulterer i et komplet gen-multicast af den pågældende pakke. 59

60 7.2.8 Virtual Synchrony Men hvad nu hvis node der sender en multicast går ned midt i afsendelsen? Således kan vi have en situation hvor kun halvdelen af alle nodes har modtaget en given pakke og der ikke er nogen mulighed for at gensende pakken. Netop dette problem kan vi løse vha. virtual synchrony, som bl.a. kan bruges til distribuerede opdateringer. Det går basalt set ud på, at man discarder ikke-fuldendte multicasts, således at hvis en afsender crasher midt i at sende, så discardes pakkerne medmindre alle kørende medlemmer har modtaget dem. Alt dette gøres vha. såkaldte views. Så hvis proces 4 lægger mærke til proces 7 er død (hvilket den gør vha. pings eller heartbeats), så kan den multicast et view change request. Andre processer, som f.eks. her proces 6, sender alle dens ustabile meddelser, efterfulgt af en flush meddelse. På den måde bliver meddelser der kun nåede 60

61 en modtager alligevel sendt til alle. Processer, igen her proces 6, installerer så det nye view når den har modtaget flush meddelser fra alle andre. Virtual Synchrony har desuden mulighed for adskillige forskellige former for ordninger af meddelser, fra ingen ordning overhovedet, til ordning af meddelser fra samme proces (FIFO) helt til total ordning af alle meddelser fra alle processer (Totally-Ordered Delivery). 61

62 8 Fault Tolerance 8.1 Disposition 1. Definitions Def. Distributed System Def. Failure Def. Error Def. Fault (aka. bug) 2. Types of failures 3. Reliable Client-Server Server crashes Idempotente 4. Agreement in Faulty Systems The Two-Army Problem Agreement cases 5. Distributed Commit 6. Recovery Two-phase commit Three-phase commit Independent checkpointing Coordinated checkpointing 8.2 Subject details Her gives detaljer på nogle ting, således de hurtigt kan genopfriskes. Disse informationer er dog ikke udtømmende. Konsulter bogen såfremt der ønskes mere Definitions Lad os først få nogle få definitioner på plads, så der ingen misforståelser er. Def. Distributed System A collection of independent computers that appears to its users as a single coherent system. 62

63 Def. Failure Any deviation of the observed behaviour of a system, from the specified behaviour. Def. Error System state where any further processing by the system will lead to a failure. Def. Fault Mechanical or algorithmic cause of an error Types of failures Der er findes adskillige typer fejl vi kan opleve på et distribueret system, men hvor nogle er nemmere at overleve end andre. Dette fremgår også tydeligt af følgende diagram. Crash failures er den type fejl, der er absolut mest tydelig overfor brugeren af systemet, men det er dog ingen måde at vide hvorvidt en crash failure skyldes et reelt crash, eller en servers manglende evne til at kunne svare på et request. Nogle gange vil serveren dog selv broadcaste at den går ned, eller det vil fremgå af nogle centraliserede syslogd logs, men oftest vil serveren blot gå ned uden at give information om noget som helst. Men hvor crash failures er forholdsvis nemme at diagnosiere, da man blot kan tjekke serveren lokalt, så er Arbitrary failures langt værre, da det blot er en server der opfører sig komplet tilfældigt for hvert request og viser ingen tydelig fejlmønstre. 63

64 8.2.3 Reliable Client-Server Communication Hvad kan så gå galt når vi har at gøre med klient-server kommunikation? Der er overordnet følgende typer fejl: 1. Klienten kan ikke kontakte serveren - Netværksfejl - Java RMI fejl - Server nede 2. Serveren kan ikke kontakte klienten - Netværksfejl - Klienten er gået ned - Serveren er gået ned inden den kunne sende noget Server Crashes Hvis vi står i situationen at serveren går ned, så skal klienten beslutte sig for, om den skal gentage sin operation på serveren, eller om serveren allerede har udført operationen inden den gik ned. I praksis vil man ofte lade denne beslutning være op til brugeren selv, da han/hun typisk selv vil kunne undersøge om serveren har udført arbejdet. Men der kan være situationer hvor klienten skal gøre det automatisk, enten fordi vi ønsker failure transparency, eller fordi brugeren ikke selv kan tjekke. Der er 3 forskellige reissue strategier vi kan vælge imellem: 1. At-least-once semantics (Klienten bliver ved til den får svar) 2. At-most-once semantics (Klienten giver op og melder fejl) 3. Exactly-once semantics (Operationen udføres kun en gang Generelt umuligt!!) Som eksempel kan vi tage det at printe et dokument på en printserver. Vi kan stå i en situation hvor serveren går ned inden den når at printe og sende en besked tilbage, men vi kan for den sags skyld også opleve at den når at printe, men ikke når at sende tilbage - eller at den måske ligefrem når ingen af delene. Når der sker en failure og vi får genoprettet serveren, så skal vi så beslutte 64

65 hvorvidt vi vil have klienten til at forsøge igen eller ej. Alt afhængig af den reissue strategi vi vælger, så kan vi opleve at få duplikatprint, kun 1 print eller absolut ingen print. Situationerne er illustreret herunder: Vi kunne dog godt kun printe en gang hvis det blot havde været en idempotent operation. Idempotent Operations Det vi gerne vil opnå, er som sagt Exactly-once semantics, men dette er ikke generelt muligt. Der er dog en måde at gøre det muligt, nemlig ved at bruge idempotente operationer. En idempotent operation er en operation der altid resulterer i det samme, uanset hvor mange gange den udføres. Dette gælder f.eks.: F (x) = x 0 Læs block 3 af en fil Skriv til block 3 af en fil Som eksempler på operationer der IKKE er idempotente har vi f.eks.: G(x) = x + 1 Print et dokument Læs næste blok af en fil Skriv næste blok af en fil Ved kun at bruge idempotente operationer får vi et lidt andet resultat i forhold til reissue strategier: 65

66 Som det ses kan Exactly-once semantics garanteres ved idempotente operationer, såfremt der anvendes en strategi om altid at gensende indtil der kommer bekræftelse Agreement in faulty systems Replication er essentielt i distribuerede systemer for at kunne få ordentlige reliable systemer der scalerer. Men replication giver også nogle problemer hvis vi har 2 eller flere adskilte processor der skal blive enige om noget. Dette fremgår også tydeligt af to-hærs problemet. The Two-Army Problem Vi har 2 hærer. En blå, der er adskilt i to dele på henholdsvis 2000 og 3000 tropper, og en rød på 4000 tropper. Problemet er som følgende: 1. Blå hær vil beslutte om de skal angribe rød hær. 2. Hvis kun en del af hæren angriber, taber blå. 3. Del 1 af blå hær bruger en budbringer til at spørge del 2. (Omission failure: Rød hær kan opsnappe budbringeren!) 4. Del 2 sender budbringeren tilbage med en bekræftelse. Blå hær vil aldrig kunne komme til enighed, da ingen af de to dele på noget tidspunkt ved om rød hær har opsnappet budbringeren, eller om budbringeren af andre grunde er blevet forhindret. Dette fremgår også af nedenstående handlingsforløb: 66

67 Agreement cases Hvordan og hvornår kan man så blive enig? Der er generelt 3 situationer hvor enighed er muligt (ud fra figuren ovenfor): Case 1: Case 2: Case 3: Processer er synkrone og kommunikations delay er bundet. Meddelser er ordnede og transmissionsteknikken er multicast. Processer er synkrone og meddelser er ordnede. Løsningerne er som følger: Case 1 Løsning: fejlet Time-outs kan bruges til at undersøge om en proces er Case 2 Løsning: Hver proces multicaster initiel værdi og alle ikke-fejlede processer vælger den første værdi de modtager Case 3 Løsning: Obskur algoritme vi ikke har fået gennemgået 67

Kaminsky DNS exploit

Kaminsky DNS exploit Syddansk Universitet DM829 Kaminsky DNS exploit Jan Christensen - 241189 Anders Knudsen 150885 12. maj 2012 Indhold 1 Indledning 2 2 Introduktion til DNS 2 2.1 Cache............................... 3 2.2

Læs mere

Computer Networks Specielt om Infrastrukturer og Teknologi

Computer Networks Specielt om Infrastrukturer og Teknologi Computer Networks Specielt om Infrastrukturer og Teknologi Ole Borch Slide 1 Doc Bud på arkitektur (som mange andre steder) Sygehus Hemmelig Meget hemmelig WWW browser WWW Server Dataplejer Staklen Internet

Læs mere

Network Services Location Manager. Håndbog for netværksadministratorer

Network Services Location Manager. Håndbog for netværksadministratorer apple Network Services Location Manager Håndbog for netværksadministratorer Dette dokument indeholder oplysninger om Network Services Location (NSL) Manager og om, hvordan et netværk kan opbygges, så

Læs mere

Styresystemer og tjenester

Styresystemer og tjenester Styresystemer og tjenester Indhold: 1. Introduktion til styresystemer. 2. Processer og tråde. 3. Synkroniseringsmetoder og InterProcesCommunikation. 4. Memory management. 5. I/O og devicedrivere. 6. Filsystemer.

Læs mere

SIP. Session Initiation Protocol TDC IP telefoni Scale. SIP design mål

SIP. Session Initiation Protocol TDC IP telefoni Scale. SIP design mål Session Initiation Protocol TDC IP telefoni Scale design mål Give mulighed for at integrere nye faciliteter efterhånden som de opfindes er ikke en erstatning for det offentlige telefonnet - er helt sin

Læs mere

Oprettelse af DNS Records i Hostnordic Selfcare

Oprettelse af DNS Records i Hostnordic Selfcare Oprettelse af DNS Records i Hostnordic Selfcare Brugervejledning Date: 2011-01-31 Version: 1 Author: Martin Schou Target Level: Customer Target Audience: End User Language: da-dk Side 1 af 8 JURIDISKE

Læs mere

SIP. Session Initiation Protocol. TDC IP telefoni Scale

SIP. Session Initiation Protocol. TDC IP telefoni Scale SIP Session Initiation Protocol TDC IP telefoni Scale SIP design mål Give mulighed for at integrere nye faciliteter efterhånden som de opfindes SIP er ikke en erstatning for det offentlige telefonnet -

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

TCP/IP stakken. TCP/IP Protokollen består af 5 lag:

TCP/IP stakken. TCP/IP Protokollen består af 5 lag: Trådløse netværk TCP/IP stakken TCP/IP er nok den mest benyttede netværks protokol. Protokollen har fået sit navn efter de to vigtigste protokoller i den : Transmission Control Protocol (TCP) og Internet

Læs mere

Netværkslaget Rutning og sammenkobling

Netværkslaget Rutning og sammenkobling Roskilde Universitetscenter, Datalogisk Afdeling E-mail: ncjuul@acm.org Netværkslaget Rutning og sammenkobling Niels Christian Juul Mandag den 2. oktober 2000 Tanenbaum: CN kap. 5 5.1, 5.2, 5.4 Copyright

Læs mere

GUIDE TIL CLOUD DRIVE

GUIDE TIL CLOUD DRIVE GUIDE TIL CLOUD DRIVE Dette er en guide du kan anvende til nemt at komme effektivt i gang med at anvende Cloud Drive Indholdsfortegnelse 1. Tilgængelige Cloud Drive klienter 2. Guide til Windows klienten

Læs mere

Netværkstopologi. - Den logiske og den fysiske! Netteknik 1

Netværkstopologi. - Den logiske og den fysiske! Netteknik 1 Netværkstopologi - Den logiske og den fysiske! Netteknik 1 Netværkstopologi Topologi betyder geometri, dvs. netværkets udseende En introduktion til netværkets grundbegreber! Et firmanetværk LAN, baseret

Læs mere

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

SSSystems.local. Netværk. Sikkerhed. Webserver

SSSystems.local. Netværk. Sikkerhed. Webserver SSSystems.local Netværk Vi har valgt at bygge vores netværk på en måde der sikre at trafik fra DMZ en ikke kan komme ned til vores LAN. Både ved hjælp af firewall regler og NAT. Men for at sikre at vi

Læs mere

Netværksovervågning og -administration

Netværksovervågning og -administration Netværksovervågning og -administration Network management (eng. ord for netværksovervågning og administration) er den brede betegnelse for styring og overvågning af alle netværksenheder og brugere. Enhederne

Læs mere

Sektornet VPN. Opsætning af Novell 4.1x server og klient på. Windows 2000/NT/XP

Sektornet VPN. Opsætning af Novell 4.1x server og klient på. Windows 2000/NT/XP Sektornet VPN Opsætning af Novell 4.1x server og klient på Windows 2000/NT/XP UNI C oktober 2002 Sektornet VPN UNI C oktober 2002 v1.0 Af Jesper Skou Jensen 1 Installation og konfiguration af Netware IP

Læs mere

Opdatering af ISOWARE til version 6.1.0

Opdatering af ISOWARE til version 6.1.0 Opdatering af ISOWARE til version 6.1.0 September 2015 Indhold Kontaktoplysninger... 1 VIGTIGT... 2 Opdatering af trejdepartssoftware... 2 Opdatering til version 6.1.0.... 2 1. Backup af databasen... 3

Læs mere

Windows system administration 1

Windows system administration 1 Windows system administration 1 SAI sw6 F2005 Svend Mortensen Ingeniørhøjskolen i København program Windows domæne modellen Introduktion til Active Directory Brugere Grupper Rettigheder Netkonf Management

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Ruko SmartAir. Updater installation

Ruko SmartAir. Updater installation Ruko SmartAir Updater installation Introduktion. Updateren er en speciel enhed som giver os mulighed for at tilføje, læse og skrive funktioner i en offline installation. Med læse og skrive funktionen kan

Læs mere

Avancerede Datanet. Udviklingen i Netværksarkitekturer. Ole Brun Madsen Professor Department of Control Engineering University of Aalborg

Avancerede Datanet. Udviklingen i Netværksarkitekturer. Ole Brun Madsen Professor Department of Control Engineering University of Aalborg Department of Control Engineering Distributed Real-time Systems Avancerede Datanet Udviklingen i Netværksarkitekturer Ole Brun Madsen Professor Department of Control Engineering University of Aalborg Avancerede

Læs mere

DNS teknisk set. Netteknik 1

DNS teknisk set. Netteknik 1 DNS teknisk set - vi kigger lidt dybere i DNS systemet! Netteknik 1 DNS systemet lidt dybere Som vi tidligere har set er DNS (Domain Name System) et navneoversættelsessystem som er designet til at oversætte

Læs mere

VoIP. Voice over IP & IP-Telefoni. Lars Christensen & René Truelsen, Dec. 2004

VoIP. Voice over IP & IP-Telefoni. Lars Christensen & René Truelsen, Dec. 2004 VoIP Voice over IP & IP-Telefoni Lars Christensen & René Truelsen, Dec. 2004 Oversigt over foredrag VoIP I Dag Hvordan står tingene i dag? Netværksstrukturen for VoIP Benyttede VoIP-standarder/protokoller

Læs mere

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen

IPv6 sameksistens med IPv4. af Laurent Flindt Muller & Jakob Pedersen IPv6 sameksistens med IPv4 af Laurent Flindt Muller & Jakob Pedersen Gennemgangsplan: Network Address Translation Protocol Translation (NAT-PT) - Motivation - IPv4 NAT - NAT-PT - Stateless IP/ICMP Translation

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

DNS systemet. Mercantec 2013 DNS. DNS en hierarkisk zone opdelt navnedatabase. Navnene i DNS er opbygget af 2 dele:

DNS systemet. Mercantec 2013 DNS. DNS en hierarkisk zone opdelt navnedatabase. Navnene i DNS er opbygget af 2 dele: DNS systemet DNS (Domain Name System) er et navne oversættelsessystem som er designet til at oversætte domain navne (www.dr.dk) og host navne til IP adresser. Systemet er udviklet til Internettet i starten

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login

Læs mere

PNI/GRN - 1. kursusgang

PNI/GRN - 1. kursusgang Jens Myrup Pedersen Ass. Professor Networking and Security Center for Network Planning PNI/GRN - 1. kursusgang 10/17/2007 1 Struktur på kurset 5 Kursusgange (JMP 3 gange, JDN 2 gange). Form: 2x 45 minutters

Læs mere

Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt...

Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt... Indholdsfortegnelse Valg af opgave... 2 Introduktion... 2 Problem... 2 Målgruppe... 2 Afsender... 2 Budskab... 2 Kodning... 3 Effekt... 3 Information... 3 Programmering... 3 Design... 4 Brochure... 4 Hjemmeside...

Læs mere

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet

Sikre Beregninger. Kryptologi ved Datalogisk Institut, Aarhus Universitet Sikre Beregninger Kryptologi ved Datalogisk Institut, Aarhus Universitet 1 Introduktion I denne note skal vi kigge på hvordan man kan regne på data med maksimal sikkerhed, dvs. uden at kigge på de tal

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Innovative Business Software A/S

Innovative Business Software A/S Innovative Business Software A/S Technical Note Klienter - Installation og opdatering 26. november 2014 ii MEDDELELSE OM OPHAVSRET Copyright 2014 Innovative Business Software A/S. Alle rettigheder forbeholdt.

Læs mere

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails Casper Fabricius http://casperfabricius.com ActiveRecord O/RM i Ruby on Rails Casper Fabricius Freelance webudvikler - casperfabricius.com 9 års erfaring med webudvikling 6 år med ASP/ASP.NET/C# 3 år med

Læs mere

Internet Protocol (IP)

Internet Protocol (IP) Internet Protocol (IP) IP protokollen: er arbejdsprotokollen i moderne netværks-kommunikation; al kommunikation går gennem den. adresserer pakkerne på lag 3 (netværkslaget). arbejder med forbindelsesløs

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

Citrix CSP og Certificate Store Provider

Citrix CSP og Certificate Store Provider Project Name Document Title TDC Citrix Citrix og Certificate Store Provider Version Number 1.0 Status Release Author jkj Date 5-10-2006 Trademarks All brand names and product names are trademarks or registered

Læs mere

VIGTIG information til alle kunder som kører backup over Internet via SSL - Kræver kundeaktion inden 17. april 2009!

VIGTIG information til alle kunder som kører backup over Internet via SSL - Kræver kundeaktion inden 17. april 2009! VIGTIG information til alle kunder som kører backup over Internet via SSL - Kræver kundeaktion inden 17. april 2009! Det er blevet tid til at opdatere certifikater på alle servere som afvikler backup over

Læs mere

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores

Læs mere

Projektoplæg - AMU kursus 44953 - Netteknik - Server - Videregående

Projektoplæg - AMU kursus 44953 - Netteknik - Server - Videregående Velkommen til projektforløbet på Netteknik - Server - Videregående! Udarbejdet af: Anders Dahl Valgreen, mail adva@mercantec.dk, mobil 23 43 41 30 I dette projekt skal din gruppe i tæt samarbejde med resten

Læs mere

PHP Quick Teknisk Ordbog

PHP Quick Teknisk Ordbog PHP Quick Teknisk Ordbog Af Daniel Pedersen PHP Quick Teknisk Ordbog 1 Indhold De mest brugte tekniske udtryk benyttet inden for web udvikling. Du vil kunne slå de enkelte ord op og læse om hvad de betyder,

Læs mere

Routeren. - og lag 3 switchen! Netteknik 1

Routeren. - og lag 3 switchen! Netteknik 1 Routeren - og lag 3 switchen! Netteknik 1 Routeren en introduktion NETVÆRK 10.0.0.0 NETVÆRK 192.168.1.0 E1 Router E0 S0 NETVÆRK 194.182.2.0 Grundlæggende LAN teknologi består af Ethernet switche der flytter

Læs mere

Basal TCP/IP fejlfinding

Basal TCP/IP fejlfinding Basal TCP/IP fejlfinding Dette notat beskriver en række enkle metoder til fejlfinding på TCP/IP problemer. Metoderne er baseret på kommandoer, som er en fast bestanddel af Windows. Notatet er opbygget

Læs mere

Filr: Næste generation af Fildeling. Flemming Steensgaard fsteensgaard@novell.com

Filr: Næste generation af Fildeling. Flemming Steensgaard fsteensgaard@novell.com Filr: Næste generation af Fildeling Flemming Steensgaard fsteensgaard@novell.com Filr Infrastruktur CIFS, NCP Eksterne, uden for Firewall HTTPS Filr Appliance: Validering edir og/eller AD NCP, CIFS, HTTPS

Læs mere

har jeg hentet nedenstående anmeldelse af et godt program til

har jeg hentet nedenstående anmeldelse af et godt program til Software Fra design af hjemmesider: har jeg hentet nedenstående anmeldelse af et godt program til Wordpress er intet mindre end et genialt program til hjemmesider. For det første er det gratis, og for

Læs mere

SNMP Simple Network Management Protocol. Henrik Thomsen/EUC MIDT 2007

SNMP Simple Network Management Protocol. Henrik Thomsen/EUC MIDT 2007 SNMP Simple Network Management Protocol Henrik Thomsen/EUC MIDT 2007 Overvågning Network Management At overvåge kritiske netværksenheder System Management At overvåge kritiske servere Application Management

Læs mere

EasyRun En løbers bedste ven

EasyRun En løbers bedste ven En løbers bedsteven Anders Arnfast 06525, Martin Søberg 0655, Ken Falk 06504 09 . INDHOLD. Indhold... 2 2. Introduktion... 3 Opsætning... 3 3. System arkitekturdesign... 4 4. Hardware Design... 5 Ethernet

Læs mere

Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner

Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner Virtuel PC Fordele/ulemper Fordele: Lærer nye styresystemer Installerer programmer som kun kan bruges i ældre versioner Ulemper: Reserverer RAM (Windows 7) Problemer med at ureglementeret lukke ned Mister

Læs mere

bnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnm

bnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnm aetcvbnwebintergratorkcvkcvk esrkkwebintergratoriopasdfghj klzxcvbnmqiopasdfghjklzxcvbn mqmwebhostingpasdfghjklzxcv Webserver bnmqwertyuiopasdfghjklzxcvbn Internet, Webhosting, Webserver mqwertyuiopasdfghjklzxcvbnm

Læs mere

MSI pakke til distribution af AutoPilot komponenter.

MSI pakke til distribution af AutoPilot komponenter. MSI pakke til distribution af AutoPilot komponenter. Hermed følger en basal dokumentation for installation af AutoPilot msi pakken. Der vil i det følgende blive forklaret brugen af 4 programmer fra Microsoft,

Læs mere

Sådan installeres og teste WordPress på en lokal server

Sådan installeres og teste WordPress på en lokal server Sådan installeres og teste WordPress på en lokal server Det gratis WordPress blog værktøj er vokset gennem årene til et fuldgyldigt CMS-system content management system). WordPress har forenklet processen

Læs mere

ADIS, WS og Meta Service

ADIS, WS og Meta Service ADIS, WS og Meta Service Om ADIS, Web Services, Værktøjer og Meta Service. Michael Jacobsen Technology Network Management Agenda ADIS og dens udvidelse ISOagriNET Web Service med eller uden fuldt objektmodel

Læs mere

NETVÆRKSKURSUS Oktober November 2014. jmt 07-11-2014

NETVÆRKSKURSUS Oktober November 2014. jmt 07-11-2014 1 NETVÆRKSKURSUS Oktober November 2014 jmt 07-11-2014 2 Netværkskursus 14 17 Oktober 2014 ETHERNET 99% af al datatrafik er på ETH standard http://standards.ieee.org/ https://www.ieee.org/ 802.3 er ETH

Læs mere

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks

SOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks SOSIGW - Driftsvejledning for SOSIGW 1.0 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Kontrol af korrekt driftstilstand... 2 Ændring af statisk konfiguration... 2 Logfil... 2 Backup... 3

Læs mere

M A D S L A R S E N, A S G E R B A L L E G A A R D & J O N A S K R O N B O R G R O S K I L D E T E K N I S K E G Y M N A S I U M.

M A D S L A R S E N, A S G E R B A L L E G A A R D & J O N A S K R O N B O R G R O S K I L D E T E K N I S K E G Y M N A S I U M. M A D S L A R S E N, A S G E R B A L L E G A A R D & J O N A S K R O N B O R G R O S K I L D E T E K N I S K E G Y M N A S I U M mininet EN ØVELSE I AT ETABLERE ET NETVÆRK S E R V I C E O G K O M M U N

Læs mere

Globeteam A/S. Windows Server 2012. Globeteam Virumgårdsvej 17A 2830 Virum. SolutionsDay 2012, den 27. September, Brøndby Stadion

Globeteam A/S. Windows Server 2012. Globeteam Virumgårdsvej 17A 2830 Virum. SolutionsDay 2012, den 27. September, Brøndby Stadion Globeteam A/S Windows Server 2012 Et hurtigt overblik over nyhederne og hvad betyder det for din virksomhed SolutionsDay 2012, den 27. September, Brøndby Stadion Lars Lohmann, Globeteam Principal, Infrastruktur,

Læs mere

Salg af servere. Torben Vig Nelausen Produktchef Windows Server Familien

Salg af servere. Torben Vig Nelausen Produktchef Windows Server Familien Salg af servere. Torben Vig Nelausen Produktchef Windows Server Familien Trin 1: Hvem skal købe en Server? Trin 1: Hvem skal købe en Server? Lyt efter nøgle-ord der kan identificiere en kunde der endnu

Læs mere

Hvorfor skal vi bruge objekt orienteret databaser?

Hvorfor skal vi bruge objekt orienteret databaser? OODBMS Vs. RDBMS 1 Indholdsfortegnelse Hvorfor skal vi bruge objekt orienteret databaser?... 3 OODBMS i erhvervslivet... 4 Bagsiden af medaljen... 5 OODBMS i praksis... 6 Konklusion... 8 2 Hvorfor skal

Læs mere

Den Gode Webservice. version 1.0.1 W 1

Den Gode Webservice. version 1.0.1 W 1 Den Gode Webservice version 1.0.1 W 1 Indhold Introduktion...3 Tid...4 Tidsangivelse...4 Tidssynkronisering...5 Referencer...6 MedCom. Den Gode Webservice version 1.0.1 2 Introduktion Den Gode Webservice

Læs mere

Introduktion til computernetværk

Introduktion til computernetværk Introduktion til computernetværk 24. oktober 2011 Mads Pedersen, OZ6HR mads@oz6hr.dk Slide 1 Plan i dag Netværk generelt Lokalnet Internet Router Kabel/trådløs Firewall Lokal server (forward) Warriors

Læs mere

I denne øvelse vil du få vist hvordan opsætningen af netværket foregår. Målet er at du selv kan konfigurere en IP adresse på din lokal maskine.

I denne øvelse vil du få vist hvordan opsætningen af netværket foregår. Målet er at du selv kan konfigurere en IP adresse på din lokal maskine. I denne øvelse vil du få vist hvordan opsætningen af netværket foregår. Målet er at du selv kan konfigurere en IP adresse på din lokal maskine. Opsætningen her er speciel for dette lokalnetværk, der kan

Læs mere

Om ONEBox... 2 Faciliteter i ONEBox... 2 Overordnet teknisk overblik... 2 Multiple servere... 3 Backup... 4 Sikkerhed... 5 Domæner... 6 Web...

Om ONEBox... 2 Faciliteter i ONEBox... 2 Overordnet teknisk overblik... 2 Multiple servere... 3 Backup... 4 Sikkerhed... 5 Domæner... 6 Web... Om ONEBox... 2 Faciliteter i ONEBox... 2 Overordnet teknisk overblik... 2 Multiple servere... 3 Backup... 4 Sikkerhed... 5 Domæner... 6 Web... 7 Mail... 8 Fildeling... 9 Brugere og grupper...10 Teknisk

Læs mere

OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen

OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen > OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen Publikationen kan også hentes på IT- & Telestyrelsens Hjemmeside: http://www.itst.dk ISBN

Læs mere

Opsætning af Outlook til Hosted Exchange 2007

Opsætning af Outlook til Hosted Exchange 2007 Opsætning af Outlook til Hosted Exchange 2007 Sådan opsættes Outlook 2007 til Hosted Exchange 2007. Opdateret 29. december 2010 Indhold 1 Indledning... 2 2 Outlook 2007 klienten... 2 3 Automatisk opsætning

Læs mere

VLAN, Trunk & VTP. VLAN: Virtual Local Area Network

VLAN, Trunk & VTP. VLAN: Virtual Local Area Network (C) EC MID 2005 VLAN, runk & VP 2003 EC MID, Heh 1 VLAN: Virtual Local Area Network VLAN s er en logisk opdeling af enheder eller brugere VLAN s fungerer på OI lag 2 ( og 3 ) Opbygget af witche ( og Routere

Læs mere

Interconnect. Front end interface

Interconnect. Front end interface Direct Remote Access to Devices (DREAD) Introduktion These Metode Baggrund Prototypen Resultater Konklusioner Kritik og fremtidigt arbejde 5. december 2000 Direct Remote Access to Devices slide 1 Klynger

Læs mere

Software Projekt NoSQL vs RMDB

Software Projekt NoSQL vs RMDB Software Projekt NoSQL vs RMDB Skrevet af Carsten Sørensen, Hans Jørgen Frandsen, Peter Haislund Department of Computer Science, University of Aarhus Aabogade 34, 8200 Arhus N, Denmark 201200089, 19960442,

Læs mere

Netværk & elektronik

Netværk & elektronik Netværk & elektronik Oversigt Ethernet og IP teori Montering af Siteplayer modul Siteplayer teori Siteplayer forbindelse HTML Router (port forwarding!) Projekter Lkaa Mercantec 2009 1 Ethernet På Mars

Læs mere

Peer-to-peer (P2P) og BitTorrent

Peer-to-peer (P2P) og BitTorrent Basim Reza og Jonas Fonseca Datalogisk Institut Københavns Universitet Udvalgte emner indenfor datanet / 2004 efterår Oversigt 1 Introduktion til P2P 2 Hvad er P2P? Løst system af uafhængige, samarbejdende

Læs mere

Applikations Virtualisering. Anders Keis Hansen Anders.keis.hansen@atea.dk

Applikations Virtualisering. Anders Keis Hansen Anders.keis.hansen@atea.dk Applikations Virtualisering Anders Keis Hansen Anders.keis.hansen@atea.dk Hvem er jeg Anders Keis Hansen Arbejder i Ateas konsulent afdeling Baggrund som System administrator, IT Arkitekt primært med fokus

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Exchange 2010 SSL certifikat administration Følgende vejledning beskriver hvordan man vælger hvilke adresser der skal være i ens Exchange 2010 SAN SSL certifikat. Derudover er der tekniske guides til at

Læs mere

2. Systemarkitektur... 2

2. Systemarkitektur... 2 Indholdsfortegnelse 2. Systemarkitektur... 2 2.1 Præsentationsserverarkitektur... 3 2.2 Applikationsserverarkitektur... 7 Version 7.0 Side 1 af 7 5. Systemarkitektur Arkitekturen for Nyt BBR bygger på

Læs mere

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3 1 Indholdsfortegnelse INDHOLDSFORTEGNELSE 2 A5.1 INTRODUKTION 4 A5.2 HTTP RETURKODER 4 A5.3 DIGITAL POST FEJLKODER 7 A5.3.1 DIGITAL POST

Læs mere

Windows Small Business Server (SBS) 2008

Windows Small Business Server (SBS) 2008 Produktgruppe: Server Licensmodel: Microsoft Server Styresystemer Serverlicens Windows Small Business Server (SBS) 2008 Enhedsbaseret klientadgangslicens () Brugerbaseret klientadgangslicens () VEJEN TIL

Læs mere

ISA Server 2006 Del 5. Jesper Hanno Hansen Jphan@wmdata.dk

ISA Server 2006 Del 5. Jesper Hanno Hansen Jphan@wmdata.dk ISA Server 2006 Del 5 Jesper Hanno Hansen Jphan@wmdata.dk Agenda Overblik over sessionen Konfigurerer RDP publisering Konfigurerer Exchange Access (OWA, RPC http og EAS) Næste Webcast Overblik over sessionen

Læs mere

Internettet Netværk. Hvad er netværk?

Internettet Netværk. Hvad er netværk? Internettet Netværk. Internettet består af mange selvstændige netværk som er koblet sammen. På yderste niveau har vi små lokale netværk, så lidt større netværk, nationale netværk og til sidst de internationale

Læs mere

Web services i brug. Anvendelse uden for biblioteksverdenen

Web services i brug. Anvendelse uden for biblioteksverdenen Web services i brug Anvendelse uden for biblioteksverdenen Agenda Visionen bag webservices Tre cases Et kig fremad Nordija Etableret i marts 1998 Udviklingsprojekter Forretningskritiske applikationer Komponenter

Læs mere

vejman.dk WMS/WFS dokumentation vmgeoserver.vd.dk Maj 2013 Udgave 2.0

vejman.dk WMS/WFS dokumentation vmgeoserver.vd.dk Maj 2013 Udgave 2.0 vejman.dk WMS/WFS dokumentation vmgeoserver.vd.dk Maj 2013 Udgave 2.0 Indholdsfortegnelse 1 Indledning... 3 2 WMS generelt... 3 3 WFS generelt... 4 4 WMS/WFS eksterne kald i forskellige formater... 4 5

Læs mere

Ruko Security Master Central Database

Ruko Security Master Central Database Ruko Security Master Central Database RSM benytter en central database, til at udveksle låsesystemer mellem Ruko og låsesmeden. Udvekslingen sker via Internettet, så det er derfor nødvendigt at have en

Læs mere

1. Programmet downloades.

1. Programmet downloades. Vejledning til brug PLATINUM Service Tool på en PLATINUM 7000R3 inverter. (Til brugere af Microsoft Windows 7). Programmet kan anvendes til at hente den komplette eventliste (hændelses-liste), hvorved

Læs mere

Trådløst LAN hvordan sikrer man sig?

Trådløst LAN hvordan sikrer man sig? Trådløst LAN hvordan sikrer man sig? Trådløse acces points er blevet så billige, at enhver der har brug for en nettilsluttet computer et andet sted end ADSL modemmet står, vil vælge denne løsning. Det

Læs mere

Algorithms & Architectures II

Algorithms & Architectures II Algorithms & Architectures II Algorithms & Architectures II Jens Myrup Pedersen Hans Peter Schwefel Kursusholdere Dagens lektion Overordnet mål: At etablere en forståelse for hvordan hardware og hardwarearkitekturer

Læs mere

Fang Prikkerne. Introduktion. Scratch

Fang Prikkerne. Introduktion. Scratch Scratch 2 Fang Prikkerne All Code Clubs must be registered. Registered clubs appear on the map at codeclubworld.org - if your club is not on the map then visit jumpto.cc/ccwreg to register your club. Introduktion

Læs mere

PHP 3 UGERS FORLØB PHP, MYSQL & SQL

PHP 3 UGERS FORLØB PHP, MYSQL & SQL PHP 3 UGERS FORLØB PHP, MYSQL & SQL Uge 1 & 2 Det basale: Det primære mål efter uge 1 og 2, er at få forståelse for hvordan AMP miljøet fungerer i praksis, og hvordan man bruger PHP kodesproget til at

Læs mere

SW6 SAI. Services 1: (Fil) service admin torsdag 7/4 05

SW6 SAI. Services 1: (Fil) service admin torsdag 7/4 05 SW6 SAI Services 1: (Fil) service admin torsdag 7/4 05 agenda Backup / Restore SW pakke management Windows Installer RPM mm Patch management Linux / Windows Backup og Restore I hvilke situationer er der

Læs mere

Håndbog Til CPR services. Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper

Håndbog Til CPR services. Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper Håndbog Til CPR services Bilag 10 Opsætning af CPR klienten til understøttelse af forskellige installationstyper CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6 Side 1 af 6 Indholdsfortegnelse INDHOLDSFORTEGNELSE 1 INTRO 3 STARTEN AF SPECIALISERINGEN 3 ANKOMST TIL SKOTLAND 4 DATABASER 5 NETVÆRK 5 INTERAKTION 5 AFSLUTNING AF SPECIALISERINGEN 5 KONKLUSION 6 Side

Læs mere

Sentinel (Dynamisk IP) til ZyWALL (Statisk IP) VPN Tunnel

Sentinel (Dynamisk IP) til ZyWALL (Statisk IP) VPN Tunnel Sentinel (Dynamisk IP) til ZyWALL (Statisk IP) VPN Tunnel 1. Opsætning af ZyWALL VPN 2. Opsætning af SSH Sentinel Denne side giver en gennemgang af opsætning af VPN mellem Sentinel software klient v1.4

Læs mere

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation

Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Baggrund. 1. Hvad er føderation Baggrundsbeskrivelse for installation af føderation i partnerorganisationer til Danmarks Miljøportal. Miljøportalsekretariatet Ref.: jejnb Den 22. november 2007 Baggrund I forbindelse med strukturreformen

Læs mere

Dan Rolsted PIT. Side 1

Dan Rolsted PIT. Side 1 Side 1 Side 2 Indledning I denne vejledning vil der vises hvordan Office 365 opsættes på de forskellige platforme, herunder IOS (ipad) og Android (HTC One). Derudover vil der også være vejledning til Windows

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

- en introduktion! Oversætter domænenavne til IP-adresser - F.eks: www.jp.dk oversættes til 80.80.12.116 - Bruges dagligt i Internet Browsere

- en introduktion! Oversætter domænenavne til IP-adresser - F.eks: www.jp.dk oversættes til 80.80.12.116 - Bruges dagligt i Internet Browsere Domain Name Service - en introduktion! Domain Name Service - DNS Oversætter domænenavne til IP-adresser - F.eks: www.jp.dk oversættes til 80.80.12.116 - Bruges dagligt i Internet Browsere Oversætter IP-adresser

Læs mere

Rådgivning når viden gør en forskel

Rådgivning når viden gør en forskel 1 Rådgivning når viden gør en forskel Hvad siges der i medierne - 1 Computerworld d. 20 september 2010 2 Hvad siger medierne - 2 ZD- NET 9 august 2010 3 Agenda Opsummering på IPv4 Status på IPv4 Opsummering

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note PC Klient 2.4.0.17 o Support for at Domain maskiner kan logge på ConnectAnywhere automatisk med Windows credentials Løsningen forudsætter/kræver at man logger på Windows

Læs mere

Opsætning af FTP- og webserver 22. januar 2007

Opsætning af FTP- og webserver 22. januar 2007 Opsætning af FTP- og webserver 22. januar 2007 Mads Pedersen, OZ6HR mads@oz6hr.dk Plan Generelt: Teori og praksis. Tager sikkert ikke så lang tid Hvad bruges en FTP- og webserver til? Hvad skal der bruges

Læs mere