diff --git a/doc/include/common.tex b/doc/include/common.tex
index aa93d1f8e763e331ae283b576ef21198afdcbb65..90e28f25ed09a218b5cb54b7d2fdc7dbfdc2e58e 100644
--- a/doc/include/common.tex
+++ b/doc/include/common.tex
@@ -113,4 +113,4 @@
 \newcommand{\tlab}[1]{\label{tab:#1}}
 \newcommand{\flab}[1]{\label{fig:#1}}
 
-\newcommand{\aref}[1]{Assignment~#1 \cite{description#1}}
+\newcommand{\aref}[1]{Lab~#1 \cite{description#1}}
diff --git a/doc/lab0.pdf b/doc/lab0.pdf
index ed71decd41b7d3be70bfa30bf8abe09d413a6fb8..8e045d79f02e5ee6e56425269f9d7d20bba9c425 100644
Binary files a/doc/lab0.pdf and b/doc/lab0.pdf differ
diff --git a/doc/lab0.tex b/doc/lab0.tex
index e868f2923980d2d400a630fb763a94f11bd5e348..1bb13e49f60a2618c4957ec82c71e21aebd3a073 100644
--- a/doc/lab0.tex
+++ b/doc/lab0.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed System: Assignment 0\\Standalone Database}
+\title{Distributed System: Lab 0\\Standalone Database}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
 
@@ -12,24 +12,23 @@
 
 \section{Introduction to the Programming Project} \slab{data-format}
 \input{include/assets/distributed-database.tex}
-Welcome to the course! Over six programming assignments, from zero to five, you
-will learn and put into practice the key components of a distributed system
-\cite{lecture1}. To this end, you will implement your own distributed system,
-namely, a distributed database of short messages known as fortunes
-\cite{fortune}.
+Welcome to the course! Over six labs, from zero to five, you will learn and put
+into practice the key components of a distributed system \cite{lecture1}. To
+this end, you will implement your own distributed system, namely, a distributed
+database of short messages known as fortunes \cite{fortune}.
 
 The final configuration of the system that you will obtain by the end of the
-fifth assignment is depicted in \fref{distributed-database}. This system is
-composed of a number of servers/peers (SP) and a number of clients (C). The
-servers maintain copies of the database (DB) and ensure that these copies are
-kept consistent across all the peers using a distributed locking mechanism (L).
-The clients interact with this peer-to-peer network of servers in order to
-perform various operations on the data. The participants of the network discover
-each other by virtue of a so-called name service (NS); for clarity, these
-communications are not shown.
-
-In each assignment, you will make a step towards the outlined goal by focusing
-on a particular component of the final system:
+fifth lab is depicted in \fref{distributed-database}. This system is composed of
+a number of servers/peers (SP) and a number of clients (C). The servers maintain
+copies of the database (DB) and ensure that these copies are kept consistent
+across all the peers using a distributed locking mechanism (L). The clients
+interact with this peer-to-peer network of servers in order to perform various
+operations on the data. The participants of the network discover each other by
+virtue of a so-called name service (NS); for clarity, these communications are
+not shown.
+
+In each lab, you will make a step towards the outlined goal by focusing on a
+particular component of the final system:
 \begin{enumerate}
 
   \setcounter{enumi}{-1}
@@ -55,37 +54,37 @@ on a particular component of the final system:
 
 \end{enumerate}
 
-For each assignment, you will be given a skeleton of the code that corresponds
-to a particular part of the system, and your task will be to understand what the
-code does and to complete the implementation. The programming language that we
-shall be using throughout the course is \python\ \cite{language}, more
-precisely, the third version of \python\ \cite{python}. Even if you are not
-familiar with \python, the language is straightforward to learn, and the source
-code, provided to you, with a little bit of reading \cite{python-tutorial,
-python-library} will be enough to readily get started and to successfully finish
-this programming project. The above-mentioned skeletons for the assignments and
-the corresponding instructions (just like the one below for the zeroth
-assignment) are provided to you on the web page \cite{course} of the course.
-
-\section{Introduction to the Assignment}
+For each lab, you will be given a skeleton of the code that corresponds to a
+particular part of the system, and your task will be to understand what the code
+does and to complete the implementation. The programming language that we shall
+be using throughout the course is \python\ \cite{language}, more precisely, the
+third version of \python\ \cite{python}. Even if you are not familiar with
+\python, the language is straightforward to learn, and the source code, provided
+to you, with a little bit of reading \cite{python-tutorial, python-library} will
+be enough to readily get started and to successfully finish this programming
+project. The above-mentioned skeletons for the labs and the corresponding
+instructions (just like the one below for the zeroth lab) are provided to you on
+the web page \cite{course} of the course.
+
+\section{Introduction to the Lab}
 \input{include/assets/standalone-agents.tex}
-The goal of the zeroth assignment is to introduce you to \python. Here we
-consider a non-distributed system that consists of a number of standalone
-machines, each of which acts as a server and as a single possible client of this
-server at the same time. The scenario is depicted in \fref{standalone-agents}.
-The machines do not interact with each other and perform all the operations on
-their own copies of the data without any synchronization. In what follows, we
-shall refer to such a standalone machine with the server/client functionality as
-simply \classname{Client}.
+The goal of the zeroth lab is to introduce you to \python. Here we consider a
+non-distributed system that consists of a number of standalone machines, each of
+which acts as a server and as a single possible client of this server at the
+same time. The scenario is depicted in \fref{standalone-agents}. The machines do
+not interact with each other and perform all the operations on their own copies
+of the data without any synchronization. In what follows, we shall refer to such
+a standalone machine with the server/client functionality as simply
+\classname{Client}.
 
 \section{Data Format} \slab{data-format}
-In all the assignments, the list of fortunes, \ie, the actual data in our
-database, will be stored in a text file conventionally called
-\filename{fortune.db}. Such a file will be provided to you along with the source
-code; however, you are free to come up with your own lists of fortunes. The
-format of \filename{fortune.db} is rather straightforward: each message ends
-with a new line containing a single percent sign (\texttt{\%}). For example, the
-following text contains two fortunes:
+In all the labs, the list of fortunes, \ie, the actual data in our database,
+will be stored in a text file conventionally called \filename{fortune.db}. Such
+a file will be provided to you along with the source code; however, you are free
+to come up with your own lists of fortunes. The format of \filename{fortune.db}
+is rather straightforward: each message ends with a new line containing a single
+percent sign (\texttt{\%}). For example, the following text contains two
+fortunes:
 \begin{fortune}
 Everything should be made as simple as possible, but not simpler.
     -- Albert Einstein
@@ -102,9 +101,8 @@ writing your code for the interaction with the database.
 \subsection{Preparation} \slab{preparation}
 Clone the repository of the programming project or download the latest snapshot
 of the repository as a single zip archive \cite{repository}. The files relevant
-to this assignment are listed below; note that the paths are given with respect
-to the \filename{src} directory of the repository. You should read and
-understand them.
+to this lab are listed below; note that the paths are given with respect to the
+\filename{src} directory of the repository. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab0/client.py} --- the main file of the application that each
@@ -166,14 +164,13 @@ you should complete the implementation of the following three function in
 Recall the note at the end of \sref{data-format}.
 
 \section{Conclusion}
-Having completed the assignment, you can now perform the reading and writing
-operations on the database. However, if you run several instances of the
-application on different machines (see \fref{standalone-agents}) or in different
-terminal windows on the same machine and try to add a new fortune in one of
-them, the other clients will not see the change. The reason is that the clients
-do not collaborate with each other and, therefore, do not try to keep their
-copies of the data consistent. In the next assignment, we will mitigate this
-problem.
+Having completed the lab, you can now perform the reading and writing operations
+on the database. However, if you run several instances of the application on
+different machines (see \fref{standalone-agents}) or in different terminal
+windows on the same machine and try to add a new fortune in one of them, the
+other clients will not see the change. The reason is that the clients do not
+collaborate with each other and, therefore, do not try to keep their copies of
+the data consistent. In the next lab, we will mitigate this problem.
 
 \printbibliography
 
diff --git a/doc/lab1.pdf b/doc/lab1.pdf
index 22804aa5495e100fdb5e4a767ec41e36a4ceb618..b9a51a7e4604bdbd49ca4c3c07a706ca7939ff96 100644
Binary files a/doc/lab1.pdf and b/doc/lab1.pdf differ
diff --git a/doc/lab1.tex b/doc/lab1.tex
index cb0f759f3d3ff487c222b61d97aa55c8d9205171..eee0d1cd5bf3df4cedea3abfed9a3c52fae19bdc 100644
--- a/doc/lab1.tex
+++ b/doc/lab1.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed Systems: Assignment 1\\Client-Server Database}
+\title{Distributed Systems: Lab 1\\Client-Server Database}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
 
@@ -12,16 +12,15 @@
 
 \section{Introduction}
 \input{include/assets/single-server.tex}
-In the previous assignment, you built a non-distributed system composed of a
-number of standalone machines, and each such machine was responsible for both
-the server and client components of your fortune database. You observed that the
-private copies of the data maintained by the machines could easily become
-inconsistent as there were no attempts of synchronization. The goal of the
-current assignment is to mitigate this problem by utilizing the client-server
-model \cite{lecture2} of distributed systems. Specifically, we shall designate
-the server role to one separate machine and turn the rest into pure clients.
-This scenario is depicted in \fref{single-server}; compare it with the one from
-\aref{0}.
+In the previous lab, you built a non-distributed system composed of a number of
+standalone machines, and each such machine was responsible for both the server
+and client components of your fortune database. You observed that the private
+copies of the data maintained by the machines could easily become inconsistent
+as there were no attempts of synchronization. The goal of the current lab is to
+mitigate this problem by utilizing the client-server model \cite{lecture2} of
+distributed systems. Specifically, we shall designate the server role to one
+separate machine and turn the rest into pure clients. This scenario is depicted
+in \fref{single-server}; compare it with the one from \aref{0}.
 
 \section{Communication Protocol} \slab{protocol}
 In order for the server and clients to be able to interact with each other, they
@@ -90,8 +89,8 @@ constructor of the class.
 \section{Your Task}
 \subsection{Preparation}
 Continue working with the same code base that you have been working with so far,
-including all the changes that you have made. The files relevant to this
-assignment are listed below. You should read and understand them.
+including all the changes that you have made. The files relevant to this lab are
+listed below. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab1/client.py} --- the \classname{Client} application (\fix);
@@ -118,7 +117,7 @@ attention to the missing parts marked with ``Your code here.'' In order to run
 the code, open two terminal windows and change the current folder to
 \filename{lab1}. In one of the terminals, issue the following command in order
 to run the \classname{Server} application (recall that the server is unique in
-this assignment):
+this lab):
 \begin{shell}
 \$ ./server.py
 Listening to: c-204-13.eduroam.liu.se:45725
@@ -151,14 +150,14 @@ correctness of the address, the system does not work at this stage since neither
 \classname{Server} nor \classname{Client} has the corresponding communication
 part implemented.
 
-In order to ease the testing procedure of this and the future assignments, we
-have implemented a set of shell scripts that open the needed terminals and run
-the corresponding commands for you. These scripts are called \filename{test.sh}
-and can be found in the main folder of each assignment. For instance, the test
-script for the current assignment is \filename{lab1/test.sh}. It is important to
-note, however, that you should be able to set up everything yourself without the
-help of these scripts. So, have a look at the content of the scripts and make
-sure you understand what they do. You can also modify these scripts as you wish.
+In order to ease the testing procedure of this and the future labs, we have
+implemented a set of shell scripts that open the needed terminals and run the
+corresponding commands for you. These scripts are called \filename{test.sh} and
+can be found in the main folder of each lab. For instance, the test script for
+the current lab is \filename{lab1/test.sh}. It is important to note, however,
+that you should be able to set up everything yourself without the help of these
+scripts. So, have a look at the content of the scripts and make sure you
+understand what they do. You can also modify these scripts as you wish.
 
 \subsection{Communication} \slab{communication}
 Using \python's sockets \cite{python-ipc}, complete the implementation of
@@ -196,18 +195,17 @@ Lastly, make sure that, in spite of all possibly occurred exceptions, the server
 keeps on working until it is explicitly stopped by the user.
 
 \section{Conclusion}
-In this assignment, you have implemented a rather na\"{i}ve distributed system:
-there is only one server and each client is required to know the current address
-of the server. The former issue makes our distributed system both unreliable
-(\eg, your carefully written code will not protect the server against a
-blackout) and inefficient (\eg, if there are many clients, the workload of a
-single server machine can be substantially high making clients wait for a
-response for a long time). The second issue makes it inconvenient for the
-clients to connect to the server as the hostname and/or port of the server might
-easily change, and the clients need to keep track of such changes. This
-inconvenience will become especially bothering when you allow your distributed
-system to have several servers; therefore, in the next assignment, you will
-address this problem first.
+In this lab, you have implemented a rather na\"{i}ve distributed system: there
+is only one server and each client is required to know the current address of
+the server. The former issue makes our distributed system both unreliable (\eg,
+your carefully written code will not protect the server against a blackout) and
+inefficient (\eg, if there are many clients, the workload of a single server
+machine can be substantially high making clients wait for a response for a long
+time). The second issue makes it inconvenient for the clients to connect to the
+server as the hostname and/or port of the server might easily change, and the
+clients need to keep track of such changes. This inconvenience will become
+especially bothering when you allow your distributed system to have several
+servers; therefore, in the next lab, you will address this problem first.
 
 \printbibliography
 
diff --git a/doc/lab2.pdf b/doc/lab2.pdf
index f9f69f48f7ae76ed5c36b761f54dea2444c6499a..7e4ff20d1071f59f45732c1ebd715b38eca4339a 100644
Binary files a/doc/lab2.pdf and b/doc/lab2.pdf differ
diff --git a/doc/lab2.tex b/doc/lab2.tex
index fe0e02c3c997db8a7f0aa883859d61555860da8a..ea42f065bac987cfc557eaf022f6b91c0df88b4b 100644
--- a/doc/lab2.tex
+++ b/doc/lab2.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed Systems: Assignment 2\\Middleware: Object Request Brokers}
+\title{Distributed Systems: Lab 2\\Middleware: Object Request Brokers}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
 
@@ -12,25 +12,25 @@
 
 \section{Introduction}
 \input{include/assets/name-service.tex}
-In the previous assignment, you implemented a distributed system with a single
-server and an arbitrary number of clients. The clients were required to
-explicitly specify the hostname and port of the server in order to interact with
-the database. It was not convenient as this information could easily change. The
+In the previous lab, you implemented a distributed system with a single server
+and an arbitrary number of clients. The clients were required to explicitly
+specify the hostname and port of the server in order to interact with the
+database. It was not convenient as this information could easily change. The
 situation becomes significantly more complicated when there are many servers
 joining and leaving the network in an arbitrary way. Such a freedom is at heart
 of a distributed system, and it is exactly what we aim to achieve by the end of
-the programming project. In this assignment, you will implement the code that
-will allow the participants of your distributed system to smoothly discover each
+the programming project. In this lab, you will implement the code that will
+allow the participants of your distributed system to smoothly discover each
 other. At this point, we shift our focus from the client-server to peer-to-peer
 model \cite{lecture3} and refer to participants as peers.
 
 The problem outlined above is solved by introducing into our distributed system
 a so-called middleware \cite{lecture4}; carefully read the corresponding
-sections in \cite{lecture4} to get a better understanding of the assignment.
-Loosely speaking, a middleware of a distributed system is an auxiliary layer
-that hides all the complexity of the communication process between peers. Such a
-layer is typically divided into two parts: object services (\eg, name services)
-and object request brokers.
+sections in \cite{lecture4} to get a better understanding of the lab. Loosely
+speaking, a middleware of a distributed system is an auxiliary layer that hides
+all the complexity of the communication process between peers. Such a layer is
+typically divided into two parts: object services (\eg, name services) and
+object request brokers.
 
 A name service is a global registrar of all the objects/peers that participate
 in the network. Upon request, a name service can, for instance, provide
@@ -51,12 +51,12 @@ A name service is already present in the LiU network for you to use. The source
 code of the name service will not be given; however, the interface of this
 machine will be described (see \sref{interface}) such that you can employ it for
 your purposes by sending adequate messages. Consequently, your first task is to
-learn how to interact with this auxiliary component. To this end, in this
-assignment, you will put aside your previous code and implement a simple
-application with the only purpose of registering in the name service and listing
-the addresses of the peers that are currently present in the network. This
-knowledge will help you to seamlessly incorporate the name service into your
-distributed database of fortunes in the future assignments.
+learn how to interact with this auxiliary component. To this end, in this lab,
+you will put aside your previous code and implement a simple application with
+the only purpose of registering in the name service and listing the addresses of
+the peers that are currently present in the network. This knowledge will help
+you to seamlessly incorporate the name service into your distributed database of
+fortunes in the future labs.
 
 \section{Name Service Interface} \slab{interface}
 The foremost aspect to note is that the name service is following the
@@ -96,8 +96,8 @@ sharing the same object type; otherwise, keep your object type secret.
 \section{Your Task} \slab{task}
 \subsection{Preparation}
 Continue working with the same code base that you have been working with so far,
-including all the changes that you have made. The files relevant to this
-assignment are listed below. You should read and understand them.
+including all the changes that you have made. The files relevant to this lab are
+listed below. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab2/peer.py} --- the \classname{Peer} application (\leave);
@@ -118,8 +118,8 @@ assignment are listed below. You should read and understand them.
 
 \end{itemize}
 Go through the code and grasp the main idea behind each part. You can also try
-to run the main executable file of the assignment, that is, \filename{peer.py},
-and you will observe that the application cannot even start without your help.
+to run the main executable file of the lab, that is, \filename{peer.py}, and you
+will observe that the application cannot even start without your help.
 
 \subsection{Understanding the Setup}
 Let us focus on the module \filename{orb.py} that contains an incomplete
@@ -196,11 +196,11 @@ The requirements are similar to those given in \aref{1}:
 
 \end{itemize}
 As you remember, each remote method invocation should be encoded in JSON and
-sent to the remote side, which is always the name service in this assignment. In
-this regard, pay your attention to the \code{\_rmi} function in
-\classname{Stub}. The name service returns the result of the call as a
-JSON-encoded object containing the output of the method, if it was successful,
-or an error, if the execution failed.
+sent to the remote side, which is always the name service in this lab. In this
+regard, pay your attention to the \code{\_rmi} function in \classname{Stub}. The
+name service returns the result of the call as a JSON-encoded object containing
+the output of the method, if it was successful, or an error, if the execution
+failed.
 
 Have a look at the arguments passed to \code{register} (see \sref{interface}). A
 common problem is that \code{socket.gethostname()} in \filename{peer.py} is
@@ -209,15 +209,15 @@ yields \code{127.0.0.1} or alike and the name service receives rather
 meaningless information about the peer. A workaround is to hardcode your IP
 address in \filename{peer.py}.
 
-After a successful completion of the assignment, each new peer started in a new
+After a successful completion of the lab, each new peer started in a new
 terminal window should output its own address and the addresses of all other
 peers that have already been started and have not been terminated. However,
-those other peers will not (and, in this assignment, are not supposed to) see
-the new one. Remember that you are provided with a test script
+those other peers will not (and, in this lab, are not supposed to) see the new
+one. Remember that you are provided with a test script
 (\filename{lab2/test.sh}), which can set up everything for you.
 
 \section{Conclusion}
-Having completed the assignment, you have made an important step towards your
+Having completed the lab, you have made an important step towards your
 distributed database of fortunes: now you have an object request broker that can
 properly interact with the name service (and, actually, with other peers).
 However, the simple listing of available peers achieved so far is not something
@@ -225,9 +225,9 @@ extremely useful by itself. Moreover, as it was discussed at the end of the
 previous section, each peer is aware only of those participants that joined the
 system before it. In addition, if a peer leaves the network, the other machines
 will not notice this change and, thus, can be misled. Therefore, in the next
-assignment, you will (a) extend the application constructed here to call some
-useful functions of other peers (not only of the name service) and (b) implement
-an auxiliary class that will help to properly maintain the list of active peers.
+lab, you will (a) extend the application constructed here to call some useful
+functions of other peers (not only of the name service) and (b) implement an
+auxiliary class that will help to properly maintain the list of active peers.
 
 \printbibliography
 
diff --git a/doc/lab3.pdf b/doc/lab3.pdf
index 9f79c4635582e4eb09bed05bcf18c8a5ac7751b4..47506004e6539422b66292b45d735e4f322861df 100644
Binary files a/doc/lab3.pdf and b/doc/lab3.pdf differ
diff --git a/doc/lab3.tex b/doc/lab3.tex
index e58f21362e6aee9c65446e96be7718be72ed9e4d..8a0e2dcac6c45c9870d173d941b68523c440c687 100644
--- a/doc/lab3.tex
+++ b/doc/lab3.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed Systems: Assignment 3\\Middleware: Peer-to-Peer
+\title{Distributed Systems: Lab 3\\Middleware: Peer-to-Peer
 Communications}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
@@ -13,14 +13,14 @@ Communications}
 
 \section{Introduction}
 \input{include/assets/chat.tex}
-The goal of the current assignment is to make the code written for \aref{2}
-properly handle situations when peers arbitrary join and leave your distributed
-system. This functionality will be delegated to a separate class called
+The goal of the current lab is to make the code written for \aref{2} properly
+handle situations when peers arbitrary join and leave your distributed system.
+This functionality will be delegated to a separate class called
 \classname{PeerList}, which will take advantage of the object request broker
-implemented as a part of the previous assignment. In addition, you will
-introduce interactions between peers themselves, \ie, peers will be remotely
-invoking methods \cite{lecture3} of each other (as you remember, so far peers
-were communicating only with the name service). In order to put all these pieces
+implemented as a part of the previous lab. In addition, you will introduce
+interactions between peers themselves, \ie, peers will be remotely invoking
+methods \cite{lecture3} of each other (as you remember, so far peers were
+communicating only with the name service). In order to put all these pieces
 together and ensure that they work properly, you will implement a test
 application for exchanging text messages between peers. Such a system of
 messengers is depicted in \fref{chat}.
@@ -28,8 +28,8 @@ messengers is depicted in \fref{chat}.
 \section{Your Task}
 \subsection{Preparation}
 Continue working with the same code base that you have been working with so far,
-including all the changes that you have made. The files relevant to this
-assignment are listed below. You should read and understand them.
+including all the changes that you have made. The files relevant to this lab are
+listed below. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab3/chatPeer.py} --- the chat application (\leave);
@@ -52,19 +52,19 @@ assignment are listed below. You should read and understand them.
 
 \end{itemize}
 
-The main functionality of this assignment is concentrated in
-\filename{peerList.py}, which contains the \classname{PeerList} class. As the
-name suggests, this class represents a list of peers, and it is utilized as
-follows. Each peer has an instance of \classname{PeerList}, and this instance
-maintains local images, that is, \classname{Stub}s, of all the peers that are
-currently present in the network (restricted to your name space specified by
-your object type\footnote{Object types were discussed in \aref{2}.}). Therefore,
-whenever a peer wants to invoke a method of some other peer, it just needs to
-find the addressee in the peer list and make a call to the corresponding image;
-the rest will be done automatically by the object-request-broker functionality
-that you implemented earlier. Carefully read the code in \filename{peerList.py}
-and understand what it does. In particular, ensure that you understand the
-purpose of the locks utilized throughout the module.
+The main functionality of this lab is concentrated in \filename{peerList.py},
+which contains the \classname{PeerList} class. As the name suggests, this class
+represents a list of peers, and it is utilized as follows. Each peer has an
+instance of \classname{PeerList}, and this instance maintains local images, that
+is, \classname{Stub}s, of all the peers that are currently present in the
+network (restricted to your name space specified by your object
+type\footnote{Object types were discussed in \aref{2}.}). Therefore, whenever a
+peer wants to invoke a method of some other peer, it just needs to find the
+addressee in the peer list and make a call to the corresponding image; the rest
+will be done automatically by the object-request-broker functionality that you
+implemented earlier. Carefully read the code in \filename{peerList.py} and
+understand what it does. In particular, ensure that you understand the purpose
+of the locks utilized throughout the module.
 
 Run \filename{chatPeer.py} in several terminal windows. If you have overwritten
 \filename{orb.py} with your correct implementation from \aref{2}, the
@@ -121,8 +121,8 @@ At this point, you have a rather solid ground for your future distributed
 database of fortunes. Now you can perform remote method invocations in a
 straightforward manner, thanks to your object request broker and peer list.
 However, we shall postpone the integration of this code with the
-database-related code from \aref{1} until the final assignment. The reason is
-that there is one crucial component which is still missing. This component is a
+database-related code from \aref{1} until the final lab. The reason is that
+there is one crucial component which is still missing. This component is a
 distributed lock \cite{lecture67}, which you will closely look at in \aref{4}.
 
 \printbibliography
diff --git a/doc/lab4.pdf b/doc/lab4.pdf
index d8f5064875d5a718131a7e01a2e3d3fadaf18605..b8c9fdb89c6a975227a4edae40e7c4149288c566 100644
Binary files a/doc/lab4.pdf and b/doc/lab4.pdf differ
diff --git a/doc/lab4.tex b/doc/lab4.tex
index eac21e30c605b5277ce21b1c0da346e9cfa81e49..2bdaa93596d767914be1b7319a68e2a73bc085c8 100644
--- a/doc/lab4.tex
+++ b/doc/lab4.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed Systems: Assignment 4\\Middleware: Distributed Locks}
+\title{Distributed Systems: Lab 4\\Middleware: Distributed Locks}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
 
@@ -24,7 +24,7 @@ several peers might try to access shared resources simultaneously. Thus, such
 resources have to be protected in order to eliminate corrupted states of the
 data.
 
-The goal for this assignment is to implement an algorithm for distributed mutual
+The goal for this lab is to implement an algorithm for distributed mutual
 exclusion, which will address the aforementioned concern. This locking-enhanced
 configuration of the system is depicted in \fref{lock}. More specifically, we
 shall focus on the second Ricart--Agrawala algorithm \cite{lecture67} (the one
@@ -43,8 +43,8 @@ algorithm.
 \section{Your Task}
 \subsection{Preparation}
 Continue working with the same code base that you have been working with so far,
-including all the changes that you have made. The files relevant to this
-assignment are listed below. You should read and understand them.
+including all the changes that you have made. The files relevant to this lab are
+listed below. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab4/mutexPeer.py} --- the main application (\leave);
@@ -69,16 +69,16 @@ assignment are listed below. You should read and understand them.
   lock (\fix).
 
 \end{itemize}
-As usual, you should reuse your implementations from the previous assignments
-and overwrite the corresponding files listed above.
+As usual, you should reuse your implementations from the previous labs and
+overwrite the corresponding files listed above.
 
 Carefully go through the code in \filename{mutexPeer.py} and
 \filename{distributedLock.py}. The former is the main executable file of this
-assignment. It is a simple test application serving the only purpose of
-acquiring and releasing the distributed lock in \filename{distributedLock.py} by
-choosing the corresponding commands from the menu of the application (see
-below). Run several instances of \filename{mutexPeer.py} in parallel and try to
-acquire the lock in all of them simultaneously:
+lab. It is a simple test application serving the only purpose of acquiring and
+releasing the distributed lock in \filename{distributedLock.py} by choosing the
+corresponding commands from the menu of the application (see below). Run several
+instances of \filename{mutexPeer.py} in parallel and try to acquire the lock in
+all of them simultaneously:
 \begin{shell}
 \$ ./mutexPeer.py -t ivan
 Choose one of the following commands:
@@ -142,10 +142,10 @@ the token never disappears (\eg, due to a system crash) without passing the
 token to someone else.
 
 \section{Conclusion}
-In this assignment, you have implemented one of the algorithms for distributed
-mutual exclusion. As motivated in the introduction, such an algorithm is a
-crucial component of a distributed system as it makes it possible to maintain
-shared resources in consistent states. The final step is to integrate all the
+In this lab, you have implemented one of the algorithms for distributed mutual
+exclusion. As motivated in the introduction, such an algorithm is a crucial
+component of a distributed system as it makes it possible to maintain shared
+resources in consistent states. The final step is to integrate all the
 components that you have implemented so far into a robust distributed database,
 in which an arbitrary number of peers will be maintaining the content of the
 database, and an arbitrary number of clients/users will be able to seamlessly
diff --git a/doc/lab5.pdf b/doc/lab5.pdf
index 02dd5ac27670ccae7dbc8aacafa7d3727bbc3905..dfbcf917c71c6adbe73602ebe1ba98c9f0b38735 100644
Binary files a/doc/lab5.pdf and b/doc/lab5.pdf differ
diff --git a/doc/lab5.tex b/doc/lab5.tex
index 04bee46af77d7c447f20687d043498fee7cc77ac..7f57906fe32cb0704ce90421207ad91fdd2449b3 100644
--- a/doc/lab5.tex
+++ b/doc/lab5.tex
@@ -3,7 +3,7 @@
 
 \bibliography{include/references.bib}
 
-\title{Distributed Systems: Assignment 5\\Client-Server Database with Replicas}
+\title{Distributed Systems: Lab 5\\Client-Server Database with Replicas}
 \author{\input{include/authors.tex}}
 \date{December 20, 2015}
 
@@ -12,9 +12,9 @@
 
 \section{Introduction}
 \input{include/assets/distributed-database.tex}
-Let us summarize what has been achieved so far. In the first two assignments,
-counting from zero, you implemented the basic functionality of a database
-following the client-server model. Specifically,
+Let us summarize what has been achieved so far. In the first two labs, counting
+from zero, you implemented the basic functionality of a database following the
+client-server model. Specifically,
 \begin{itemize}
 
   \item the user can perform the read and write operations on the data, that is,
@@ -25,8 +25,8 @@ following the client-server model. Specifically,
   two possible commands (\aref{1}).
 
 \end{itemize}
-In the last three assignments, from two to four, you built the core components
-of a distributed system. These components are as follows:
+In the last three labs, from two to four, you built the core components of a
+distributed system. These components are as follows:
 \begin{itemize}
 
   \item an object request broker, which, together with the name service,
@@ -39,9 +39,9 @@ of a distributed system. These components are as follows:
   corrupted states due to concurrent operations (\aref{4}).
 
 \end{itemize}
-The goal of this assignment is to improve the na\"{i}ve database obtained at the
-end of \aref{1} by fusing it with the three components of a distributed system
-listed above. The target configuration of the system is displayed in
+The goal of this lab is to improve the na\"{i}ve database obtained at the end of
+\aref{1} by fusing it with the three components of a distributed system listed
+above. The target configuration of the system is displayed in
 \fref{distributed-database}, in which each peer\footnote{The words \emph{peer}
 and \emph{server} are used interchangeably in our context. Similarly, the words
 \emph{user} and \emph{client} have the same meaning here.} maintains a copy of
@@ -54,17 +54,17 @@ guaranteed to see the same data regardless of the peer chosen for reading.
 
 In the scenario described above, the peers duplicating the data are typically
 referred to as replica managers. This concept is of high importance for the
-current assignment, and, therefore, it might be a good idea to get yourself
-familiar with it before diving deeper into the assignment. All the needed
-information on the subject can be found in the corresponding lecture notes
-\cite{lecture8}. In particular, make sure you understand the read-any/write-all
-protocol, which our replica managers will be assumed to follow.
+current lab, and, therefore, it might be a good idea to get yourself familiar
+with it before diving deeper into the lab. All the needed information on the
+subject can be found in the corresponding lecture notes \cite{lecture8}. In
+particular, make sure you understand the read-any/write-all protocol, which our
+replica managers will be assumed to follow.
 
 \section{Your Task}
 \subsection{Preparation} \slab{preparation}
 Continue working with the same code base that you have been working with so far,
-including all the changes that you have made. The files relevant to this
-assignment are listed below. You should read and understand them.
+including all the changes that you have made. The files relevant to this lab are
+listed below. You should read and understand them.
 \begin{itemize}
 
   \item \filename{lab5/client.py} --- the client application representing a user
@@ -133,8 +133,8 @@ copy of the data and collaborates with other servers in order to keep this copy
 up-to-date. An instance of \filename{client.py} is a client/user of the
 distributed database that connects to one of the peers and can issue the
 read/write operations via the corresponding text menu (similar to the first two
-assignments). A client chooses a server to connect to by virtue of the name
-service, which you can easily tell by looking at the corresponding code. More
+labs). A client chooses a server to connect to by virtue of the name service,
+which you can easily tell by looking at the corresponding code. More
 specifically, in \filename{client.py}, you can discover two new functions that
 the interface of the name service has:
 \begin{itemize}
@@ -165,10 +165,10 @@ properly resolved, and your \classname{DistributedLock} is in high demand in
 this context.
 
 \subsection{Implementation} \slab{implementation}
-As you can see in the source code of this assignment, the system has already
-been assembled for you. Assuming that you have properly transfered your
-(hopefully correct) implementations from the previous assignment to the current
-one (see \sref{preparation}), there is only one problem to solve.
+As you can see in the source code of this lab, the system has already been
+assembled for you. Assuming that you have properly transfered your (hopefully
+correct) implementations from the previous lab to the current one (see
+\sref{preparation}), there is only one problem to solve.
 
 Neither \classname{ReadWriteLock} nor \classname{DistributedLock} is sufficient
 by itself. The former is not aware of the distributed nature of the system, and
@@ -185,12 +185,12 @@ have to write two functions with rather suggestive names: \texttt{read} and
 \texttt{write}.
 
 \section{Conclusion}
-Congratulations! You have successfully completed the final programming
-assignment of the course. In this assignment, you have put together many of the
-ideas that you learned previously and have created a robust distributed
-database, which is able to serve many clients in parallel balancing the workload
-among several servers spread out across the network. We hope that you enjoyed
-this programming project. Good luck!
+Congratulations! You have successfully completed the final lab of the course. In
+this lab, you have put together many of the ideas that you learned previously
+and have created a robust distributed database, which is able to serve many
+clients in parallel balancing the workload among several servers spread out
+across the network. We hope that you enjoyed this programming project. Good
+luck!
 
 \printbibliography