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.
Johan Montelius redigerade 24 september 2014
Two completely different things that are actually quite similar. It all comes down to storing, finding and updating an item given a key.
In order to communicate we need to find the other party. Instead of keeping an address or communication channel open it is better to refer to object using a name . The name is then resolved each time we need to access the service. How are names constructed and how are they resolved? Is there a difference between names and addresses?
File systems make use of name services to locate items. It then provides the means to update these items. We normally see file systems as very different to name services but the propblems we encounter are very similar.
When distributing services we encounter a problem of consistency. How do we guarantee that all clients actually have the same image of the service. We need to be able to talk about consistency of services and realize that sometimes it might not be feasible nor necessary to provide strong consistency guarantees.
* file.pdf
Johan Montelius redigerade 18 september 2015
Two completely different things that are actually quite similar. It all comes down to storing, finding and updating an item given a key.
In order to communicate we need to find the other party. Instead of keeping an address or communication channel open it is better to refer to object using a name . The name is then resolved each time we need to access the service. How are names constructed and how are they resolved? Is there a difference between names and addresses?
File systems make use of name services to locate items. It then provides the means to update these items. We normally see file systems as very different to name services but the propblems we encounter are very similar.
When distributing services we encounter a problem of consistency. How do we guarantee that all clients actually have the same image of the service. We need to be able to talk about consistency of services and realize that sometimes it might not be feasible nor necessary to provide strong consistency guarantees.
* file.pdf
* name.pdf
Johan Montelius redigerade 18 september 2015
Two completely different things that are actually quite similar. It all comes down to storing, finding and updating an item given a key.
In order to communicate we need to find the other party. Instead of keeping an address or communication channel open it is better to refer to object using a name . The name is then resolved each time we need to access the service. How are names constructed and how are they resolved? Is there a difference between names and addresses?
File systems make use of name services to locate items. It then provides the means to update these items. We normally see file systems as very different to name services but the propblems we encounter are very similar.
When distributing services we encounter a problem of consistency. How do we guarantee that all clients actually have the same image of the service. We need to be able to talk about consistency of services and realize that sometimes it might not be feasible nor necessary to provide strong consistency guarantees.
* file.pdf
* name.pdf
Build your own DNS proxy Here is some undocumented code that will implement a small DNS proxy. You can start your own DNS-proxy on for example port 5300 and then direct your operating system to us this as your dns resolver. Once you start to understand what it looks like you should be able to do some caching etc.¶
The trickiest part is how messages are encoded since this is quite spaghetti like. In order to save few bytes DNS messages are encoded in a not so friendly manner.¶
* dns.erl
* handler.erl
* msg.erl
* relay.erl
* test.erl
Johan Montelius redigerade 17 oktober 2014
Transactions are tricky and it's hard to get it right. From the beginning it is quite straight forward and the simple solution is to only allow one transaction at a time. In the quest for better performance we will allow transaction to run concurrently and this is of course asking for trouble. Several techniques are presented such as locking, optimistic control and timestamps, to allow concurrency while preserving the requirements on Atomicity, Consistency, Isolation and Durability.
* transactions.pdf
* disritbuted transactions.pdf
Johan Montelius redigerade 28 september 2012
This is an introduction to large scale storage systems using distributed hash tables. Why do we use hashing at all and what is the trade-off between fast lookup and management of routing tables. What do we do when nodes die and where do we store the replicas.
* distributed hash tables.pdf
Johan Montelius redigerade 17 oktober 2014
This is an introduction to large scale storage systems using distributed hash tables. Why do we use hashing at all and what is the trade-off between fast lookup and management of routing tables. What do we do when nodes die and where do we store the replicas.
* p2p.pdf
* dht.pdf
Johan Montelius redigerade 28 september 2012
So if we now have our distributed system where we hardly can tell what time it is, how do we coordinate our actions? Simple things as taking a lock to protect critical operations is if not tricky, time consuming. A special case occurs if we loose our leader, can a new leader be elected and what happens in the case of node failures.
Multi-casting is also a coordination problem. It does not look like one at first sight but it turns out that processes have to agree on the order of arriving messages or if a arrived message should be treated at all.
* coordination.pdf
Johan Montelius redigerade 6 oktober 2014
So if we now have our distributed system where we hardly can tell what time it is, how do we coordinate our actions? Simple things as taking a lock to protect critical operations is if not tricky, time consuming.
Multi-casting is also a coordination problem. It does not look like one at first sight but it turns out that processes have to agree on the order of arriving messages or if a arrived message should be treated at all.
* coordination-I.pdf
Johan Montelius redigerade 12 oktober 2012
One way of making a system fault-tollerant is to replicate its state. This could also mean that we could increase performance by accession the replicas concrrently. The problem is of course how to achieve a transparent interface, we should preserve the view of one image (or not?). What are the formal requirements that we must place on the service.
What if we want to have a highly available service or increase performance, could we improve the sytem at the expence of consistency?
replication.pdf¶
Johan Montelius redigerade 6 oktober 2014
One way of making a system fault-tollerant is to replicate its state. This could also mean that we could increase performance by accession the replicas concrrently. The problem is of course how to achieve a transparent interface, we should preserve the view of one image (or not?). What are the formal requirements that we must place on the service.
What if we want to have a highly available service or increase performance, could we improve the sytem at the expence of consistency?
* replication.pdf
Johan Montelius redigerade 28 september 2014
How do we describe the state of a distributed system. What is a state of a global system and how do we know that we have recorded it properly? Can we say anything about properties of an execution by looking at recorded states.
* global.pdf
Johan Montelius redigerade 24 september 2014
What is time and why is it so important?
We will look at some definition of time and what it means that clocks are synchronized and correct. The problem then is of course how to actually make sure that our clocks are synchronized. Once we realize that clocks will not help us we look at logical time and how this can help us order events.
* time.pdf
Johan Montelius redigerade 16 september 2014
Sending and receiving messages in a group can be either the easiest thing in the world or the most complicated; it all depends on what we guarantee.
Indirect communication is central in distributed systems yet very hard to get right. It is often provided in a middlelayer that hides the implementation details. Nevertheless one needs to understand what the problem is and how things are solved in order to use the tools efficiently.
Read chapter 6 in the course book.
* indirect.pdf
Is there a reason for this lecture (and the "Transactions" lecture) to only be visible when logged in? All the other lectures are "visible to the whole world". Almost missed reading the slides because of this.
Johan Montelius redigerade 9 september 2014
A topic that could be it own course. We will look at how the Internet protocols work and what quality of service they provide.
Since all distributed systems do communicate it's important to understand what services we can expect and what limitation s we have. Especially important are IP, TCP, UDP, DNS and NAT.
Having a network protocol does not solve all issues, we have to know how to actually access it from a program? What are the API:s that we can use and what do they provide. How do we code messages into byte streams in a way that the receiver can unpack the stream and recreate the message?
* networks.pdf
Johan Montelius redigerade 25 augusti 2012
This seminar is not compulsory but highly recomended for those of you that need help in learning Erlang. We will do some Erlang programming and explore how messages can be sent across a network. If you do not have any problems programming in Erlang you can safely skip this seminar.
* An Erlang Primer
After this seminar you're expected to know how to work in a Erlang programming environment. You should be able to write, compile and run smaller Erlang programs.
At the six'th floor If you work with the KTH computers on six'th floor you will not be able to run Erlang distributed over the network. You can however run several Erlang shells on the same computer and let them communicate with each other. In order to start Erlang in local distribution mode you start Erlang as follows:
erl -sname foo -setcookie secret
and
erl -sname bar -setcookie secret
Now check which name your erlang node has with the call node(). It will probably say something like foo@pc9826. Now, if you register a process under a name "q" then the you should be able to send a message to this process using
{q, 'foo@pc9826'} ! hello.
Ubuntu and other linux users If you're using Ubuntu you will install Erlang in less than three minutes. Choose your favorite packet manager and search for "erlang". Choose the main erlang paket and if you want to use Emacs as a development environment also choose "erlang-mode". The "erlang-doc" packet is also nice since then you will have the html documentation local on your machine.
If you're running other linux or unix distributions, you will find packets for most platforms if you look around. If not you should be able to compile a system using the source found at www.erlang.org. The erlang system is ported to most platforms so it should not be a problem.
Emacs It's only fun to use Emacs if you learn the twenty most common commands using ctr- and esc-sequences. If you google on "emacs commands" you will find many good listings that wil explain what you need to know.
Warning, once you master Emacs there is no going back!
Windows users Install Erlang from www.erlang.org. As a IDE you can choose Eclipse (there are plugins for Erlang) but I would recomend Emacs and install the Erlang modules that will allow you to run Erlang inside Emacs.
Johan Montelius redigerade 25 augusti 2012
Course Book Distributed Systems - Concepts and Design by George Coulouris, Jean Dollimore, Tim Kindberg fifth edition, Addison-Wesley, ISBN: 0-273-76059-9¶
Recommended reading Distributed Systems - Principles and Paradigms by Andrew S. Tannebaum and Maarten Van Steensecond edition, Pearson Education, ISBN: 0-13-239227-5¶
This book could equally well have been chosen as the course book. It covers more or less the same material.¶
Distributed Computing - Principles, Algorithms, and Systems by Ajay D. Kshemkalyani and Mukesh SinghalCambridge Univeristy Press, ISBN: 978-0-521-87634-6¶
A book that is more theoretical than the course book. The book covers topics that are handled in the advanced course. If you think that the theory is the most important part of distributed systems and know the basics of networks and programing systems this could be the book for you.¶
Programming Erlang - Software for a Concurrent World by Joe Armstrongthe Pragmatic Programmers, ISBN: 987-1-934356-00-5¶
This is the book if you want to go further in Erlang programming. There is of course a lot of material on the web but why not take it from one of the most experienced Erlang programmer.¶
Erlang Programming - A Concurrent Approach to Software Development by Francesco Cesarini, Simon ThompsonJune 2009 O'Reilly, ISBN 10: 0-596-51818-8 | ISBN 13: 9780596518189¶
The lates addition to Erlang books, now by the people who might have the most experience in teaching Erlang: Francesco from Erlang Training and Consulting and Simon from the University of Kent.¶
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.)