Home | Papers | Reports | Projects | Code Fragments | Dissertations | Presentations | Posters | Proposals | Lectures given | Course notes |
<< 15. Various Cases of Peer-to-peer distributed systems | 17. Examination Questions 1999-2000 >> |
16. Examination Questions 1998-1999Werner Van Belle1 - werner@yellowcouch.org, werner.van.belle@gmail.com Abstract : A variety of questions used in 1998/1999.
Reference:
Werner Van Belle; Examination Questions 1998-1999; |
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.
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.
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.
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.
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.
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.
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.
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.
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”)
Sturen van een bericht naar een
remote object
a.msg(parameter1,…,parametern)
Asynchroon
Messages worden aan de receiverside gequeued en 1/1 verwerkt.
Messages worden automatisch geserialiseerd. Objecten worden meegegeven als referentie naar een object binnen de lokale agent. (Dus agent A stuurt een object-message naar agent B, dan zal agent B dat object zien als een ‘remotedict’ naar data object binnen agent A)
Een agent migreren naar een andere machine. Hierbij wordt de volledige execution state gemigreerd naar de nieuwe positie. De agent zelf merkt geen verschil voor en na verplaatsing.
c:remotedict(“tecra”);
agentmove(c)
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 |
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)
Design dergelijk applicatie in Cborg.
Houd rekening met het feit dat er meerdere clients tegelijk kunnen connecteren.
Beschrijf welke agents u in uw systeem zou laten bestaan.
Beschrijf hoe ze samenwerken om uiteindelijk homepages te genereren, beschrijf m.a.w. de functie van elke agent.
Beschrijf een volledige controlflow voor een enkele request.
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
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)
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)
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.
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.
ofwel kopiert u naar een clipboard op een gegeven machine
ofwel geeft u uw buffer een naam eens u kopiert en haalt u hem op bij naam
ofwel paste u vanuit een buffer op een andere machine
ofwel andere…
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 |