Distributed Systems 

Thilo Kielmann, Ana­Maria Oprescu, Alex Uta 
Vrije Universiteit Amsterdam, University of Amsterdam 
Fall 2015 
 

Solutions to Exercise 3 
 
1. How are the OSI model layers mapped to the adapted (middleware­centric) reference 
model? Discuss in terms of functionality. 
 
A: Physical (bit transmission), Data link (correctness) ­ Hardware; Network (routing), 
Transport (retransmission, connection­oriented (telephone) and connectionless (mailing 
a letter) communication services) ­ Operating System; Session (synchronization 
facilities), Presentation (semantics) ­ Middleware (application­independent protocols); 
Application (application­specific and general­purpose protocols) ­ Application 
(application­specific protocols).  
 
2. Give some examples of general­purpose protocols, which belong to the middleware 
layer. What types of distribution transparency do they provide? 
 
A: remote procedure call ­ provides access transparency; domain name system ­ 
provides location transparency. 
 
3. Give some examples of systems evolving from combining persistent/transient, 
synchronous/asynchronous and discrete/streaming communication. Which combination 
corresponds to RPC? 
 
A: Persistent communication means that a message submitted for transmission is stored 
by the communication middleware until received; with transient communication, a 
message is stored only as long as both the sender and receiver are executing. 
 
Asynchronous communication means the sender continues after submitting a message 
for transmission, while synchronous communication means the sender blocks either until 
a) middleware confirms taking over; b) message has been delivered to destination; or c) 
the recipient replies. 
 
In discrete communication a message forms a complete unit of information, while 
streaming involves multiple, related messages. Persistent communication, blocking until 
a message is delivered to destination is typical for message­queueing systems. 
Transient communication, blocking until receiving a reply is typical for RPC, 
 Client/Server. Transient communication, blocking until message is delivered to 
destination is typical for asynchronous RPC. 
 
4. Can we simply use pointers as parameters in RPC calls without extra care? Why? 
 
A: No, because local call­by­reference would be meaningless on a remote machine. A 
solution to this is replacing the call­by­reference by call­by­value/restore. Follow­up 
question: Why aren’t these semantically identical, but still good enough frequently? A: in 
call­by­reference the changes to the variable are immediately visible (e.g., another 
pointer variable to the same address space would see the updated value), while in 
call­by­value/restore only the final change is visible at the end of the call (e.g., multiple 
such variables would not see the updated value). Another solution is using global 
references (e.g., file handle in a shared file system).  
 
5. In multicast RPC, should the client wait for all responses? Why? 
 
A:  It depends on the purpose of involving multiple servers: if it’s for fault­tolerance, then 
1 reply is sufficient, if it’s for workload distribution, then we need all replies back, merged 
by the stub before being returned into a single answer to the client. 
 
6. Consider implementing an application using RPC on top of streams (TCP) and 
datagrams (UDP) sockets, respectively. What would be your main challenge? 
 
A:  Since UDP is an unreliable transport protocol, the application needs to handle 
resending a request. If the request is idempotent (no side­effects) things are trivial, 
otherwise at a minimum client­issued sequence numbers are needed, state has to be 
maintained by the server for each client and the server needs to reply to each request. 
 
7. What are the differences between ZeroMQ and Berkeley (traditional) sockets? What is 
the side effect of asynchronous connection­oriented communication? What are the main 
communication patterns supported by ZeroMQ? 
 
A: In contrast to one­to­one Berkeley sockets, ZeroMQ sockets may support 
one­to­many and many­to­one communication patterns. Processes may request a 
connection setup and then send a message even if the recipient is not up­and­running. 
Sender actions are queued at the sender side, and are dealt by a separate ZeroMQ 
thread. Main communication patterns are request­reply (similar to client­server), 
publish­subscribe (similar to event­based coordination), and pipeline (push­pull 
behavior). 
 
8. What is the role of the message brokers? Why/when are they needed? ​ A: Their main 
role is to convert incoming messages so that they may be understood by destination 
applications (basic: reformatters, more advanced: application­level gateway, using 
 plugins to convert messages between two applications using different messaging 
protocols). In a system with N applications, we may need up to NxN messaging protocol 
converters. Higher­level abstraction solutions, such as XML messages, still have to 
make sure the semantics of the message are well understood. Moreover, message 
brokers may act as subject­based routers (publish­subscribe).  
 
9. Gossiping protocols can be used for data aggregation. Each node ​ Pi​
 maintains a 
variable ​ vi​
. When two nodes ​ i​ j​
 and ​ vi​
 gossip, they set their variables ​ vj​
 and ​ (vi + vj) /2​
 to ​ . 
Show that, eventually, all nodes will have computed the average of the initial values. 
What happens in the case when ​ v1 = 1​, and ​vi = 0​ i != 1​
 (for ​ ) ? 
 
A: Whenever two nodes gossip, they compute the average of their values. During more 
and more communication rounds, more initial values will be covered by the averaging 
process. Eventually, all nodes end up with the same average value. 
In the case where all nodes start with 0, and one node starts with 1, the final result will 
be 1/N (with N nodes). This value can be used to estimate the overall size of the 
network. 
 
10.  Where do we see gossip protocols at work in real­life computing? Think of an example. 
 
A: Tribler (BitTorrent client) uses a gossip protocol to add keyword search capabilities, 
as well as  to discover relevant content. At every step, it either connects to a known peer 
or exchanges information with a random peers. see: 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.4174&rep=rep1&type=pdf