Practicum Distributed Systems 21 december 2001 Inhoudsopgave 1 Overzicht van de architectuur 2 1.1 Client................................. 2 1.2 Front-end............................... 2 1.3 Replication Manager (RM)..................... 3 2 Overzicht van de entiteiten 3 2.1 First Author............................. 3 2.2 Co-author............................... 3 2.3 Reviewer................................ 3 2.4 Supervisor............................... 4 2.5 Document............................... 4 3 Use Cases 4 3.1 inloggen................................ 4 3.2 nieuw document maken....................... 4 3.3 bestaand document openen..................... 5 3.4 client doet aanvraag tot bewerken van onderdeel......... 5 3.5 client voegt onderdeel toe...................... 5 3.6 client stuurt update......................... 6 3.7 client vraagt updates op....................... 6 3.8 client commit een bewerkt deel................... 7 3.9 First author of co-author stuurt een aanvraag tot nakijken naar reviewer................................ 7 3.10 reviewer antwoordt op een aanvraag op nakijken......... 8 3.11 supervisor stuurt waarschuwing naar rst author......... 8 3.12 bericht(en) ontvangen........................ 9 3.13 client wijst rol toe.......................... 9 3.14 uitloggen............................... 9 4 Collaboration Diagramma's 9 5 Gebruikte Technologieen 10 1
6 Ecientie en Schaalbaarheid 10 7 consistentie 10 8 Fouttolerantie 10 8.1 Server crash/onbereikbaar...................... 10 8.2 Front-end crash/onbereikbaar.................... 11 8.3 Client crash.............................. 11 9 High availability 11 10 Glossary 11 1 Overzicht van de architectuur We maken gebruik van een 2-lagen structuur, want de applicatie- en presentatie-laag zitten in de client(s). Het verwerken van de gegevens (tekstverwerking) gebeurt enkel aan de client-zijde. De gegevens zelf worden opgeslagen op een server, dit is een netwerk van replication managers (RM). Communicatie tussen de clients en de replication managers gebeurt via front-ends. 1.1 Client Een client is een entiteit die verschillende rollen kan vervullen: First Author, Co-author, Reviewer en/of Supervisor. Een client zorgt voor: Bewerken van gegevens Versturen en ontvangen updates (indien hij/zij de juiste rol vervult) Versturen en ontvangen van berichten (afhankelijk van de rol die hij/zij vervult) 1.2 Front-end Een front-end is een entiteit die de communicatie tussen client en replication managers verzorgt. Een front-end zorgt voor: Doorsturen van berichten en updates tussen clients en replication managers. bijhouden van de identiteit van de verbonden clients. 2
1.3 Replication Manager (RM) Een replication manager is een entiteit die de gegevens bewaart en zijn data consistent houdt met de andere replication managers. Een RM zorgt voor: Locking Identicatie van de clients Openen van een bestaand document Aanmaken van een nieuw document Wijzigen van een bestaand document op basis van updates komende van de front-ends Doorgeven van reviews, aanvraag tot nalezen en/of waarschuwingen naar bevoegde client(s) 2 Overzicht van de entiteiten 2.1 First Author Aanmaken van document Editeren van document Co-authors aanstellen Reviewers aanstellen Reviewers vragen om na te kijken Heeft laatste woord over content en layout 2.2 Co-author Editeren van document Reviewers aanstellen Reviewers vragen om na te kijken 2.3 Reviewer Document nakijken Commentaar sturen naar author(s) 3
2.4 Supervisor Controleren de vooruitgang van het document Sturen waarschuwingen naar First Author bij een probleem 2.5 Document bevat een lijst met onderdelen en bijhorende locks en identiers verwijzing naar alle clients (met hun rol en rechten) die betrekking hebben tot dit document. 3 Use Cases 3.1 inloggen client connect met front-end client stuurt userid, paswoord front-end stuurt userid,paswoord naar server server identiceert bij falen : stuur faal-bericht,userid naar front-end bij succes: haal berichten voor userid op geef succes bericht + eventuele berichten + userid aan front-end stuurt door naar client, sluit connectie bij falen 3.2 nieuw document maken client stuurt naam naar front-end front-end stuurt userid,naam naar server server controleert of document met gegeven naam bestaat indien bestaat geef foutboodschap,userid terug aan front-end indien onbestaand maak nieuw document aan met gegeven naam maak sentinel aan registreer userid als rst author RM geeft succesboodschap,userid door aan front-end front-end stuurt door naar client 4
3.3 bestaand document openen client geeft naam door aan front-end front-end geeft userid+naam door aan server server controleert dat userid gemachtigd is om document te lezen indien nee geef foutboodschap,userid aan front-end front-end geeft terug aan client indien ja geef succesboodschap + userid + volledig document inclusief updates + eventuele locks op dit document voor dit userid + laatste update-tijd aan front-end front-end geeft terug aan client client vervangt zijn eventuele huidige lijst met locks door de gekregen lijst 3.4 client doet aanvraag tot bewerken van onderdeel client geeft naam van document + onderdeelid aan front-end front-end geeft userid,naam,onderdeelid door aan server is userid gemachtigd om document te bewerken en onderdeel is niet de sentinel en [onderdeelid niet gelocked of lock expired]? indien ja verwijder lock op het onderdeel als er een is lock onderdeelid met userid, huidige tijd geef succesboodschap,userid terug aan front-end indien nee geef foutboodschap,userid terug aan front-end front-end geeft door aan client 3.5 client voegt onderdeel toe client geeft naam van document + onderdeelid van het voorgaande onderdeel in het document, aan front-end front-end geeft naam, onderdeelid, userid door aan server is userid gemachtigd om document te bewerken en is onderdeel onderdeelid gelockt door userid? 5
dan voeg een nieuw onderdeel toe, vlak na het onderdeel waar onderdeelid naar verwijst bewaar huidige tijd, userid en update-informatie in de lijst met updates lock nieuwe onderdeelid met userid, huidige tijd geef succesboodschap,userid,nieuwonderdeelid terug aan frontend front-end geeft boodschap door aan client anders geef foutboodschap, userid terug aan front-end front-end geeft boodschap door aan client 3.6 client stuurt update client geeft naam van document, onderdeelid en update-informatie door aan front-end front-end geeft naam, update-informatie, userid door aan server als userid gemachtigd is om document te bewerken en onderdeelid is gelocked door userid dan bewaar update, huidige tijd, userid bij het onderdeelid van dat document indien update niet leeg is update locktijd van lock geef succesboodschap,userid terug aan front-end anders geef foutboodschap,userid terug aan front-end front-end geeft boodschap door aan client 3.7 client vraagt updates op client geeft naam van document en laatste gekende update tijd Tijd door aan front-end front-end geeft naam, Tijd en userid door aan server als userid gemachtigd is om het document te lezen en er zijn nieuwe updates sinds Tijd dan 6
geef succesboodschap met nieuwe updates met update tijden, userid terug aan front-end front-end stuurt door naar client client voert updates uit en onthoudt meest recente update tijd anders geeft foutboodschap,userid terug aan front-end front-end geeft door aan client 3.8 client commit een bewerkt deel client geeft naam, onderdeelid en update-informatie mee en stuurt update door (Zie 3.6) en server verwijdert lock van het bewerkte deel als update geslaagd is 3.9 First author of co-author stuurt een aanvraag tot nakijken naar reviewer client stuurt naam van document en lijst met gewenste reviewers naar front-end front-end stuurt naam van document, lijst met reviewers en userid naar server is client gemachtigd om aanvraag tot review te doen voor dit document en is elke gewenste reviewer geldig en gemachtigd om het document te reviewen? ja nee machtig elke gewenste reviewer in de meegegeven lijst om het document te reviewen (dit komt neer op het document openen) voeg voor elke gewenste reviewer, de aanvrager van de review toe aan de lijst met aanvragers tot review van het document stuur een bericht naar elke gewenste reviewer in de meegegeven lijst om het document te reviewen geef succesboodschap, userid terug aan front-end geeft foutboodschap,userid terug aan front-end front-end geeft door aan client 7
3.10 reviewer antwoordt op een aanvraag op nakijken client stuurt naam van het document, userid van aanvrager (auserid) en review door naar front-end front-end stuurt naam van document, auserid, review en userid door naar server komt auserid voor in de lijst met aanvragers tot review door userid van het document? ja nee stuur een bericht naar auserid met de naam van het document en het review verwijder auserid uit de lijst met aanvragers tot review door userid van het document als de lijst met aanvragers tot review door userid van het document leeg is, ontneem userid dan het recht om het document na te kijken geef succesboodschap,userid terug aan front-end geeft foutboodschap,userid terug aan front-end front-end geeft boodschap door aan client 3.11 supervisor stuurt waarschuwing naar rst author client stuurt naam van het document, waarschuwing en auserid door naar front-end front-end stuurt naam van het document, waarschuwing, auserid en userid door naar server is userid een supervisor voor het document en auserid de First Author van het document? ja nee stuur bericht met waarschuwing en naam van het document naar auserid geef succesboodschap,userid terug aan front-end geeft foutboodschap,userid terug aan front-end front-end geeft boodschap door aan client 8
3.12 bericht(en) ontvangen client vraagt aan front-end om na te gaan of er berichten zijn front-end stuurt userid door naar server zijn er berichten voor userid? ja nee stuur succesboodschap,userid en boodschappen voor userid door naar front-end verwijder berichten voor userid van de server stuur foutboodschap,userid door naar front-end front-end geeft boodschap door aan client 3.13 client wijst rol toe client stuurt naam van document, auserid en rol door naar front-end front-end stuurt naam van document, auserid, rol en userid door naar server is userid gemachtigd om de rol toe te kennen aan auserid voor dit document? ja nee ken rol toe aan auserid voor het document stuur succesboodschap,userid door naar front-end stuur foutboodschap,userid door naar front-end front-end geeft boodschap door aan client 3.14 uitloggen client stuurt commit van alle onderdelen waar hij/zij een lock voor is toegekend. (Zie 3.8) client sluit de connectie met de front-end af. 4 Collaboration Diagramma's Zie bijlage 9
5 Gebruikte Technologieen 2-lagen-architectuur TCP/IP protocol client-server Gossip protocol (met immediate ordering) bij de replication managers E-mail variant kloksynchronisatie tussen RM's via NTP 6 Ecientie en Schaalbaarheid ecientie Hangt af van de instellingen van de client (tijd tussen updates). Timestamps voor de updates. Dit is nodig om niet altijd dezelfde updates op te vragen aan de RM's. schaalbaarheid De enige bottleneck is Gossip. Zolang de bandbreedte van het netwerk dat de RM's onderling verbindt voldoende hoog is, kunnen er zonder problemen zowel RM's als clients worden toegevoegd. 7 consistentie locking van de onderdelen. het gebruik van Gossip houdt de RM's onderling consistent (vooral door immediate ordering). hier is er vooral een trade-o gemaakt tussen consistentie en netwerkbelasting. waarbij het meeste belang werd gehecht aan de consistentie. 8 Fouttolerantie 8.1 Server crash/onbereikbaar Bij het falen van een server nemen de andere replication managers over. Front-ends verbonden met de falende server, verbinden met een van de overige RM's. 10
De front-ends zorgen ervoor dat de eventueel nog niet gecommitte data de server bereikt door over te schakelen op een andere RM bij het falen van de huidige. De client merkt hier niets van. 8.2 Front-end crash/onbereikbaar Bij het falen van een front-ends, verbinden de clients die daarmee verbonden waren, op een andere front-end. Hierbij starten ze opnieuw de login-procedure. Nog niet gecommitte updates worden opnieuw verstuurd, ditmaal langs de nieuwe front-end. Ook hier merkt de gebruiker niets van. 8.3 Client crash Bij het falen van een client, gaan al de nog niet gecommitte gegevens verloren. Bij het opnieuw verbinden van de client op een front-end en het hernemen van het werk, behoudt de client de locks die hij had. Dit gaat echter enkel op indien de client opnieuw connect binnen een zekere tijdsspanne. Uiteraard gaat dit niet ongemerkt voorbij. 9 High availability High availability wordt bereikt via het gebruik van : RM's het Gossip protocol (immediate ordering) 10 Glossary sentinel: leeg tekstonderdeel dat altijd vooraan staat, en niet editeerbaar of verwijderbaar is. lock: bevat userid en wordt gezet op een onderdeel. onderdeel: een elementair stuk tekst. front-end: front-end kent userid van bepaalde connectie. 11