Nyhetsflöde
Logga in till din kurswebb
Du är inte inloggad på KTH så innehållet är inte anpassat efter dina val.
Har du frågor om kursen?
Om du är registrerad på en aktuell kursomgång, se kursrummet i Canvas. Du hittar rätt kursrum under "Kurser" i personliga menyn.
Är du inte registrerad, se Kurs-PM för ID2201 eller kontakta din studentexpedition, studievägledare, eller utbilningskansli.
I Nyhetsflödet hittar du uppdateringar på sidor, schema och inlägg från lärare (när de även behöver nå tidigare registrerade studenter).
Johan Montelius redigerade 25 augusti 2012
There will be six seminar topics that will guide you through some interesting aspects of distributed systems.
For each topic you will have two sessions. The first session is not mandatory but you will be able to get some help in solving the problem. The best thing is if you are already well prepared and spend the time at the session solving the tricky issues and maybe run some experiments.
On the second seminar you should have a working system up and running so that you can either connect to others in a larger distrubuted system, extend the system, run some benchmarks and discuss the problems encountered. The second seminar sessions are mandatory and you should be prepared to explain your results. Note - the first topic is not mandatory and there is nothing that you need to hand in.
The report At the seminar you should hand in a 2-3 page report that describes your results. You should use the LaTex template provided and hand in a printed copy at the start of the seminar. If you fail to prepare properly you have falled the seminar and will have to redo the course next year.¶ Use the following LaTex template:¶
* Seminar template
SIgn up Sign up to one of the sessions for the Thursday seminars: morning, before lunch and afternoon. You sign up using Daisy.
Schedule
* Hello Erlang: an introduction to Erlang
* Tuesday x'th of September
* Thursday x'st of September - not mandatory
* Rudy: a small web server
* Tuesday x'th of September
* Thursday x'th of September - mandatory
* Routy: a routing network
* Tuesday x of September
* Thursday x of September - mandatory
* Loggy: a logical time logger
* Tuesday x of September
* Thursday x of September - mandatory
* Groupy: a group membership service
* Tuesday x of September
* Thursday x of September - mandatory
* Chordy: a distributed hash table
* Tuesday x of October
* Friday x of October - mandatory
is there somewhere where we can register for seminars ? link ?
If you have been registered on the course then you should be able to see the course using Daisy (http://daisy.it.kth.se). Find ID2201 and then select one of the seminar groups. In your case you need to talk to the student coordinator for the IT-program and figure aout why you are not registered for the semester nor have the course selected.
looks like i cannot rech my coordinator before friday..
can i attend tommorow's seminar ?
Yes, but tomorrow is only "Hello Erlang" and it's not mandatory.
It seems that all of the dates for the seminars and "räknestuga" is off by one day. For example 17/9 is a Wednesday, not a Tuesday. So in the schedule they are indeed on Tuesdays and Thursdays but according to the dates given here they are on Wednesdays and Fridays. Which days are the correct ones?
Those were last years dates :-) Should be updated now.
It was fine to do the seminar assignments in pairs, but was it also ok to write and hand in the same report? I forgot.
Oh and also, are we supposed to actually implement the improvements suggested under "Going further" before the seminar, or is that optional?
That is optional... but quite fun.
Ahh, you work in pairs or small groups, help each other etc but you write your own report. I wan to see your thoughts on what was hard and how things were solved.
Johan Montelius redigerade 22 september 2014
There will be six seminar topics that will guide you through some interesting aspects of distributed systems.
For each topic you will have two sessions. The first session is not mandatory but you will be able to get some help in solving the problem. The best thing is if you are already well prepared and spend the time at the session solving the tricky issues and maybe run some experiments.
On the second seminar you should have a working system up and running so that you can either connect to others in a larger distrubuted system, extend the system, run some benchmarks and discuss the problems encountered. The second seminar sessions are mandatory and you should be prepared to explain your results. Note - the first topic is not mandatory and there is nothing that you need to hand in.
The report At the seminar you should hand in a 2-3 page report that describes your results. You should use the LaTex template provided and hand in a printed copy at the start of the seminar. If you fail to prepare properly you have falled the seminar and will have to redo the course next year. Use the following LaTex template:
* Seminar template
Sign up Sign up to one of the sessions for the Thursday seminars: morning, before lunch and afternoon. You sign up using Daisy.
Schedule
* Hello Erlang: an introduction to Erlang
* Not mandatory, help is available during the first two weeks.
* Rudy: a small web server
* Monday/Tuesday 15-16'th of September
* Thursday 18'th of September - mandatory
* Routy: a routing network
* Monday/Tuesday 22-23'th of September
* WedneThursday 245'th of September - mandatory
* Loggy: a logical time logger
* Tuesday 30'th of September
* Thursday 2'nd of October - mandatory
* Groupy: a group membership service
* Tuesday 7'th of October
* WedneThursday 89'th of October - mandatory
* Chordy: a distributed hash table
* Monday 13'th of October
* Tuehursday 146'th of October - mandatory
Now it should be synchronized with the actual schedule. Sorry for the disinformation.
Will there be any make up/extra seminar session to present in case you miss the last Seminar?
Yes, there will be at least one extra reporting session after the last seminar. I'll appoint an extra session(s) later next week.
Johan Montelius redigerade 20 september 2012
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
* groupy.pdf
In the code at the end of section 2.1:
- Slave is in the function signature. It should be Slaves.
- In the {mcast, Msg} clause: Unbound variable Peers is used.
- in {join, Wrk, Peer} clause: _ is included in a message, which isn't allowed (erlang R15B01).
- in {join, Wrk, Peer} clause: bcast/2 is called, but nothing indicates that the function should exist.
- the whole function isn't indented correctly, but that is the least of its problems.
In the init function at the end of section 2.3:
I believe Grp ! {join, Self} should be changed to Grp ! {join, Master, Self}.
After fixing this and the other stuff i mentioned + running it in windows instead of arch linux, it seems to be working!
Cool stuff :-)
Found the same problems. Working on it...
Hi, thanks for the commenst and sorry for the errros in the desciption but I'm sure that you will be abel to work your way around it. The tcl/tk gui is as you've seen depricated but I think it will still work? I'll port this to wx ... anyday soon. Will update the .pdf with your fixes.
Johan Montelius redigerade 24 september 2012
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
* groupy.pdf
Ok, I've updated the description of teh assignment and think it is now consistent (have I compiled it,... no, ok, think it is). Thanks for the corrections.
Johan Montelius redigerade 25 september 2012
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
* groupy.pdf (third try)
Ok, third try :-) As you saw the code in the appendix did not quite correspond to the code in the text. I should not say that it does now but it might be closer.
Johan Montelius redigerade 25 september 2012
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
* groupy.pdf (third tryfourth)
And now the indentation is ok :-)
For me there was a problem with the gui module. The graphical window was not updated, I solved it by adding hide and show to the color function.
color(Window, Color) ->
wxWindow:setBackgroundColour(Window, Color),
wxWindow:hide(Window),
wxWindow:show(Window).
The best way is maybe to use the refresh function, thus you avoid closing and opening the windows each time the color changes (On Windows 7 at least).
color(Frame, Color) ->
wxFrame:setBackgroundColour(Frame, Color),
wxFrame:refresh(Frame).
Hello!
If you have any trouble with the GUI not updating its color, it could be that you have to add another line to refresh the Window yourself.
You can do this by refresh. For example:
color(Window, Color) ->
wxWindow:setBackgroundColour(Window, Color),
wxWindow:refresh(Window).
Johan Montelius redigerade 28 september 2015
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
This version uses the wxWidgets library.
* Groupy: a group membership service
Johan Montelius redigerade 28 september 2015
In this assignment you will implement a group membership service. If everything works ok, you will not only see colours but the same colours.
This is an assignment were you will implement a group membership service that provides atomic multicast. The aim is to have several application layer processes with a coordinated state i.e. they should all perform the same sequence of state changes. A node that wish to perform a state change must first multicast the change to the group so that all nodes can execute it. Since the multicast layer provides total order, all nodes will be synchronized. The problem in this assignment is that all nodes need to be synchronized even though nodes may come and go (crash). As you will see it is not as trivial as one might first think.
Complete the assignment up to, and including, section 3. Write up your observations in a short report and be prepared to connect the nodes in a class room wide group. On the seminars we will discuss the questions under section 4.
This version uses the wxWidgets library.
* Groupy: a group membership service
* worker.erl
* gui.erl
* test.erl
Question, the sequence numbers in the last part of the lab.. are they supposed to be the same for views and messages or separate sequence numbers for each of these? It's hard to understand from the assignment what is intended... :)
Why do we have sequence numbers? Do views have their own order or is it one order for all kind of messages?
To keep consistency and order, I'd say it's all one order but then we must resend views as views and messages as messages and so we need to keep track of whether the last saved message was a view or a message and the docs doesn't mention this at all which I think is misleading since they tend to be VERY explicit about most other things... therefore I hesitated and I'm now looking for a clarification :)
Any detail unclear is deliberately there to make you think about what your doing (and sometimes by random :-)
Let's say your a slave and you have one thing in you pocket, the last thing you got from your master. Now the master dies, what should you do with the thing in your pocket? Does it matter if it's a regular message, a view or a coconut?
It does if we're not saving the entire tuple as the last message ;) a good ol' "gedanken wööörp" as we say in Swedish :D
I think slides are missing from this pdf, after slide 27, after 33, after 37 and after 39.
Yes, Sorry for that. Thanks for your comment.
Now I have uploaded a new revised version of the slides.
Johan Montelius redigerade 15 oktober 2015
A summary and time left over for things that we did not have time to cover.... and then of course we must decide the price of olive oil.
* paxos.pdf
Johan Montelius redigerade 24 september 2012
In this assignment you will implement a distributed hash table following the Chord scheme. In order to understand what you're about to do you should have a basic understanding of Chord and preferably have read the original paper.
Implement the distributed hash table up to the point where you have added the store and done some smaller experiments (section 1 and 2). Write up your results and experience in a report and hand it in at the seminar.
At the seminar we will build a larger ring and perform some measurements. We will also discuss how to proceed with handling of failures.
* chordy.pdf
Regarding the first version of chordy (section 1):
at the end on page 4, in the stabilize clause, i think it should say:
node(Id, Predecessor, Successor);
instead of
node(Id, Predecessor, Successor, Store);
Johan Montelius redigerade 28 september 2012
In this assignment you will implement a distributed hash table following the Chord scheme. In order to understand what you're about to do you should have a basic understanding of Chord and preferably have read the original paper.
Implement the distributed hash table up to the point where you have added the store and done some smaller experiments (section 1 and 2). Write up your results and experience in a report and hand it in at the seminar.
At the seminar we will build a larger ring and perform some measurements. We will also discuss how to proceed with handling of failures.
* chordy.pdf
You're so right, fixed.
Johan Montelius redigerade 1 oktober 2012
In this assignment you will implement a distributed hash table following the Chord scheme. In order to understand what you're about to do you should have a basic understanding of Chord and preferably have read the original paper.
Implement the distributed hash table up to the point where you have added the store and done some smaller experiments (section 1 and 2). Write up your results and experience in a report and hand it in at the seminar.
At the seminar we will build a larger ring and perform some measurements. We will also discuss how to proceed with handling of failures.
* chordy.pdf
* Chord: A Scalable Peertopeer Lookup Service for Internet Applications
Johan Montelius redigerade 28 september 2015
In this assignment you will implement a distributed hash table following the Chord scheme. In order to understand what you're about to do you should have a basic understanding of Chord and preferably have read the original paper.
Implement the distributed hash table up to the point where you have added the store and done some smaller experiments (section 1 and 2). Write up your results and experience in a report and hand it in at the seminar.
At the seminar we will build a larger ring and perform some measurements. We will also discuss how to proceed with handling of failures.
* Chordy - a distributed hash table
* Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
Some code that might come in handy when testing the system.
* test.erl
Johan Montelius redigerade 7 september 2012
Keeping track of order of events.
In this exercise you will learn how to use logical time in a practical example. The task is to implement a logging procedure that receives log events from a set of workers. The events are tagged with the Lamport time stamp of the worker and the events must be ordered before written to stdout. It is slightly more tricky than one might first think.
* loggy.pdf
Question about 4 Lamport Time: Here we're suposed to look for messages that arrives in the wrong order. But from my understanding there's nothing new we can use here to determine whether a message arrived in the wrong order. Am I correct or did I miss something?
I mean, in the first test I determined that a message was logged in the wrong order if there was a message m such that m was received before it was sent.
The only new thing I can really test by introducing timestamps is to see if messages from a process p is not incremented...
For instance:
{p, 1, message}
{p, 3, message}
{p, 2, message} //wrong order
But this can never happen since the worker and logger runs on the same machine... What am I missing?
I would say you are not missing anything. Since you are still printing the messages just the way they arrive to the logger, now you can see that sometimes the logical order is incorrect (you might get a message with a higher logical timestamp before one lower (for example a received before a sent). This is what you will try to solve in the next section.
You can also get messages from the same process in a wrong order if the jitter is big enough. Just imagine process 1 sending a message with timestamp 1 and with a delay of 2s. 500 ms after sending the first one it sends another message with timestamp 2 with a delay of 500 ms. The message from process 1 with timestamp 2 will be received before the message with timestamp 1 from the same process.
About the last answer, the second part, in a real environment or if the delay was simulated in a more realistic way that could happen. In our case, since we simulate the jitter by just putting the process to sleep, it is impossible to get a wrong order from the same process as you pointed out, because it won't send the next message until it wakes up. Sorry for the confusion.
Johan Montelius redigerade 28 september 2015
Keeping track of order of events.
In this exercise you will learn how to use logical time in a practical example. The task is to implement a logging procedure that receives log events from a set of workers. The events are tagged with the Lamport time stamp of the worker and the events must be ordered before written to stdout. It is slightly more tricky than one might first think.
* Loggy: a logical time logger
Johan Montelius redigerade 28 september 2015
Send messages from Tokyo to Brasil.In this exercise we will implement a network of routers. Before the seminar you will have to complete the functions that handle the routing table, set of interfaces and maps. You should also have a implemented a router process. During the seminar we should connect the routers together.
* Routy: a small routing proticol
Johan Montelius redigerade 25 augusti 2012
Write your own web server and access it using a regular web browser.
In this assignment you will build a small web server; sounds more complicate than it is. Before the seminar you should have started with Erlang and have completed a small web server. You should have done some performance measurements and written a small report describing your experiments and findings.
* Rudy - a small web server
During the seminar we will discuss your findings and discuss pros and cons on how to improve the server.
I kodexemplet för modulen 'test', funktionen request/2 - saknas det inte ett gen_tcp:close? För mig resulterar körningen i ett emfile (too many file descriptors opened).
Johan Montelius redigerade 28 september 2015
Write your own web server and access it using a regular web browser.
In this assignment you will build a small web server; sounds more complicate than it is. Before the seminar you should have started with Erlang and have completed a small web server. You should have done some performance measurements and written a small report describing your experiments and findings.
* Rudy - a small web server
* RFC 2616
You should complete the rudimentary server described above and do someexperiments. Set up the server on one machine and access it from another machine. A small benchmark program can generate requests and measure the time it takes to receive the answers. Write up your findings in a small report.
During the seminar we will discuss your findings and discuss pros and cons on how to improve the server.
Hej,
I cannot register a course neither in My Pages nor in Daisy in order to do the seminar registration.
Will we have to wait untill our courses are automatically registered to our accounts?. (If I recall something like that was told to us in the introduction day, for the new students.)