Home Papers Reports Projects Code Fragments Dissertations Presentations Posters Proposals Lectures given Course notes
<< 15. Various Cases of Peer-to-peer distributed systems17. Examination Questions 1999-2000 >>

16. Examination Questions 1998-1999

Werner Van Belle1 - werner@yellowcouch.org, werner.van.belle@gmail.com

1- Programming Technology Lab (PROG) Department of Computer Science (DINF) Vrije Universiteit Brussel (VUB); Pleinlaan 2; 1050 Brussel; Belgium

Abstract :  A variety of questions used in 1998/1999.

Reference:  Werner Van Belle; Examination Questions 1998-1999;


1. Java RMI

We willen een whiteboard implementen die geen gebruik maakt van een centrale ‘repeater’ service. Schrijf neer hoe dit gedaan kan worden in Java met behulp van Java RMI. Bespreek hoe clients kunnen’ joinen’ aan dit ‘gedistribueerde’ whiteboard.

2. Cborg

Mobiliteit binnen gedistribueerde systemen kan gebruikt worden om aan automatisch positiemanagement te doen. Hierbij tracht men agents die veel met elkaar interageren naar elkaar toe te verhuizen.

A: systeemagenten

De eerste setup bestaat uit een aantal geconnecteerde agentsystemen die elke een ‘systeemagent’ draaien. Deze systeemagent logt voor elke agent het aantal berichten dat deze agent naar een andere agent stuurt. Eveneens wordt het aantal ontvangen en verstuurde berichten van en naar andere agents gelogt.

Systeemagent:

GetAgentnames(CB)::{CB.agentnamesare(agentself(),[<agentnames>])}
GetAgentInfo(Agentname, CB)::{CB.agentinfofor(agentname,[<verzonden>],[<ontvangen>])
[<verzonden>]
is een array waarbinnen <naar>,<aantal> koppels staan.
[<ontvangen] is een array waarbinnen <from>,<aantal> koppels staan.

We hebben beschikking tot een schedulingalgoritme

[agent,place] Schedule([agentfrom x agentto, aantal], [agent, place])
[agentfrom x agentto, aantal]
is een tabel die voor elke communicatie tussen twee agents een rij bevat, met daarbij een aantal geannoteerd.
[agent,plaats] is een tabel die voor elke agent weergeeft op welke positie deze verkeert.
[agent,place] is de uitvoer van het algoritme en is een tabel waarin staat welke agent naar waar moet migreren.

Schrijf een scheduler agent die op geregelde tijdstippen de nodige informatie vergaart, berekent wie naar waar moet en de agents effectief migreert.

B: proxy agenten

De bovenstaande setup is bruikbaar als we een volledige reeks agentsystemen willen schedulen. Het wordt helaas moeilijker als niet elk agentsysteem een dergelijke systeemagent heeft draaien. Vaak komt het voor dat een bepaalde applicatie, zijn eigen scheduling algoritme wil gebruiken en enkel de agents wil schedulen die bij de applicatie horen.

Hetgeen we hierbij dan trachten te doen is elke agent uit te breiden met een proxy agent die al de berichten bestemd voor de originele agent ‘redirect’ naar de eigenlijke agent en zo zelf logt welk verkeer er van en naar elke agent gaat.

Schrijf dergelijke proxy agent als u weet dat Cborg uitgebreid is met de volgende primitieven. Leg uit hoe we automatisch elke agent binnen de applicatie kunnen voorzien van dergelijke proxy.

Bind(<naam>, <agent>): Deze primitieve bindt de gegeven naam aan de gegeven agent. Dus de agent <agent> krijgt een extra naam.
MessageNotUnderstood(<message> m): op het ogenblik een bericht binnenkomt voor agent B en er is geen primitieve om dit bericht op te vangen zal er een messageNotUnderstood op B aangeroepen worden die de message als parameter heeft.
SendMessage(RDC, <message> m): om zelf een bericht verder te sturen kunnen we een SendMessage call gebruiken. RDC bevat de agent naar waar het bericht moet. Message m bevat het bericht dat doorgestuurd moet worden.

C: Proxy agenten en gedistribueerde scheduling algoritmen

We hebben een gedistribueerd scheduling algoritme ter onze beschikking gekregen. Het algoritme zelf is een klein proces dat op elke proxy agent draait en dat aan zijn communicatiepartners moet vragen hoeveel communicatiepartners die heeft op verschillende machines. Uit de data die hieruit volgt kan het algoritme bepalen naar waar de agent moet verplaatsen.

Pas uw bovenstaande proxy agent aan zodat dit gedistribueerd algoritme er in past.

3. Implement Java RMI !

Stel dat u de persoon bent die Java RMI libraries moet implementeren. Hoe zou u dit doen ? U kan gebruik maken van TCP/IP of UDP/IP, al naargelang uw keuze. Het uiteindelijke resultaat moet zich exact hetzelfde gedragen als de huidige RMI specs.

A: Bespreek threading binnen uw design, geef een aantal cases van RMI calls en teken daarbij control flow diagrammen.
B: Stel een intern protocol samen dat gebruikt kan worden om te communiceren tussen de client en de server.
C: Bespreek hoe objecten getransfereerd worden. Hoe wordt code getransfereerd ?
D: Bespreek in details hoe een stub eruit ziet. Hoe wordt een stub geserialiseerd ?
E: Bespreek in details hoe een skeleton eruit ziet. Hoe wordt een skeleton geserialiseerd ?
*F: Java kent reeds mobiele code daar de classloader classen opstuurt daar waar nodig. Java kent daarentegen geen mobiele processen. Leg uit hoe we dit toch kunnen verwezenlijken in Java.

4. Implement Borg

Stel dat u de persoon bent die Cborg moet implementeren. Hou zou u dit doen ? U kan gebruik maken van TCP/IP of UDP/IP, al naargelang uw keuze. Het uiteindelijk resultaat moet zich exact hetzelfde gedragen als de huidige Cborg implementatie. Als u twijfelt over een bepaald gedrag van Cborg, leg uit wat voor methode u zou hanteren en waarom u deze keuze maakt.

A: Bespreek threading, geef een aantal cases van Message Sends.
B: Stel een intern protocol samen dat gebruikt kan worden om te communiceren tussen verschillende agent systemen
C: Bespreek hoe berichten getransfereerd worden. Bespreek hoe agents getransfereerd worden.
D: Bespreek in details hoe dictionaries (objecten in pico) behandeld worden.
E: Bespreek hoe objecten teruggevonden en benoemd worden. Bespreek hoe we name clashes kunnen vermijden bij het creeeren van nieuwe objecten.
*E: Cborg is een taal waarbij de message sends asynchroon zijn. Bespreek hoe we synchrone message sends kunnen implementeren.

5. Online Agents

Borg Basics

Ter uwer informatie staat hieronder een korte overview van de CBorg basics.

1 Elke agent bestaat uit een reeks data en code die uitgevoerd wordt, doch slechts 1 enkele thread. Binnen een aaneenschakeling van agentsystemen hebben we een massa agents die parallel uitgevoerd worden.

  1. Objecten worden gecreeerd als volgt

makepoint(x,y)::
{
getx()::x;
gety()::y;
setx(nx)::x:=nx;
sety(ny)::y:=ny;
clone()
}

p:makepoint(10,200);
display(p.getx());
p.setx(100);
display(p.getx())

3 Refereren naar een remote object, of naar het root-object van een andere agent.

a:remotedict(“tecra/ses1”)

a.msg(parameter1,…,parametern)

c:remotedict(“tecra”);
agentmove(c)

Httpd basics

Een HTTP Daemon is een programma dat een bepaald poort (normaal poort 80) opeist en daar fungeert als webserver. Clients connecteren aan een webserver altijd via TCP/IP. Elke maal een pagina opgevraagd wordt, wordt een nieuwe socketconnectie geopend met de server. Via deze socket stuurt de client een GET–request naar de server. De server zal dan de homepage via dezelfde connectie terugsturen naar de client.


Client

Network

Server

Open connectie


Send Request

 GET /students/~person




Lees request


 <html> Hallo daar </html>

Stuur antwoord


Sluit Connectie

Toon Page



De meeste HTTP daemons hebben voorzieningen om aan de serverkant een programma uit te voeren die de geschikte homepage genereert. Dit zijn de zogenaamd CGI-bin scripts. De executie loopt voor 1 sessie ongeveer als volgt:

Client

Network

Server

Open connectie


Send Request

 GET /students/cgi/counter.pl




Lees request



Start cgibin programma



Wacht op antwoord van CGIscript


 <html> You are visitor nr 1324 </html>

Stuur antwoord terug


Sluit Connectie

Toon Page



Op sommige webpaginas staat een form waarop data ingetikt kan worden. Na het induwen van submit wordt de data ingegeven in de form opgestuurd naar de webserver. Dit gebeurt door een GET te doen van een homepage waar extra data in de URL meegegeven wordt. Bijvoorbeeld:

Client

Network

Server

Send Request

 GET /students/start.html

Lees request


 <de whatisyourname Form met daarin een actie-referentie naar /students/nameis.html>

Stuur Antwoord Terug

Toon Page, gebruiker tikt name in en slaagt op Enter



Send Request

 GET /students/nameis.html?name=brups&sex=depends

Lees Request

Toon nieuwe page

Stuur antwoord terug

De Opgave: Agents Online:

We willen in staat zijn in het agentsysteem een agent te schrijven die op bepaalde HTML-requests antwoord. Werk hiervoor een design uit, bespreek welke aanpassingen nodig zijn aan de virtuele machine en bespreek hoe u uw ‘oplossing’ kunt gebruiken als programmeur van ‘HTML-agents’. Beantwoord de vraag in 3 delen.

A: Bespreek hoe u webpages zou implementeren met agents (/12)

B: Het is duidelijk dat deze opdracht compleet onmogelijk is zonder Cborg aan te passen (hoe wordt bijvoorbeeld een incoming connectie zichtbaar gemaakt binnen Cborg, om maar iets te noemen). Leg uit welke aanpassingen u dient te maken aan de interpreter. (/4)

C: Validatie van uw design

  1. Beschrijf hoe we een webpagina waarop een form staat. Als in deze form de naam wordt ingetikt wordt een nieuwe webpagina geladen waarop staat ‘Hallo <name>’ (/2)

  2. Hoe worden URL’s opgevangen die niet bestaan. Als u geen opvang voorzien hebt hoe zorgt u er dan voor dat er automatisch een ‘Unknown URL’ message komt ? (/1)

  3. HTTP Protocol v1.1 (of iets in dien trend, mijn versienummering is een beetje de mist in) maakt het mogelijk dat een client een socket opent naar de server en dat hij meer dan 1 request stuurt. Dit is de fameuze keep-alive methode. Waar en hoe past u uw design aan om rekening te houden met dit nieuw gegeven ? (/1)

OPMERKING: Juiste HTML code is niet interessant, exact juiste Cborg code is eveneens niet interessant. Wat wel interessant is, is een design van dergelijke application. Welke functies u zou laten bestaan en wat deze functies doen. Bijvoorbeeld: schrijf niet hoe u formdata parsed (dus hoe de functie de string in stukken bijt), schrijf wel waar u de formdata parsed en wat voor invoer en uitvoer de functie heeft. U mag met OMT schemas werken maar beschouw dit zeker niet als verplichting. OMT is meestal niet echt geschikt om gebruikt te worden binnen gedistrbueerde systemen.

6. Distributed GPM

GPM is een muis tooltje voor linux machines. GPM geeft de mogelijkheid om met de muis op het scherm een region aan te duiden en deze te copieren in een clipboard. Nadien kan deze clipboard gepaste worden met de rechtermuisknop (eventueel op een andere virtuele console). Laat ons ervan uit gaan dat GPM de volgende interne functies heeft:

CopyRegion(Buffer b) void

Deze functie wordt opgeroepen vanuit de muisinterface op het ogenblik dat een region geselecteerd is en losgelaten. Deze functie moet de gegeven buffer copieren naar het clipboard.

PasteAtPos() Buffer

Deze functie wordt opgeroepen vanuit de muisinterface op het ogenblik de gebruiker de rechtermuisknop duwt om te pasten. Deze functie geeft de text weer die gepaste wordt.

Herschrijf deze 2 functies zodat we in staat zijn tussen verschillende machines te copieren en te pasten. Werk een systeem uit om te weten welke buffer we willen pasten.

The choice is yours.

Opgave: Schrijf de 2 functies, de initialisatie en leg uit hoe u te werk gaat. U kan kiezen welke taal u gebruikt, Java met RMI, Cborg, CORBA, sockets, TCP/IP, UDP/IP. Zorg dat uw pseudocode meer ‘code’ allures dan ‘pseudo’ allures heeft ;-)


http://werner.yellowcouch.org/
werner@yellowcouch.org