Yarmouk Private University (YPU)

Faculty Of Informatics And

Communication Engineering

Distributed Systems (DS)

SWE417

Lecture 1:
Introduction to Distributed Systems

1
Welcome!
❑ What is a distributed system?
❑ What do we want to achieve?
❑ Why do we have distributed systems?
❑ Where are distributed systems found?
❑ challenges in distributed systems
❑ The 8 fallacies of distributed computing

2
What Is a Distributed System?
❑ Collection of autonomous computing elements that appears to its users as a single
coherent system (Users/applications perceive a single system)
❑ Computing elements: hardware devices or software processes

❑ Users cannot determine location of computation/data

❑ Or details about the data replication

3
Distributed System definition
A computing platform built with many Concurrency means executing multiple
tasks at the same time but not necessarily
computers that: simultaneously

➢ Operate concurrently;
➢ Are physically distributed; (have their own
failure modes)
➢ Are linked by a network;
➢ Have independent clocks
➢ Provide Distribution Transparency

4
Coherent system
❑ The collection of nodes as a whole operates the same, no matter where,
when, and how interaction between a user and the system takes place.
❑ Examples:
➢ An end user cannot tell where a computation is taking place
➢ Where data is exactly stored should be irrelevant to an application
➢ If or not data has been replicated is completely hidden
➢ Keyword is distribution transparency

❑ partial failures:
➢ It is inevitable that at any time only a part of the distributed system fails. Hiding
partial failures and their recovery is often very difficult and in general impossible
to hide.

5
Distributed System Layer

Middleware, as a resource manager, it

offers services like:
• Facilities for interapplication
communication
• Security services
• Accounting services
• Masking of and recovery from
failures

Figure 1-1. A distributed system organized as middleware. The middleware layer runs
on all machines, and offers a uniform interface to the system

6
What do we want to achieve?
❑ Support sharing of resources
❑ Distribution transparency
❑ Openness
❑ Scalability

7
Sharing resources
❑ Canonical examples:
➢ Cloud-based shared storage and files
➢ Peer-to-peer assisted multimedia streaming (Peer5)
➢ Shared mail services (think of outsourced mail systems)
➢ Shared Web hosting (think of content distribution networks)

❑ Observation:
“The network is the computer”

8
Distribution transparency

❑ Types:

Transparency Description

Access Hide differences in data representation and how an object is accessed

Location Hide where an object is located

Relocation Hide that an object may be moved to another location while in use

Migration Hide that an object may move to another location

Replication Hide that an object is replicated

Concurrency Hide that an object may be shared by several independent users

Failure Hide the failure and recovery of an object

9
Degree of transparency
Aiming at full distribution transparency may be too much:
➢ There are communication latencies that cannot be hidden
➢ Completely hiding failures of networks and nodes is (theoretically and
practically) impossible
❖ You cannot distinguish a slow computer from a failing one (e.g., when accessing web server)

❖ You can never be sure that a server actually performed an operation before a crash

➢ Full transparency will cost performance, exposing distribution of the system

❖ Keeping replicas exactly up-to-date with the master takes time

❖ Immediately flushing write operations to disk for fault tolerance

10
Degree of transparency
❑ Exposing distribution may be good:
➢ Making use of location-based services (finding your nearby friends)
➢ When dealing with users in different time zones
➢ When it makes it easier for a user to understand what’s going on (when e.g., a
server does not respond for a long time, report it as failing).
❑ Conclusion:
➢ Distribution transparency is a nice goal, but achieving it is a different story, and it
should often not even be aimed at

11
Openness of distributed systems
An open distributed system is essentially a system that offers
components that can easily be used by, or integrated into other systems

❑ Systems should conform to well-defined interfaces: standard rules that describe the syntax and
semantics of what those components have to offer (which services they provide)
❑ Systems should easily interoperate: the extent by which two implementations of systems or
components from different manufacturers can co-exist and work together by merely relying on each
other’s services as specified by a common standards
❑ Systems should support portability of applications: to what extent an application developed for a DS A
can be executed, without modification, on a different DS B that implement the same interfaces as A
❑ Systems should be easily extensible: It should be easy to add new component or replace existing ones
without affecting those components that stay in place

12
Challenges In Distributed Systems

❑ Nodes are independent and can ❑ Node membership: fixed, dynamic

be uncoupled or only loosely ❑ Communication between nodes:
coupled ➢ Structured: Each node has well-defined
❑ No global clock! set of neighbors (tree, ring)
➢ Unstructured: Nodes can communicate
❑ Distributed reads and writes
with any other node
❑ Two Generals Problem ❑ Fault-tolerance: Nodes can fail in
❑ How to order events within a multiple ways
distributed system? ❑ Data consistency means: the same
❑ How to organize a distributed data on any node is the same at any
system? time
❑ Performance

13
Designing Distributed Software Systems
❑ Scalability: Handle massive changes in user requests (10X)

❑ Performance

❑ Reliability and Resiliency: Handle partial failures gracefully

❑ Usability: Abstractions and Interfaces

❑ Jeff Dean: Building Software Systems At Google and Lessons Learned

https://www.youtube.com/watch?v=modXC5IWTJI

14
15
Examples of distributed systems…

❑ Intranets, Internet, WWW, email, …

❑ DNS (Domain Name System)
➢ Hierarchical distributed database
❑ Distributed supercomputers, Grid/Cloud computing
❑ Electronic banking
❑ Airline reservation systems
❑ Peer-to-peer networks
❑ Sensor networks
❑ Mobile and Pervasive (ubiquitous ) Computing

16
The 8 fallacies of distributed computing
It is a common mistake for programmers, when they first build a distributed
application, to make the following 8 assumptions. All prove to be false in the long run
and all cause big trouble and painful learning experiences:
(http://www.rgoarchitects.com/Files/fallacies.pdf)

1. The network is reliable

Peter Deutsch, a SUN
2. Latency is zero
fellow is credited with the
3. Bandwidth is infinite first seven (1994); around
4. The network is secure 1997, James Gosling
5. Topology doesn’t change added the 8th fallacy.
6. There is one administrator Lots of information can
be found through google.
7. Transport cost is zero
8. The network is homogeneous
17
Fallacy 1: The Network is Reliable

❑ Hardware may fail!

➢ Power failures; Switches have a mean time between failures.

(e.g., a router between you and the server you get data from)

❑ The implications:

➢ Hardware: weigh the risks of failure versus the required investment to build
redundancy (yet another trade-off!).
➢ Software: we need reliable messaging: be prepared to retry messages,
acknowledge messages, reorder messages (do not depend on message
order), verify message integrity, and so on.

18
Fallacy 2: Latency is zero
Latency: how much time it takes for data to move from one place to another:
measured in time.
❑ The minimum round-trip time between two points on earth is determined by
the maximum speed of information transmission: the speed of light. At
300,000 km/sec, it will take at least 30msec to send a ping from Europe to the
USA and back.

❑ The implications:
➢ You may think all is OK if you deploy your application on LANs, but you
should strive to make as few sessions over the network as possible (and
transfer as much data out in each of these sessions).
❑ Read: http://blogs.msdn.com/oldnewthing/archive/2006/04/07/570801.aspx
❑ Exercise: 100MB file, latency 1sec or 0.001sec, bandwidth 100MB/sec, at once or not?
19
Fallacy 3: Bandwidth is infinite
❑ Bandwidth: how much data you can transfer over a period of time (may be
measured in bits/second)
❑ It constantly grows, but so does the amount of information we are trying to
squeeze through it! (VoIP, videos, verbose formats such as XML, …)
❑ Bandwidth may be lowered by packet loss (usually small in a LAN): we may want
to use larger packet sizes.
❑ The implications:

➢ Compression; try to simulate the production environment to get an

estimate for your needs.

20
Fallacy 4: The Network is Secure
❑ The Implications:
➢ You may need to build security into your applications from Day 1.
➢ As a result of security considerations, you might not be able to access
networked resources, different user accounts may have different privileges,
and so on…

21
Fallacy 5: Topology doesn’t change
❑ The topology doesn’t change as long as we stay in the lab.

❑ Servers may be added and removed often, clients (laptops, wireless ad hoc
networks) are coming and going: the topology is changing constantly.
❑ The implications:

➢ Do not rely on specific endpoints or routes.

➢ Abstract the physical structure of the network: the most obvious example is
DNS names as opposed to IP addresses.
(refresh your memory about the Internet Domain Name System – DNS)

22
Fallacy 6: There is one administrator
❑ Unless we refer to a small LAN, there will be different administrators associated
with the network with different degrees of expertise.
❑ Might make it difficult to locate problems (is it their problem or ours?)

❑ Coordination of upgrades: will the new version of MySql work as before with
Ruby on Rails?
❑ Don’t underestimate the ‘human’ (‘social’) factor!

23
Fallacy 7: Transport Cost is Zero
❑ Going from the application layer to the transport layer is not free:
➢ Information needs to be serialised (marshalling) to get data onto the wire.
➢ The cost (in terms of money) for setting and running the network is not zero.
Have we leased, for instance, the necessary bandwidth?

24
Fallacy 8: The Network is Homogeneous
❑ (homogeneous = of the same kind; uniform).

❑ Even a home network may connect a Linux PC and a Windows PC. A

homogeneous network today is the exception, not the rule!
❑ Implications:
➢ Interoperability will be needed.

➢ Use standard technologies (not proprietary protocols), such as XML (a W3C

recommended general-purpose markup language – a markup language combines text
and extra information about the text – designed to facilitate the sharing of data across
different information systems. Its drawback? It’s slow…)

25