Internet and Distributed Systems PDF

INTERNET & DISTRIBUTED
SYSTEMS
INTERNET & DISTRIBUTED SYSTEMS
Jocelyn O. Padallan
ARCLER
P r e s s
www.arclerpress.com
Internet & Distributed Systems
Jocelyn O. Padallan
Arcler Press
2010 Winston Park Drive,
2nd Floor
Oakville, ON L6H 5R7
Canada
www.arclerpress.com
Tel: 001-289-291-7705
001-905-616-2116
Fax: 001-289-291-7601
Email: orders@arclereducation.com
e-book Edition 2019
ISBN: 978-1-77361-587-5 (e-book)
This book contains information obtained from highly regarded resources. Reprinted material
sources are indicated and copyright remains with the original owners. Copyright for images and
other graphics remains with the original owners as indicated. A Wide variety of references are
listed. Reasonable efforts have been made to publish reliable data. Authors or Editors or Publish-
ers are not responsible for the accuracy of the information in the published chapters or conse-
quences of their use. The publisher assumes no responsibility for any damage or grievance to the
persons or property arising out of the use of any materials, instructions, methods or thoughts in
the book. The authors or editors and the publisher have attempted to trace the copyright holders
of all material reproduced in this publication and apologize to copyright holders if permission has
not been obtained. If any copyright holder has not been acknowledged, please write to us so we
may rectify.
Notice: Registered trademark of products or corporate names are used only for explanation and
identification without intent of infringement.
© 2019 Arcler Press
ISBN: 978-1-77361-390-1 (Hardcover)
Arcler Press publishes wide variety of books and eBooks. For more information about
Arcler Press and its products, visit our website at www.arclerpress.com
ABOUT THE AUTHOR
Jocelyn O. Padallan is currently pursuing her Master of Science in

Information Technology from Laguna State Polytechnic University,
Philippines and has Master of Arts in Educational Management from the
same University. She has passion for teaching and has been an Instructor at
Laguna State Polytechnic, Los Banos Campus, Philippines.
TABLE OF CONTENTS
List of Figures.................................................................................................xi
List of Tables.................................................................................................xiii
Preface..........................................................................................................xv
Chapter 1 Introduction to Internet............................................................................. 1

1.1 History of The Internet.......................................................................... 2
1.2 Local Area Network............................................................................ 12
1.3 Wide Area Network............................................................................ 13
1.4 Wireless Local Area Network.............................................................. 14
1.5 Metropolitan Area Network................................................................ 15
1.6 Connecting to The Internet.................................................................. 15
1.7 Web Services...................................................................................... 17
References................................................................................................ 24
Chapter 2 Fundamental Concepts of Distributed Systems........................................ 25

2.1 Distributed Systems............................................................................ 26
2.2 Architecture Models............................................................................ 28
2.3 Internet Architecture........................................................................... 32
2.4 Ethernet Design.................................................................................. 36
2.5 Open Systems Interconnections (ISO/OSI Reference Model) .............. 39
2.6 Middleware........................................................................................ 43
2.7 The TCP/IP Reference Model............................................................... 45
2.8 Interprocess Communication.............................................................. 48
References................................................................................................ 51
Chapter 3 Time and Global States............................................................................ 53

3.1 Clocks and Concepts of Time.............................................................. 54
3.2 Timing Problem.................................................................................. 55
3.3 Physical Clocks................................................................................... 55
3.4 Logical Clocks.................................................................................... 61
3.5 Events Ordering Synchronization........................................................ 65
3.6 Global States...................................................................................... 68
3.7 Distributed Debugging........................................................................ 69
References................................................................................................ 73
Chapter 4 Coordination............................................................................................ 75
4.1 Distributed Mutual Exclusion.............................................................. 76
4.2 Multicast Communication................................................................... 85
4.3 Group Communication....................................................................... 86
4.4 Failure................................................................................................ 87
4.5 Elections............................................................................................. 91
References................................................................................................ 94
Chapter 5 Distribution and Operating Systems......................................................... 95

5.1 Introduction to Operating Systems...................................................... 96
5.2 Batch Operating System...................................................................... 99
5.3 Time-Sharing Operating Systems......................................................... 99
5.4 Distributed Operating System........................................................... 100
5.5 Real-Time Operating System............................................................. 101
5.6 Network Operating System............................................................... 102
5.7 Unix Operating System..................................................................... 105
5.8 Windows Operating System.............................................................. 107
5.9 Distributed and Network File System................................................ 108
References.............................................................................................. 114
Chapter 6 Peer To Peer Systems............................................................................. 115

6.1 Introduction to Peer to Peer System................................................... 116
6.2 Routing in P2P.................................................................................. 117
6.3 Classification of P2P......................................................................... 121
6.4 First Generation of P2P..................................................................... 124
6.5 Second Generation P2P.................................................................... 126
6.6 Third Generation P2P........................................................................ 130
6.7 Current Generation P2P.................................................................... 133
References.............................................................................................. 135
viii
Chapter 7 Security and Privacy............................................................................... 137
7.1 Concepts of Security......................................................................... 138
7.2 Kerberos........................................................................................... 144
7.3 SSL Security...................................................................................... 145
7.4 Firewall............................................................................................ 145
7.5 Authorization.................................................................................... 146
7.6 Auditing............................................................................................ 148
7.7 Digital Signatures.............................................................................. 148
7.8 Cryptography.................................................................................... 152
References.............................................................................................. 161
Chapter 8 Mobile and Ubiquitous Computing........................................................ 163

8.1 Communication Technology............................................................. 164
8.2 Traditional System of Distribution..................................................... 164
8.3 Nomadic Distribution System........................................................... 168
8.4 Mobile Adhoc Network.................................................................... 169
8.5 Theory in Mobile Computing............................................................ 171
8.6 Models............................................................................................. 172
8.7 Palmtop and Laptop Technology....................................................... 174
8.8 Mobile Middleware.......................................................................... 175
8.9 Ubiquitous Computing..................................................................... 181
References.............................................................................................. 185
Chapter 9 Distributed Programming Systems and Environment.............................. 187

9.1 Distributed Programming Environment............................................. 188
9.2 Occam 2.......................................................................................... 188
9.3 Ada 95.............................................................................................. 189
9.4 Java................................................................................................... 194
9.5 Corba............................................................................................... 198
References.............................................................................................. 206
Chapter 10 Wireless Sensor Network....................................................................... 207

10.1 Sensing and Sensors........................................................................ 208
10.2 Wireless Sensor Networks............................................................... 213
10.3 Medium Access Control (MAC)....................................................... 217
10.4 Operating Systems.......................................................................... 218
ix
10.5 Middleware.................................................................................... 223
10.6 Challenges and Constraints............................................................. 224
10.7 Applications of Wireless Sensor Networks....................................... 227
References.............................................................................................. 229
Bibliography........................................................................................... 231
Index...................................................................................................... 235
x
LIST OF FIGURES
Figure 1.1: An illustration of the Internet

Figure 1.2: Free Enterprise E-mail Server
Figure 1.3: Mode of Operation of Types of FTP
Figure 1.4: Local Area Network
Figure 1.5: A Modem
Figure 1.6: Overview of Web Services
Figure 1.7: Coding a Website in a Notepad
Figure 1.8: Components of a URL
Figure 2.1: Example of a Distributed System
Figure 2.2: A desktop PC as an Example of a Fat Client
Figure 2.3: Encapsulation of Data in the TCP/IP Protocol Stack
Figure 2.4: IP Protocol Header
Figure 2.5: Ethernet at Data Link Layer
Figure 2.6: How LAN Protocols Map to the OSI Reference Model
Figure 2.7: TCP/IP model
Figure 3.1: Computation of Mean Solar Day by Physical Clock
Figure 3.2: An Illustration of NTP Server Configuration
Figure 3.3: Lamport Clock Assignments
Figure 3.4: Vector Clock Assignments
Figure 4.1: Lamport’s Algorithm
Figure 4.2: Ricart-Agrawala Algorithm
Figure 4.3: A Tree Organization of 15 Copies of an Object
Figure 4.4: The Byzantine Generals Problem
Figure 5.1: Distributed Operating System
Figure 5.2: General structure of a Network Operating System
Figure 5.3: Different layers of the UNIX architecture
Figure 5.4: A DFS operating in a Web Server System
Figure 6.1: A Peer to Peer Relationship
Figure 6.2: An Example of Query Routing from Peer n to m
Figure 6.3: The Napster P2P
Figure 6.4: Gnutella
Figure 6.5: Range of data sharing scenarios supported by Oneswarm
Figure 7.1: Authentication Based on Shared Keys
Figure 7.2: Principle of using a KDC
Figure 7.3: Mutual Authentication using Public Key Encryption
Figure 7.4: Operation of Web Application Firewall
Figure 7.5: Basic RSA Data Security Digital Signature Process
Figure 7.6: Secured Communication via Encryption
Figure 7.7: Symmetric Encryption
Figure 7.8: Asymmetric Encryption
Figure 7.9: The MD-5 Algorithm
Figure 8.1: First Operational Analog 1G Mobile System
Figure 8.2: Waves of Computing
Figure 9.1: The Transputer/Host Development Relationship
Figure 10.1: A Sensor Node
Figure 10.2: A Schematic of a Wheatstone Bridge Circuit
Figure 10.3: A Wireless Sensor Network Model
Figure 10.4: Wireless Sensor Network Topologies
Figure 10.5: TinyOS Architecture
Figure 10.6: Block Diagram of Contiki Architecture
Figure 10.7: Lite OS Architecture
xii
LIST OF TABLES
Table 1.7: Generic Domains

Table 2.5: OSI Protocol Summary
Table 4.1: Variables used in the Algorithm
Table 4.2: Failure Models
Table 7.1: Conventional and Public Key Encryption
Table 8.1: Different Forms of Transparency in a Distributed System
Table 10.1: Classification and Examples of Sensors
Table 10.2: Comparison of Traditional Networks and Wireless Sensor Networks
Table 10.3: Comparative Analysis of Existing Operating Systems
PREFACE
The US Department of Defense established the basis of the Internet by

introducing a network called ARPANET the first packet switching network
for host-to-host communication about 30 years ago. This network was the
Internet’s precursor prior to the release of the open version in 1969. The original
ARPANET eventually developed into what we know as the Internet today. The
Internet represents a fundamental and technical idea which is majorly the open
architecture networking. In this methodology, the preference of any discrete
network technology is not controlled by certain network architecture but
could be chosen without restriction by a provider and made to interconnect
with the other networks through a meta-level “Internetworking architecture.”
In an open-architecture network, the discrete networks may be designed
and developed independently with each having its own distinctive interface
which it may provide for users and providers. The shortcoming of the initial
communication standard was the inability to address other solution apart from
ARPANET; hence, a feasible replacement was needed. At this point, a new
protocol known as Transmission Control Protocol/Internet Protocol (TCP/IP)
was released in 1972. However, the prevalent growth of the Internet started in
the mid-1980s when there was mass production of personal computers (PCs)
and workstations. But the public was not aware of the Internet that much until
after the development of the World Wide Web (WWW) in the early 1990s. The
internet today has become an indispensable tool for most people all over the
world. Today, the Internet is a core functionality of media, politics, business,
administrative systems, banking, defense, and social interaction. Technology
has driven the development of both the private and public sectors over the
years, but the introduction of the Internet has boosted the use of high-end
technology. Phone calls are now getting out of fashion as social media platforms
and applications are now being invented—YouTube, Twitter, Facebook, Flickr,
WhatsApp, Skype are all good examples. The internet is part of distributed
systems. In a realistic context, distributed systems are generally composed
of the Internet, the intranet, and mobile computing. An intranet is a private
network or a subset of an enterprise. An internet is a large interconnected group
of computer networks of various types. The Internet is a single communication
subsystem providing communication between interconnected hosts. The
Internet is assembled from many subnets. A subnet is a unit which connects two
switching elements or router, and it conveys data from one part of the Internet
to another; it is an assemblage of nodes that can get contacted on a similar
physical network. Internet’s infrastructure combines both network architecture
and system components (hardware and software) that efficiently incorporate
various subnets into a single data communication service. A distributed system
can be defined as a system of multiple independent processing elements
working together to achieve a common objective. A distributed service may
utilize the replication of data where a service preserves multiple copies of data
to allow access at various locations locally, or to improve accessibility when a
server process may have crashed. This Book explores the distributed systems
that make up the Internet. Chapter one emphasizes on the Internet, its origin,
and the various types of networks that we have across the globe. Chapter two
to six highlights the concepts of distributed systems, framework for network
systems, processes involved in connection of network and network architecture.
All the important application layer protocols were described with examples
and illustrations. Here, the author also describes how the properties and design
subjects of distributed systems can be captured and adopted using descriptive
models. These chapters extensively discuss the problems of distributed systems
especially the major ones such as concurrency of components, lack of a global
clock, and independent failures of components. Security issues in distributed
systems were briefly explained in chapter seven while the last two chapters
explain Itinerant, Distributed and Ubiquitous technologies and also describe
distributed programming systems such as CORBA, Java, OCCAM, and Ada
and the way each of these works in a networking environment. Presently, there
are only few books based on Internet and distributed systems which prompted
the author not only to conceive the idea of writing about it but to focus on
the complementary aspect of it—distributed systems, because the books that
discuss about internet do not give explicit and salient information on distributed
systems which seems to be the “heart” of Internet itself. As such, the coverage
of essential topics in these books seems insufficient. With the steep rise of the
Internet over the years and its significance in all walks of life, our belief is
that this book is a massive contribution to the teeming population of internet
experts, network professionals, computer scientists, and engineers. The book is
simple to understand, and it has been written to assist experts in the information
and communication technology field and also non-experts. More importantly,
the first chapter is useful for the laymen who want to get additional knowledge
of the evolution of the Internet and how it works. Each chapter begins with an
xvi
introduction and is kept at a judicious length. Relevant images are inserted with
sources for future reference and an intensive effort has been made to make the
whole content comprehensive, self-explanatory, and very much interesting for
the readers.
xvii
CHAPTER 1
INTRODUCTION TO INTERNET
“The Internet came out of our frustration that there were only a limited
number of large, powerful research computers in the country, and that many
research investigators who should have access to them were geographically
separated from them.”
-Leiner et al. 2003
CONTENTS
1.1 History of The Internet............................................................................................... 2
1.2 Local Area Network................................................................................................. 12
1.3 Wide Area Network................................................................................................. 13
1.4 Wireless Local Area Network................................................................................... 14
1.5 Metropolitan Area Network..................................................................................... 15
1.6 Connecting to The Internet....................................................................................... 15
1.7 Web Services........................................................................................................... 17
References..................................................................................................................... 24
2 Internet & Distributed Systems
The public internet is a global computer network, that is, a network that
interconnects other networks throughout the world via devices. Most of
these devices are conventional desktop PCs, Unix-based workstations, and
servers that store and transmit data such as Web (WWW) pages and e-mail
messages. Gradually, non-traditional computing devices such as Web TVs,
mobile computers, pagers, and toasters are being connected to the Internet.
The Internet provides a capability so powerful and universal that it can be
used for almost any purpose that depends on information, and it is accessible
by every individual who connects to one of its constituent networks. This
chapter discusses the internet at large, modern means of communication such
as email, the diverse protocols that drive the internet and also highlights the
ways by which one can get connected to the internet.
1.1 HISTORY OF THE INTERNET

The Internet is a universal system of interconnected computer networks
that was established to reach billions of private, public, academic, and
business networks through an international telecommunications backbone
that consists of various electronic and optical networking technologies. The
basic purpose of the Internet is to ease the exchange of information and
there are diverse tools used to perform this operation. Some of the more
common tools include e-mail, lusters, newsgroups, telnet, gopher, File
Transfer Protocol (FTP), and the WWW. Probably, the most prevalent of all
Internet tools is the WWW. The Internet does not have a central controlling
body; hence, it is owned by nobody because it is a decentralized system. The
internet system was made as such by the Defense Department which adopts
it for the sole purpose of exchanging data to make it less susceptible to
terrorist attacks. It all started way back in the US Department of Defense as
a network provided to aid communication between scientists and university
professors around the world. In 1969, in response to the warning of the
nuclear attack, ARPANET was built to sustain communication if one or
more sites were destroyed. This was the case during the year of ARPANET
when only computer scientists and engineers were the only ones who knew
how to handle its complicated operations. But today, millions of people
across the world have access to the Internet from home, work, or public
place. ARPA champions, the development of a packet-switching network,
are called the ARPANET. In 1974, the Telecommunication Protocol/Internet
Protocol (TCP/IP) protocols and model were proposed by Cerf/Kahn. In
1980, IPv4 was introduced. Three years after, ARPANET adopted TCP/IP.
Introduction to Internet 3
At this time, the ARPANET had 200 routers. In 1984, NSF funded a TCP/
IP-based backbone network. This backbone grows into the NSFNET, which
becomes the successor of the ARPANET. In 1995, NSF stopped funding
of NSFNET. The Internet went completely commercial. Researchers and
academics in other fields began to make use of the network, and ultimately
the National Science Foundation (NSF), which had generated a similar and
parallel network, called NSFNet, took over much of the TCP/IP technology
from ARPANET and established a distributed network of networks capable
of handling far traffic. In 1985, NSF initiated a program to establish
Internet access across the United States. They created a backbone called the
NSFNET and gave access to all educational facilities, academic researchers,
government agencies, and international research organizations. By the
1990s, the Internet experienced explosive evolution. It is expected that the
number of computers connected to the Internet was doubling every year.
Business owners realized that they could make use of the Internet to upgrade
and enhance their services to their customers, so they started spending huge
amounts of money to develop the Internet. This spawned violent competition
among the communications carriers and hardware and software suppliers to
meet this demand. The result is that bandwidth (i.e., the information carrying
capacity of communications lines) on the Internet has increased immensely
and costs have dropped. It is widely believed that the Internet has played a
momentous role in the economic success.
Figure 1.1: An illustration of the Internet. Source: https://www.businessday-

online.com/internet-solutions-wins-best-west-africa-infrastructure-service-
provider/
1.1.1 World Wide Web

The WWW is a collection of Internet sites that can be accessed by using
a hypertext interface. Web documents Hypertext documents on the web
contain links to other documents located anywhere on the web. To access
relevant materials through another site or file, you have to click on the link.
The interesting thing about hypertext links is that the links might refer you to
similar material on another computer located anywhere in the world pretty
much better than just to a file on your local hard drive. The size of the web is
currently estimated to be around 22 billion pages. The web is by far the most
used application in the world: in few decades it has deeply revolutionize
human behavior impacting on the way people study, communicate, make
business, deliver services, have fun.
The WWW extends the well-established concept of hypertext by making
it possible for the destination document to be located on a completely different
computer from the source document, either one located anywhere on the
network. This was made possible by exploiting the existing capabilities of
the Internet, a worldwide network of interconnected computers developed
over the preceding 20 years, to establish a rapid connection to any named
computer on the network. To achieve this, the WWW uses client–server
architecture. A user who wants to access information runs a WWW client
(sometimes referred to as a browser) on his local computer. The client
fetches documents from remote network nodes by connecting to a server on
that node and requesting the document to be retrieved. A document typically
can be requested and fetched in less than a second, even when it is located
on the other end of the requester.
The WWW is an information retrieval system based on hypertext. In
hypertext, highlighted words or areas on the screen are expandable, leading
to more details about subject. A hypertext allows you to gain access to
information without using complex commands and the source of information.
When a hyperlink is attached to text, it is known as hypertext. A browser is
a client application used to access the information on WWW. The browser
displays web pages and makes the connection indispensable to follow
hypertext links. WWW is a global hypertext system that uses the Internet
as its mode of transmission. The WWW enables you to access information
on the Internet without the use of complicated commands. The web brings
volume of information to the user by linking resources throughout the
Internet. The WWW could be very simply defined as a universal database
of knowledge and information that is easily accessible to people around the
world and links easily to other pieces of information. This enables the user
to find vital information swiftly. It is an Internet resource where one can get
information about diverse topics and content.
1.1.2 E-mail
E-mail has become an essential form of communication. Modern e-mail
operates across the Internet, but the use of e-mail actually precedes
ARPANET. Some of the earlier e-mail systems date back to the mid-1960s,
including the Automatic Digital Network by the US. Department of Defense
and the Compatible Time-Sharing System by MIT. As ARPANET grew
significantly, regulations were developed for e-mail communication. The
first ARPANET e-mail was sent in 1971, using the @ symbol to separate
the name of the user from the user’s machine. The most commonly used
e-mail standard, called Simple Mail Transfer Protocol (SMTP) was
developed in 1982. Standardization led to a significant increase in the
popularity of e-mail. In fact, e-mail was the first killer app of ARPANET
and the Internet. A killer application is a computer program that is so useful
and popular that it proves the core value of some larger technology. In this
case, e-mail really established the expediency of the Internet. These early
systems worked on a restricted number of terminals across relatively small
networks. The systems were also not compatible with each other. E-mail
allows the subscriber to stay in touch with people. It actually takes just less
than a minute to send an e-mail. You may get your e-mail account through
the same people who provide your internet service, or you may sign up to
one of the committed e-mail providers, such as Gmail, Outlook, or Yahoo!
One difference between using e-mail software and using webmail is that
you usually have to login to a webmail account each time you use it. You
will need your e-mail address and a password to do this. Webmail is free
but is paid for by advertising, so you may also have to get used to small
adverts on screen when you use it. E-mail lets you type and send a message
to anyone at any location in the world provided that the receiver has an
Internet connection and an e-mail account. The message is delivered within
seconds once it is sent. The way e-mail works on the Internet is similar to
the way the postal system works although the e-mail is faster. The address
is the core part of both standard letters and e-mail messages. If the address
is incorrect, the supposed receiver will never see the message. Clicking the
send button on your computer is similar to placing your letter in a mailbox.
Once you have sent your message on its way, you cannot withdraw it. The
postal service collects mail and takes it to the local post office for processing
and routing. When you send e-mail, your local post office reads the e-mail
address and either conveys the message to another local mail account or
sends it to the Internet. As your letter travels from one post office to another,
the postal service routes it based on the address, so that there is proximity to
its destination. Your e-mail message passes through a number of computers,
known as routers, on its way to the recipient. A router is a device that acts
as a gateway between networks. It basically routes data by matching the
destination address in the data to network topology information and routing
tables. Often, a router connects a local area network (LAN) to the Internet.
Postal mail goes from the local post office to the recipient’s mailbox. The
e-mail recipient’s local post office system receives the message. Both postal
letters and e-mail messages remain in the mailbox until the recipient checks
for new mail. A major difference between electronic and postal mail is that
e-mail is significantly faster.
1.1.3 E-Mail Server

A mail server is the electronic equivalent of your friendly community
postman. Every e-mail that is sent passes through series of mail servers
along its way to its proposed receiver. Although it may look as if message is
sent immediately—zipping from one computer to another in the blink of an
eye—the reality is that an intricate series of transfers takes place. Without
this series of mail servers, you would only be able to send e-mails to people
whose e-mail address domains corresponds to your own—for instance,
you could only send messages from one example.com account to another
example.com account. The different types of mail servers are as follows
i. Web-based e-mail Many e-mail providers have a web-based
e-mail client (e.g., AOL Mail, Gmail, Outlook.com, Hotmail, and
Yahoo! Mail). This enables users to log in to the e-mail account
by means of any compatible web browser to send and receive
their e-mail. Mail is normally not downloaded to the client, so
cannot be read without anInternet connection in progress.
ii POP3 e-mail services: Now in its third iteration, post office
protocol 3, this standard supports downloading mail from any
geographic location without connecting to a fixed server. In other
words, it means that the server you connect to holds your mail
until you log on and retrieve it. It is the standard supported by
most mail clients on the Internet, but it is getting out of vogue as
IMAP seems to be a good replacement. Received messages are
regularly deleted from the server. POP supports simple download-

and-delete requirements for right to use remote mailboxes.
iii. IMAP e-mail servers: The client/server protocol now in its
fourth version, IMAP4 takes POP to a new level. Instead of
calling for users to transfer a whole mail item to a client before
starting the message, IMAP lets users optionally download
portions of a message. For example, users can download a text
portion but preserve the graphics file attachment on the server
for future download. Moreover, it lets users select messages on
a remote server, modify them by editing either online or offline
and otherwise control server-based folders. The Internet Message
Access Protocol (IMAP) offers features to manage a mailbox from
several devices. Small portable devices such as smartphones are
gradually used to check e-mail while travelling, and to make brief
responses. Bigger devices with enhanced keyboard access are
being used to send long messages. IMAP shows the headers of
messages, the sender, the subject, and the device needs to request
to download precise messages. Typically, mail is abandoned in
folders in the mail server.
iv. MAPI e-mail servers Messaging Application Programming
Interface (MAPI) is used by Microsoft Outlook to communicate
to Microsoft Exchange Server—and to a range of other e-mail
server products such as Axigen Mail Server, Kerio Connect,
Scalix, Zimbra, HP OpenMail, IBM Lotus Notes, Zarafa, and
Bynari where vendors have MAPI integrated into their products
so that a direct access can be created throughOutlook.
Figure 1.2: Free enterprise e-mail server. Source: https://www.citynethost.com/

free-enterprise-email-server/
1.1.4 File Transfer Protocol

FTP is the most primitive Internet command and the first use of the network.
FTP is a specific Internet service that either places files on, or retrieves
files from, a remote computer. It is likely to log-on to a computer without
establishing an account and to retrieve information from its public file area.
This was one of the reasons for creating unidentified log-on to these sites.
The term anonymous FTP, was used to describe these sites. FTP utilizes
both TCP control and data connection. The TCP control connection is used
for opening and closing an FTP session and for reassigning commands
from client to server. The data connection is used for conveying single files
between client and server. Every file transfer uses a separate data connection.
Any two computers that are on the similar network (and that can be on the
Internet) can transfer files using the FTP. There is an application in there,
known as “ftp,” that forwards the actual protocol (FTP) to transfer files. The
steps involved goes as follows
i. A person runs an FTP client application on one computer.
ii. Another computer runs an FTP server program. That might be as
an “ftpd” (FTP daemon) on a UNIX/Linux computer.
iii. It could also be an FTP service on other platforms. The function
of FTP protocol is to allow autonomy between client and server
machine system files, enable exchange of files between remote
computers, and enable effective transfer of data. Essentially, it
defines the method by which data is transferred over a TCP/IP
network. You can depend on FTP to deliver files efficiently. Most
of the time, you do not have to worry whether your operating
system (Windows, Apple OX, Linux) is the same as that of an
FTP server. To computers, the TCP/IP protocol is the only thing
that matters. Sometimes, however, you might have to download
FTP server software to make it work. Finally, FTP transfers are
not necessarily secure. Be sure to explore the security features of
FTP services before jumping right in. FTP protocol falls within a
client–server model, that is, one machine sends orders (the client)
and the other awaits requests to carry out actions (the server).
During an FTP connection, two transmission channels are open.
Usually, a channel is open for data while the other is open for
commands or control channel. FTP commands make it possible
to specify the port used, data structure, method of data transfer
and the nature of the action to be conducted. However, there are
three different types of FTP commands namely access control
commands, transfer parameter commands, and FTP service
commands. Traditionally, these are port 21 for the command port
and port 20 for the data port. The confusion begins however,
when we find that depending on the mode, the data port is not
always on port 20. There are two modes of FTP namely
i. Active FTP In active mode FTP, the client connects from a random
unprivileged port (N > 1024) to the FTP server’s command port,
port 21. Then, the client starts listening to port N+1 and sends the
FTP command PORT N+1 to the FTP server. The server will then
connect back to the client’s specified data port from its local data
port, which is port 20. From the server-side firewall’s standpoint,
to support active mode FTP, the following communication
channels need to be opened: FTP server’s port 21 from anywhere
(Client initiates connection) FTP server’s port 21 to ports > 1024
(server responds to client’s control port) FTP server’s port 20
to ports > 1024 (server initiates data connection to client’s data
port) FTP server’s port 20 from ports > 1024 (Client sends ACKs
to server’s data port).The main problem with active mode FTP
actually falls on the client side. The FTP client does not create the
actual connection to the data port of the server—it simply tells
the server what port it is listening on and the server connects back
to the specified port on the client. From the client-side firewall,
this appears to be an outside system initiating a connection to an
internal client which is usually restricted.
testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2
Connected to testbox2.slacksite.com. 220 testbox2.slacksite.com
FTP server ready. Name (testbox2: slacker): slacker ---> USER
slacker 331 Password required for slacker. Password: TmpPass
---> PASS XXXX 230 User slacker logged in. ---> SYST 215
UNIX Type: L8 Remote system type is UNIX. Using binary mode
to transfer files. ftp> ls ftp: setsockopt (ignored): Permission
denied.
ii. Passive FTP To resolve the problem of the server initiating the
connection to the client, a different method for FTP connections
was established. This was identified as passive mode, or PASV,
after the command used by the client to tell the server it is in a
passive mode. In a passive mode FTP, the client initiates both
connections to the server, solving the issue of firewalls filtering
the inbound data port connection to the client from the server.
When opening an FTP connection, the client opens two random
ports locally (N > 1024 and N+1). The first port communicates
with the server on port 21, but instead of then issuing a PORT
command and allowing the server to connect back to its data port,
the client will issue the PASV command. The result of this is that
the server then opens a random unprivileged port (P > 1024) and
sends the PORT P command back to the client. The client then
initiates the connection from port N+1 to port P on the server to
transfer data. From the server-side firewall’s standpoint, to support
passive mode FTP the following communication channels need
to be opened: FTP server’s port 21 from anywhere (client initiates
connection) FTP server’s port 21 to ports > 1024 (server responds
to client’s control port) FTP server’s ports > 1024 from anywhere
(client initiates data connection to random port specified by
server) FTP server’s ports > 1024 to remote ports > 1024 (server
sends ACKs (and data) to client’s data port).
Figure 1.3: Modes of operation of types of FTP. Source: http://searchenter-

prisewan.techtarget.com/definition/File-Transfer-Protocol
1.1.5 Telnet
Telnet (TELecommunication NETwork) is a network protocol used on the
Internet or LAN connections. It is a network protocol used on the Internet or
LANs to provide a bidirectional interactive communications facility. Telnet
can connect to a remote machine that on a network and is port listening.
Typically, telnet offers access to a command-line interface on a remote host

througha simulated terminal connection which comprises an 8-bit byte-
oriented data connection over the Transmission Control Protocol (TCP).
User data is interpolated in band with TELNET control information. The
user’s computer, which initiates the connection, is referred to as the local
computer. The computer being connected to, which accepts the connection,
is referred to as the remote computer. The remote computer can be located
in the next apartment, the next town or in another country physically.
The network terminal protocol (TELNET) allows a user to log in on any
other computer on the network. We can start a remote session by stating a
computer to connect to. From that time until we finish the session, whatever
we type is sent to the other computer. The Telnet program operates on the
computer and connects your computer to a server on the network. We can
then enter commands through the Telnet program, and they will be executed
as if we issue the commands directly on the server console. This enables us
to control the server and communicate with other servers on the network. To
start a Telnet session, we must log in to a server by entering a valid username
and password. Telnet is a common way to remotely control Web servers.
TELNET clients have been accessible on most Unix systems for a long time
and are available almost for all platforms. Most network equipment and
operating systems with a TCP/IP stack support some kind of TELNET service
server for their remote configuration including ones based on Windows NT.
TELNET is a client server protocol, based on a reliable connection oriented
transport. Typically, this protocol used to establish a connection to TCP
port 23, where a Getty equivalent program (telnetd) is listening, although
TELNET predates. Telnet can be used to connect to virtually any machine
that listens on ports. In other words, you can connect to any machine that
has certain ports open. Once connected to a machine, you need to issue
UNIX based commands to interact with the remote service. For example,
a user don’t need to login, check, and send mails only through his e-mail
service provider’s interface but this can be achieved using simple telnet
commands. It is because of this reason that many hackers can send spoofed
e-mails or access information such as which services are running on the
remote machine. This is also termed banner grabbing or daemon tracking.
On windows machines, telnet client can simply be started by issuing the
telnet command in windows command shell.
1.1.6 Internet Relay Chat

The Internet Relay Chat (IRC) protocol has been designed over a number
of years for use with text-based conferencing. The IRC protocol has been
established on systems using the TCP/IP network protocol, although there is
no condition that this must remain the only layer in which it operates. IRC
itself is a teleconferencing system, which (through the use of the client–
server model) is well-suited to running on many machines in a distributed
manner. It has several benefits: it does not need a multimedia PC and unlike
the e-mail, the communication is instantaneous. Each party sees what he or
she has written in the PC screen as well as what the other person replies;
several people can join in one session. To establish a dialogue through this
system, one must take note of which channel or chat room it will take place.
That channel is actually a space in an Internet computer called server. In the
Network, there are thousands of chat channels in which people participate
in conversations on topics that vary from technology to cinema, music,
religion, and many others. A typical setup involves a distinct process (the
server) forming a central point for clients (or other servers) to connect to,
performing the required message delivery/multiplexing, and other function.
The protocol as described herein is used for both connections. There are,
however, more restrictions on client connections (which to be unreliable)
than on server connections. No definite character set is stated. The protocol
is based on a set of codes which are comprises eight (8) bits, making up an
octet. Every message comprises any number of these octets; however, some
octet values are used for control codes which function as message delimiters.
Irrespective of being an 8-bit protocol, the delimiters and keywords are such
that protocol is mostly operational from USASCII terminal and a telnet
connection.
1.2 LOCAL AREA NETWORK

LANs are privately-owned networks within a single building or campus of
up to a few kilometers in size. They are widely used to connect personal
computers and workstations in company offices and factories to share
resources (e.g., printers) and exchange data. LANs are differentiated
from other kinds of networks by three characteristics namely their size,
transmission technology, and topology. LANs are restricted in size, which
means that the worst-case transmission time is limited and identified in
advance. Knowing these limits makes it conceivable to use certain kinds of
schemes that would not otherwise be possible. It also streamlines network
management. LANs may use a transmission technology involving a cable to
which all the machines are attached. Conventional LANs run at speeds of 10
Mbps to 100 Mbps, have low delay rate (microseconds or nanoseconds), and
make very few miscalculations. Examples of LANs are Ethernet and Wi-Fi.
Figure 1.4: Local area network. Source: https://www.tutorialspoint.com/com-

munication_technologies/communication_technologies_types_of_networks.
htm
1.3 WIDE AREA NETWORK

Large WANs cover large areas of geography, often a country or a continent.
It includes a set of machines designed to run custom applications or
machines are known as hosts. This host is connected via a network or as a
subnet for a short period. The machine is owned by a customer (such as a
personal computer), while the network is managed by a telephone service or
Internet service provider (ISP). The task of the subnet is to send messages
from the host to host, such as the cellphone, from the speaker to the listener.
Separation of the network’s subnetwork from the view of the application
aspect (the host) streamlines the overall design of the network. In the vast
network, most subnet consists of two separate components: transmission
lines and switch elements. The transmission cable transfers the bit between
machines. They can be made of wire, fiber optic or radio link. Most WANs
have multiple transmission lines that connect two router ports. If two paths
that do not share cable channels want to communicate, they must do so
indirectly. When a packet is transmitted from one router to another through
one or more routers, the packet is received on each average router that is stored
there until the required overseas telephone line is open and then forwarded. A
subnet prepared in accordance with this policy is called a store-and-forward
subnet or packet-switched subnet. Nearly all wide area networks (except
those using satellites) have store-and-forward subnets. When the packets

are small and all the same size, they are often called cells. The principle of
a packet-switched WAN is so important. Generally, when a process on some
host has a message to be sent to a process on some other host, the sending
host first cuts the message into packets, each one bearing its number in the
sequence. These packets are then injected into the network one at a time in
quick succession. The packets are transported individually over the network
and deposited at the receiving host, where they are reassembled into the
original message and delivered to the receiving process.
1.4 WIRELESS LOCAL AREA NETWORK

A wireless LAN (WLAN) is aLANthat does not depend on wiredEthernet
connections. A WLAN can be either an extension to a current wired network
or an alternative to it. WLANs have data transfer speeds ranging from 1 to
54 Mbps, with some manufacturers offering proprietary 108Mbps solutions.
The 802.11n standard can reach 300 to 600 Mbps. Because the wireless signal
is broadcast so everybody nearby can share it, several security precautions
are necessary to ensure only authorized users can access your WLAN. A
WLAN signal can be broadcast to cover an area ranging in size from a small
office to a large campus. Most commonly, a WLAN access point provides
access within a radius of 65 to 300 feet. WLAN types comprise private,
home or small business WLAN. Commonly, a home or business WLAN
employs one or two access points to broadcast a signal around a 100- to
200-ft radius. You can find equipment for installing a home WLAN in many
retail stores. With few exceptions, hardware in this category subscribes to
the 802.11a, b, or g standards (also known asWi-Fi); some home and office
WLANs now adhere to the new 802.11n standard. Also, because of security
concerns, many WLANS in homes and offices adhere to the Wi-Fi Protected
Access 2 (WPA2) standard. An enterprise class WLAN employs a large
number of individual access points to broadcast the signal to a wide area.
The access points have more features than home or small office WLAN
equipment, such as better security,authentication, remote management, and
tools to help integrate with existing networks. These access points have a
larger coverage area than home or small office equipment, and are designed
to work together to cover a much larger area. This equipment can adhere to
the 802.11a, b, g, or n standard, or to security-refining standards, such as
802.1x and WPA2. A wireless LAN or WLAN is a wireless LAN that uses
radio waves as its carrier. The last link with the users is wireless, to give
a network connection to all users in a building or campus. The backbone

network usually uses cable.
1.5 METROPOLITAN AREA NETWORK

A metropolitan area network (MAN) is a class of network which serves a large
geographical area between 5 to 50 kilometers in range. This geographical area
can include several buildings, such as a college campus, sometimes referred
to as a campus network, or an area as large as a city (metropolitan area).
These networks are larger than a LAN, but smaller than a WAN, generally
providing communications via fiber optic cable, and mostly works within
Layer 2, or the data link layer, of the Open System Interconnection (OSI)
model. Usually, a MAN does not belong to any particular organization, but
rather a consortium of users or a single network provider which takes charge
of the service, owns its hardware and other equipment, and sells access to
the network to end users. In this regard, levels of service must be discussed
and agreed upon between each user and the MAN provider.
1.6 CONNECTING TO THE INTERNET

There are different ways of connecting to the Internet. It depends on the user
preference or available tools.
1.6.1 Connecting to the Internet with a modem

Internet connection through computer modem (such as 56K modems) is still
a way to access the Internet even though the speed of internet access is
increasing. Although modem internet connection can be a cheap solution,
it has a slow connection. If you plan to do more than search the Internet or
read and send e-mail, you should consider using the Internet. For example,
if you want to play online, we recommend using a broadband connection
instead of modem. Using a modem to connect to the Internet requires that
your computer has an internal or external modem. You also need a home
telephone line (landline). After you verify that your computer is compatible
with internet connection, you need to find an ISP. In most regions, you can
connect to the Internet via local ISPs. Another possibility is to consider
large ISPs such as AOL or MSN that provide Internet services in many areas
around the world.
Figure 1.5: A modem. Source: https://www.computerhope.com/issues/

ch000720.htm
1.6.2 Broadband Connection

Connecting to the Internet overbroadbandis a popular solution for connecting
to the Internet today. Broadband is a much faster solution for connecting
to the Internet when compared to a standard 56k modem. Having more
bandwidth allows you to do more exciting things on the Internet, such as
watch movies, listen to music, and playing games, as well as much faster
load times for websites. Unfortunately, broadband service is not available in
all areas. Therefore, before getting this service, you must first determine if it
is available in your area. Most broadband services are provided by your local
phone companies or cable companies. Contact your local phone or cable
service providers to see if they have broadband service available in your
area. If broadband service is available in your area, the company provides
you with the hardware (e.g., able modem) required to connect to their service.
This hardware typically connects to a network card (RJ-45connector) or
USB connection. If your provider does not offer a wirelessrouteryou can
purchase and connect a wireless router (shown above) to connect any Wi-Fi
to the Internet.
1.6.3 Smartphone Connection

You may also be able to use your smartphones an Internet connection for your
computer. Doing so requires you to use tethering software, which allows the
smartphone to act as a modem or wireless access point for the computer to
use for Internet access. Configuring the tethering software and the computer
to use your smartphone for Internet service differs depending on which
tethering software you use, as well as the type of phone you have. Check
online for specific instructions for the tethering software and smartphone
you are using. However, not all smartphones are capable of tethering, and
not all cell phone carriers allow smartphones on their network to be used for
tethering. Cell phone carriers that allow tethering may not provide support
for tethering. These carriers may also charge an additional fee to tether their
smartphone.
1.6.4 Leased Connection

The leased line, also known as the dedicated line, connects two locations
for private telecommunication services for voice and/or data. A leased line
is not a reserve cable but a circuit that is situated between two points. The
leased line is always active and is offered for a fixed monthly fee. Leased
lines can cover a short or long distance. They keep loops open anytime,
unlike conventional telephone services that use the same line for various
conversations through a process called switching. The network is usually
leased by the company to affiliate the branch offices of any organization.
The leased line ensures the speed for network traffic between locations.
For example, T1 leased line is common and offers the same data rate as
a symmetrical DSL. Individuals can lease rental leasing for high speeds,
but their high prices discourage most people and far more affordable home
options are available with higher bandwidth than a simple dial-up phone line,
including residential DSL and cable internet broadband service. Fractional
T1 lines, starting at 128 Kbps, reduce this cost somewhat. They can be found
in some apartment buildings and hotels.
1.7 WEB SERVICES

The term Web services describes a standardized way of integrating Web-
based applications using the XML, Simple Object Access Protocol(SOAP),
WSDL, and UDDI open standards over an IP backbone. XML is used to tag
the data, SOAP is used to transfer the data, WSDL is used for describing the
services available and UDDI is used for listing what services are available.
Used primarily as a means for businesses to communicate with each other
and with clients, web services allow organizations to communicate data
without intimate knowledge of each other’s IT systems behind the firewall.
Unlike traditional client/server models, such as a Web server/Web page
system, Web services do not provide the user with a GUI. Web services
instead share business logic, data, and processes through a programmatic
interface across a network. The applications interface, not the users.
Developers can then add the Web service to a GUI (such as a Web page
or an executable program) to offer specific functionality to users. Web
services allow different applications from different sources to communicate
with each other without time-consuming custom coding, and because all
communication is in XML, web services are not tied to any one operating
system or programming language. For example, Java can talk with Perl,
Windows applications can talk with UNIX applications. There are two basic
types of web services namely SOAP and Representational State Transfer.
Figure 1.6: Overview of Web services. Source: https://www.javatpoint.com/

what-is-web-service
1.7.1 Searching the World Wide Web

The web’s fast-growing size and lack of structural style present a new
challenge for information retrieval (Lawrence & Giles, 1999). Conventional
search techniques involve the users typing in search keywords which the
search services can then use to locate the desired web pages. However, this
approach normally retrieves too many documents, of which only a small
fraction are relevant to the users’ needs. Furthermore, the most relevant
documents do not necessarily appear at the top of the query output list.
Numerous search technologies have been applied to web search engines;
however, the dominant search methods have yet to be identified. Two different
approaches are applied to web search services: genuine search engines and
directories. The difference lies in how listings are compiled. Search engines,
such as Google, create their listings automatically. A directory, such as
Yahoo!, depends on humans for its listings. Some search engines, known
as hybrid search engines, maintain an associated directory. Figure 1 shows
the system structure of a typical search engine. Search engines traditionally

consist of three components: (i) the crawler: A crawler is a program that
automatically scans various web sites and collects web documents from
them. Two search algorithms, breadth-first searches and depth-first searches,
are widely used by crawlers to traverse the Web. (ii) the indexing software:
automatic indexing is the process of algorithmically examining information
items to build a data structure that can be quickly searched. Traditional
search engines utilize the following information, provided by HTML scripts,
to locate the desired web pages that is, the content, descriptions, hyperlink,
hyperlink text, keywords, page title, text with a different font, and the first
sentence. (iii) Search and ranking software: Query processing is the activity
of analyzing a query and comparing it to indexes to find relevant items. A
user enters a keyword or keywords, along with Boolean modifiers such as
“and,” “or,” or “not,” into a search engine, which then scans indexed web
pages for the keywords. To determine in which order to display pages to the
user, the engine uses an algorithm to rank pages that contain the keywords.
Most search services are backed up by or are cooperating with several other
services. This is because an independent or stand-alone service contains less
information and thus tends to lose its users. Most search engines on the list
not only provide web search services but also act as portals, which are web
home bases from which users can access a variety of services, including
searches, e-commerce, chat rooms, news, and so forth.
1.7.2 Hypertext Markup Language

The Hypertext Markup Language (HTML) allows you to describe the basic
physical structure of a document using HTML tags. A markup language is a
set of formatting codes that affects that the way preset information will be
displayed. It is used to create HTML documents. It is not a programming
language. The information remains static all the documents that you view
on the WWW are created using HTML. Each HTML tag describes a specific
element on the document. The content within the “<h1>” tag describes
the heading. The content within the “<p>” tag describes a paragraph. The
content within the “<button>” tag describes a button. A web browser uses
these HTML tags to determine how to display the document. Example:
Here is a raw text as important as having a great domain name, professional
web design can help you satisfy customers, attract search engines and
avoid technical glitches. The text above when converted to HTML file is
written thus; <p class=MsoNormal style=’mso-margin-top-alt: auto; mso-
margin-bottom-alt: auto; line-height:150%; vertical-align: baseline’><span
style=’mso-fareast-font-family: “Times New Roman”’>As important as

having a great domain name, professional web design can help you satisfy
customers, attract search engines and avoid technical glitches.<o: p></o:
p></span></p>.
Figure 1.7: Coding a Website in Notepad. Source: https://www.howcast.com/

videos/476895-html-tutorial-coding-a-website-in-notepad/
1.7.3 Ports
Computer ports are vital features of all computing devices. Computer ports
provide the input and output interfaces the device needs to communicate
with peripherals and computer grids. The most important ports on computers
are used for computer networking. The transport layer’s task is to provide
a network-independent message transport service between pairs of network
ports. Ports are software-defined destination points at a host computer. They
are attached to processes, enabling data transmission to be addressed to a
specific process at a destination node A computer port is a type of electronic,
software- or programming-related docking point through which information
flows from a program on your computer or to your computer from the
Internet or another computer in a network. (A network, by the way, is a
series of computers that are physically or electronically linked. In computer
terms, a computer or a program connects to somewhere or something
else on the Internet througha port. Port numbers and the user’s IP address
combine into the “who does what” information kept by every ISP. Ports
are numbered for consistency and programming. The most commonly used
and best-known ports are those numbered 0 to 1023 dedicated for Internet
use, but they can extend far higher for specialized purposes. Each port set
or range is assigned specialized jobs or functions, and that’s generally all
they do. Usually, all identical system services or functions use the same
port numbers on the receiving servers. For example, all computers accessing
or requesting Quote of the Day will always use port 17, because that port
is officially reserved for that purpose, and only requests for that service
use port 17. Outgoing information is channeled through a different or

private port, keeping the “incoming line” open for others. E-mail received
on a local computer generally uses a TCP port 25. File Transport Protocol
or FTP uses port 21, to name only a few port assignments. A port can be
either physical or virtual. Physical network ports allow connecting cables to
computers, routers, modems, and other peripheral devices. Several different
types of physical ports available on computer network hardware include:
(i) Ethernet ports - square-shaped connection points for Ethernet cables.
(ii) USB ports - rectangular-shaped connection points for USB cables. (iii)
Serial ports - round-shared connection points for serial cables. Whereas
wired computer networks rely on physical ports and cables, wireless
networks do not need them. Wi-Fi networks, for example, utilize channel
numbers representing radio signaling bands. Virtual ports are an essential
component of IP networking. These ports allow software applications to
share hardware resources without interfering with each other. Computers
and routers automatically manage network traffic traveling via their virtual
ports. Network firewalls additionally provide some control over the flow
of traffic on each virtual port for security purposes. In IP networking, these
virtual ports are numbered 0 through 65535.
1.7.4 Domain name Addressing

Name System is usually used to translate a hostname or domain name (e.g.,
nec.edu.np) into an IP address (e.g., 202.37.94.177). Domain name comprise
a hierarchy so that names are unique, yet easy to remember. DNS makes it
possible to refer to the IP based system (hosts) by human friendly names
(domain names). Name resolution is that act of defining the IP address of
a given hostname. The benefits of DNS are two folds. First Domain Name
can be logical and easily remembered. Secondly, should an IP address for
a host change, the domain name can still resolve transparently to the users
or application. DNS name resolution is a critical Internet service. Many
network services require functional name service for correct operation.
Domain names are separated by dots with the uppermost element on the
right. Each element may be up to 63 characters long; the entire name may
be at most 255 characters long. Letters, numbers or dashes may be used in
an element. To have a hierarchical name space, a domain name space was
designed. In this design, the names are defined in an inverted-tree structure
with the root at the top. The tree can have only 128 levels: level 0 (root) to
level 127. The generic domains define registered hosts according to their
generic behavior.
Table 1.7: Generic Domains
Label Description
Aero Airlines and aerospace companies
Biz Businesses or firms
Com Commercial organizations
Coop Cooperative business organizations
Edu Educational institutions
Gov Government institutions
Info Information service providers
Int International organizations
Mil Military groups
Museum Museums and other nonprofit organiza-

tions
Name Personal names (individuals)
Net Network support centers
Org Nonprofit organizations
Pro Professional individual organizations
Source: https://dayaramb.files.wordpress.com/2011/03/computer-network-
notes-pu.pdf
1.7.5 Uniform Resource Locators

A Uniform Resource Locators (URL) is the address of a specific webpage
or file on the Internet. A URL provides a way to locate a resource on the
web, the hypertext system that operates over the Internet. The URL contains
the name of the protocol to be used to access the resource and a resource
name. The first part of a URL identifies what protocol to use. The second
part identifies the IP address or domain name where the resource is located.
URL is the most common type of Uniform Resource Identifier (URI). URIs
are strings of characters used to identify a resource over a network. URL
protocols include Hypertext Transfer Protocol (HTTP) and HTTPS s(HTTP
Secure) for web resources, “mailto” for e-mail addresses, “ftp” for files on
a FTP server, and telnet for a session to access remote computers Parts of
a URL http://host.company.com:80/a/b/c.html? user=Alice& year=2008#p2
Scheme (http:): identifies protocol used to fetch the content. Host name (//
host.company.com): name of a machine to connect to. Server’s port number
(80): allows multiple servers to run on the same machine. Hierarchical
portion (/a/b/c.html): used by server to find content. Query parameters
(? user=Alice& year=2008): provides additional parameters While all
website URLs begin with “http,” several other prefixes exist. Below is
a list of various URL prefixes: http—a webpage, website directory, or
other file available over HTTP ftp—a file or directory of files available to
download from an FTP server news—a discussion located within a specific
newsgroup telnet—a Unix-based computer system that supports remote
client connections gopher—a document or menu located on a gopher server
wais—a document or search results from a WAIS database mailto—an
e-mail address (often used to redirect browsers to an e-mail client) file—a
file located on a local storage device (though not technically a URL because
it does not refer to an Internet-based location) You can manually enter a
URL by typing it in the address bar of your web browser. For example, you
might enter a website URL printed on a business card to visit the company’s
website. Most URLs, however, appear automatically when you click on a
link or open a bookmark. If the server name in the URL is not valid, your
browser may display a “Server not found” error. If the path in the URL is
incorrect, the server may respond with a 404 error.
Figure 1.8: Components of a URL. Source: https://outspokenmedia.com/https/

claiming-all-domain-versions-in-google-search-console/
REFERENCES
1. Berners-Lee, T. (1989).Information management: A proposal, CERN
[The first document describing the World Wide Web].RetrievedJanuary
10, 2018.
2. Birman, K. (2005). Reliable distributed systems: Technologies, web
services and applications. Springer-Verlag. Retrieved January15,
2018, from http://net.pku.edu.cn/~course/cs501/2011/resource/2005-
Book Reliable%20Distributed%20Systems.pdf
3. Coulouris, G, Dollimore, J.,&Kindberg, T. (2005). Distributed systems:
Concepts and design (4th ed.). Addison Wesley.Retrieved January10,
2018, from http://www.gecg.in/papers/ds5thedn.pdf
4. Kozierok, C. (2005). The TCP/IP guide: A comprehensive, illustrated
internet protocols reference. No Starch Press Series.Retrieved
January30, 2018, from http://index-of.es/Magazines/hakin9/books/No.
Starch. TCP. IP. Guide. Oct.2005.pdf
5. Verissimo, P., &Rodrigues, L. (2012). Distributed systems for system
architects (Vol. 1).New York:Springer Science & Business Media.
CHAPTER 2
FUNDAMENTAL CONCEPTS OF
DISTRIBUTED SYSTEMS
“The result of these technologies is that it is now not only feasible, but easy,
to put together computing systems composed of large numbers of computers
connected by a high-speed network.”
-Andrew Tanenbaum
CONTENTS
2.1 Distributed Systems................................................................................................. 26
2.2 Architecture Models................................................................................................ 28
2.3 Internet Architecture................................................................................................ 32
2.4 Ethernet Design....................................................................................................... 36
2.5 Open Systems Interconnections (ISO/OSI Reference Model) ................................... 39
2.6 Middleware............................................................................................................. 43
2.7 The TCP/IP Reference Model.................................................................................... 45
2.8 Interprocess Communication................................................................................... 48
References..................................................................................................................... 51
Many of the essential principles of distributed systems play a significant role

in technological developments of recent years and hence an understanding of
the core technology is absolutely crucial to knowledge of present computing
systems. This chapter provides an in-depth understanding of fundamental
principles and models underlying the theory, algorithms, and systems
aspects of distributed computing.
Here, we also discuss the concepts of distributed systems but special
attention is given to operating systems and internet models while the other
types of distributed systems are discussed in the subsequent chapters.
Furthermore, we introduce object-oriented systems and show how objects
of such systems can be distributed among the different participating sites.
We go on to discuss middleware in traditional distributed systems and their
various architectures.
2.1 DISTRIBUTED SYSTEMS

A distributed system is one in which components located at networked
computers communicate and coordinate their actions only by-passing
messages. Most definitions have not reached a consensus categorically, so
it is normal to give a loose definition. In other words, “a distributed system
consists of a collection of autonomous computers linked by a computer
network and equipped with distributed system software” (Coulouris et
al., 2000). This software enables computers to coordinate their activities
and to share the resources of the system hardware, software, and data. A
distributed operating systems software over a collection of independent,
networked, communicating, and physically separate computational nodes.
Each individual node holds a specific software subset of the global aggregate
operating system. Each subset is a composite of two distinct service
providers. The first is a ubiquitous minimal kernel, or microkernel, that
directly controls that node’s hardware. Second is a higher-level collection of
system management components that coordinate the node’s individual and
collaborative activities. These components abstract microkernel functions
and support user applications. The microkernel and the management
components collection work together. They support the system’s goal
of integrating multiple resources and processing functionality into an
efficient and stable system. This seamless integration of individual nodes
into a global system is referred to as transparency, or single system image;
describing the illusion to users of the global system’s appearance as a single
computational entity. Computers that are connected by a network may be
Fundamental Concepts of Distributed Systems 27
spatially separated by any distance. They may be on separate continents,

in the same building or in the same room. Coulouris et al. (2000) described
the consequences of distributed systems as follows; 1. Concurrency: In a
network of computers, there is usually a simultaneous execution of program.
Two separate users can work on their computers while sharing resources
such as web pages or documents when needed. The capability of the system
to manage shared resources can be improved by adding more resources
(for example. computers) to the network. The coordination of concurrently
executing programs that share resources is also a vital and recurring topic
(see chapter 3, Time and Global States). 2. No global clock: When programs
need to collaborate, they coordinate their actions by exchanging messages.
Close coordination is mostly dependent on shared idea of the time at which
the operations of programs take place. However, there are restrictions to the
accuracy of clock synchronization by networked computers. That is, there is
no single global concept of the correct time. This is a direct result of the fact
that communication can be made only by sending messages via a network.
Examples of these difficulties in timing and solutions to them are discussed
in the next chapter. 3. Independent failures: every computer system is liable
to fail; therefore, it is the obligation of system designers to plan for the
negative outcome or possible failures. Distributed systems can fail in new
ways.
Figure 2.1: Example of a distributed system. Source: http://books.cs.luc.edu/

distributedsystems/issues.html
One of the consequences is the isolation of computers that are
interconnected to the systems of which the cause can be traced to faults but
that does not stop them from running. As a matter of fact, the programs on
these systems may not be able to recognize a failure in the network or an
unusual reduction in network speed. Similarly, the failure of a computer, or

the sudden termination of a program somewhere in the system (a crash), is not
instantly made known to the other components with which it communicates.
Each component of the system can fail individually, leaving the others still
running.
2.2 ARCHITECTURE MODELS

The architecture of a system is its structure in terms of separately specified
components and their interrelationships. The overall goal is to ensure that the
structure will meet present and likely future demands on it. Major concerns
are to make the system reliable, manageable, adaptable, and cost-effective.
The architectural design of a building has similar aspects—it determines
not only its appearance but also its general structure and architectural style
(gothic, neo-classical, modern) and provides a consistent frame of reference
for the design (Paulo V. and Luís R., 2012).
2.2.1 Physical Model

A physical model is a representation of the underlying hardware elements
of a distributed system that abstracts away from specific details of the
computer and networking technologies employed. The end result is a
physical architecture with a significant increase in the level of heterogeneity
embracing, for example, the tiniest embedded devices utilized in ubiquitous
computing through to complex computational elements found in Grid
computing. These systems deploy an increasingly varied set of networking
technologies and offer a wide variety of applications and services. Such
systems potentially involve up to hundreds of thousands of nodes. The table
below shows the division of distributed systems according to chronology.
However, the characteristics of conventional distributed system are well
explained with regards to these (see chapter 8, Mobile and ubiquitous
computing).
Table 2.1 Generations of Distributed Systems
Distributed systems Early Internet scale Contemporary
Scale Small Large Ultra-large

Heterogeneity Limited (typi- Significant in Added dimensions

cally relatively terms of plat- introduced including
homogenous forms, languages radically different
configura- and middleware styles of architecture
tions)
Openness Not a priority Significant prior- Major research chal-
ity with a range lenge with existing
of standards standards not yet able
introduced to embrace
complex systems
Quality of service In its infancy Significant Major research chal-
priority with a lenge with existing
range of services services not yet able
introduced to embrace complex
systems
Source: Distributed Systems: Concepts and Design. 4th edition, Addison

Wesley http://www.gecg.in/papers/ds5thedn.pdf
2.2.2 Architectural Model

An architectural model of a distributed system summaries the roles of
the individual components of a distributed system. Architectural models
describe a system with regards to the communication and calculative
operations performed by the calculative elements; the calculative elements
being discrete computers or aggregates of them supported by applicable
network interconnections. The architecture includes: (i) The division of
responsibilities between system components. (ii) The placement of the
components on computers in the network.
2.2.3 Architectural Patterns Client–Server

This is the architecture that is most often cited when distributed systems are
discussed. It is historically the most important and remains the most widely
employed. In particular, client processes interact with individual server
processes in potentially segregated host computers to access the shared
resources that they manage. Servers may, in turn, be clients of other servers,
as the figure below indicates. For example, a web server is often a client of
a local file server that manages the files in which the web pages are stored.
Web servers and most other Internet services are clients of the DNS service,
which translates Internet domain names to network addresses.
Figure 2.2: A client-server model. Source: http://www.goethes-farbenlehre.

com/
i. Thin-client model
In a thin-client model, all of the application processing and data management
is carried out on the server. The client is simply accountable for running the
presentation software. A thin client refers to software/hardware the supports
a window-based user interface local to the user while executing application
programs on a remote computer. It is normally used when legacy systems
are migrated to client server architectures. The legacy system acts as a server
in its own right with a graphical interface implemented on a client. A major
disadvantage is that it places a heavy processing load on both the server
and the network. Thin clients are devices/programs that have very limited
functionality and depend heavily on their server counterparts. Thin clients
can function as a user workstation that contains a minimal operating system
and little or no data storage. Examples include:–Sun Rays–VNC–Microsoft
remote desktop. Essentially, it can function as programs—a client mainly
provides a user interface, while the bulk of processing occurs in the server,
for example, the OnLive gaming client (about 10 MB in size).
ii. Fat–client model

In this model, the server is only responsible for data management. The
software on the client implements the application logic and the interactions
with the system user.
Fat clients are devices/programs that are powerful enough and operate
with limited dependence on their server counterparts. Fat clients can function
as a device or user workstation that is powerful and fully-featured in its own
right,e.g., a desktop PC, a notebook, or a laptop.
Fat clients can also function as programs whereby a client carries a

relatively large proportion of the processing load, for example, the Lineage
II gaming client (more than 2 GB in size). However, more processing is
assigned to the client as the application processing is locally executed. This
model is most suitable for new C/S systems where the abilities of the client
system are known in advance. It is more complex than a thin client model,
especially for management. New versions of the application have to be
installed on all clients.
iii. Three-tiered client–server model

In some applications, servers may also need to be clients, which lead to
a three-level architecture. Three-tiered architecture is a technical hardware
and software configuration in which the presentation, application, and
database components of the architecture are resident on separate and
distinct systems within the configuration. Some examples are distributed
transaction processing and web servers that interact with database servers.
In three-tiered architectures, functionality is distributed across three levels
of machines instead of two.
Figure 2.3: A desktop PC as an example of a fat client.
Source: https://www.cnet.com/products/dell-xps-one-27-all-in-one-desktop/re-
view/
2.2.4 Fundamental Model

Fundamental models deal with formal description of the properties that is
common to architecture models. As no global time in a distributed system,
so the clocks on different computers do not necessarily give the same time as
one another. Messages communications can be affected by delays and suffer
from a variety of failures and vulnerable to security attacks. All system models
have some common fundamental properties. There are three fundamental
models namely interaction models, failure models, and security models. (i)
Interaction: Processes communicate with messages and coordinate through
synchronization and ordering of activities. The message delays are often
of considerable duration, the coordination between processes is limited by
lack of global clock. The interaction model deals with performance and
with difficulty of setting time limits. (ii) Failure: The correct operation is
threatened whenever a fault occurs in any of the computers and network.
We should define types of faults to tolerate them for the system to continue
to run correctly. The failure model attempts to give a precise specification of
the faults that can be exhibited by processes and communication channels.
iii. Security: The modular feature of distributed system and their openness
exposes them to attack by both external and internal agents. Security model
defines and classifies the forms of attack may take, providing a basis for the
analysis of threats to a system and for the design of system that are able to
resist them. The security model discusses the possible threats to processes
and communication channels. It introduces the concept of a secure channel,
which is secure against those threats
2.3 INTERNET ARCHITECTURE

The Internet is structurally made of various components such as middleware
which is further subdivided into distributed object middleware (DOM) and
message-oriented middleware (MOM) and peer to peer (P2P). These are
succinctly described in the subsequent chapter (see chapter).
2.3.1 Data formatting

A key idea in network layering is data encapsulation. Each layer takes the
data presented to it from its higher layer, treats that as an opaque sequence of
bytes that it does not read or manipulate in any way, adds its own headers or
trailers to the beginning and/or end of the presented data, and then sends this
new chunk of data to the layer below it. The lowest layer, the physical layer,
is responsible for actually sending the data over the communication link
connecting the node to the next one end route to the eventual destination.
2.3.2 Packet encapsulation

The message passed between layers in either the OSI or the TCP/IP stacks
is done by sending packets of data from one layer to the next, and then
eventually across the network. Each layer has managerial information that it
has to keep about its own layer. It does this by adding header information to
the packet it receives from the layer above, as the packet passes down. On
the receiving side, these headers are removed as the packet moves up. When
data is passed from a higher layer to the next lower layer, a certain amount
of control information is attached to the data. The control information is
normally added in front of the data, and is called a header. If the control
information is appended to the data, it is called a trailer. All protocols have
headers and, but only very few have trailers. The process of adding header
and trailers to data is called encapsulation. The data between the header
and the trailer is called the payload. Collectively, header, payload, and (if
present) trailer, make up a protocol data unit. There is a usual practice for
naming protocol data units in the TCP/IP protocol suite: In TCP they are
called segments, in UDP and IP, they are called datagrams, and at the data
link layer, they are called frames. The generic name packet is used when
the protocol data unit does not denote a specific protocol or layer. The
encapsulation process is illustrated in the figure below. The protocol data
unit at one layer makes up the payload at the next lower layer.
Figure 2.3: Encapsulation of data in the TCP/IP protocol stack. Source: https://
www.technologyuk.net/telecommunications/internet/tcp-ip-stack.shtml
2.3.3 IP header format

Unlike the post office, a router or computer cannot determine the size of
a package without additional information. A person can look at a letter
or box and define how big it is, but a router cannot. Therefore, additional
information is required at the IP layer, in addition to the source and destination
IP addresses. The figure represented below is a rational representation of the
information that is used at the IP layer to enable the delivery of electronic
data. This information is called a header and is analogous to the addressing
information on an envelope. A header contains the information required to
route data on the Internet and has the same format regardless of the type of
data being sent. This is the same for an envelope where the address format
is the same irrespective of the type of letter being sent.
Figure 2.4: IP Protocol Header. Source: https://www.thegeekstuff.

com/2012/03/ip-protocol-header
2.3.4 Packet fragmentation

An IP packet that is larger than the maximum transmission unit (MTU) of an
interface, is too large for transmission over that interface. The packet must
either be fragmented, or discarded (and an ICMP error message returned to
the sender). In either case, the original data will be fragmented into smaller
packets (less than the smallest MTU) to allow it to be received by the final
destination system. If a router receives an IP packet that is too large for the
network to which the packet is being forwarded, IP fragments the original
packet into smaller packets that fit on the downstream network. When the
packets arrive at their final endpoint, IP on the terminus host reconstructs
the fragments into the original payload. This process is referred to as
fragmentation and reassembly. Fragmentation can occur in environments
that have a mix of networking media, such as Ethernet and Token Ring.
The fragmentation and reassembly works as follows:(i) When an IP packet
is sent by the source, it places a unique value in the identification field.(ii)
The IP packet is received at the router. The IP router notes that the MTU
of the network onto which the packet is to be forwarded is smaller than the
size of the IP packet.(iii) IP divides the original IP payload into fragments
that fit on the next network. Each fragment is sent with its own IP header
that contains: (i) The originalidentificationfield identifying all fragments
that belong together.(ii)Themore fragments flag indicating that other

fragments follow. Themore fragments Flagis not set on the last fragment,
because no other fragments follow it.(iii)Thefragment offset field specifying
the position of the fragment relative to the original IP payload. When the
fragments are received by IP at the remote host, they are identified by the
identification field as belonging together. The fragment offset field is then
used to reassemble the fragments into the original IP payload.
2.3.5 Addressing
As with any other network-layer protocol, the IP addressing scheme is
integral to the process of routing IP datagrams through an internetwork. Each
IP address has specific components and follows a basic format. These IP
addresses can be subdivided and used to create addresses for subnetworks, as
discussed in more detail later in this chapter. Each host on a TCP/IP network
is assigned a unique 32-bit logical address that is divided into two main parts:
the network number and the host number. The network number identifies a
network and must be assigned by the Internet Network Information Center
(InterNIC) if the network is to be part of the Internet. An ISP can obtain blocks
of network addresses from the Inter NIC and can itself assign address space
as necessary. The host number identifies a host on a network and is assigned
by the local network administrator. Internet network layer addresses have a
fixed size. Depending on the protocol version (IPv4 or IPv6), these addresses
are either 4-byte or 16-byte long. (i) Four-byte IPv4 addresses are typically
written as four decimal numbers separated by dots where every decimal
number represents one byte (dotted quad notation). A typical example is
the IPv4 address 212.201.48.1. (ii)Sixteen-byte IPv6 addresses are typically
written as a sequence of hexadecimal numbers separated by colons (:)
where every hexadecimal number represents two bytes. Leading nulls can
be omitted, and two consecutive colons can represent a sequence of nulls.
For example, the IPv6 address 1080:0:0:0:8:800:200C:417A can be written
somewhat shorter as 1080:8:800:200C:417A. IPv6 addresses which contain
IPv4 addresses can be written by using the dotted quad notation for the IPv4
address portion. For example, theIPv6 address 0:0:0:0:0:0:0D01:4403 can
be written as:0D01:4403 as well as:13.1.68.3.
2.3.6 Dynamic routinsg

IP routing protocols are dynamic. Dynamic routing calls for routes to be
calculated spontaneously at regular intervals by software in routing devices.
This contrasts with static routing, where routers are established by the
network administrator and do not change until the network administrator
changes them. An IP routing table, which consists of destination address/
next hop pairs, is used to facilitate dynamic routing. An entry in this table,
for example, would be interpreted as follows: to get to network 172.31.0.0,
send the packet out Ethernet interface 0 (E0). IP routing specifies that IP
datagrams travel through internet works one hop at a time. The entire route
is not known at the onset of the journey, however. Instead, at each stop, the
next destination is calculated by matching the destination address within
the datagram with an entry in the current node’s routing table. Each node’s
involvement in the routing process is limited to forwarding packets based
on internal information. The nodes do not check whether the packets get to
their ultimate destination, nor does IP provide for error reporting back to the
source when routing anomalies occur.
2.4 ETHERNET DESIGN

Ethernet work both in the data link layer (Layer 2) and the physical layer
(Layer 1). There are different Ethernet standards that support different band
of data. 10 Mb/s 100 Mb/s 1000 Mb/s (1 Gb/s) 10,000 Mb/s (10 Gb/s)
40,000 Mb/s (40 Gb/s) 100,000 Mb/s (100 Gb/s).
Figure 2.5: Ethernet at Data Link Layer. Source:http://www.tech-faq.com/

ethernet-at-the-data-link-layer.html
Ethernet standards define both the Layer 2 protocols and the Layer 1
technologies. For the Layer 2 protocols, as with all 802 IEEE standards,
Ethernet relies on the two separate sublayers of the data link layer to
operate, the Logical Link Control (LLC) and the MAC sublayers which
are explained later in this book. There are two important ways to view the
Ethernet design namely architecture and implementation. Architecture lays
emphasis on the logical divisions of the systemand how they are rightly
suited while implementation stresses the actual modules, and their packaging
and interconnection. Ethernet system is divided into two parts: the data link
layer and the physical layer. These layers are intended to correspond closely
to the lowest layers of the ISO model for Open Systems Interconnection.
Architectural organization of the specification has two main advantages:(i)
Clarity: aclean overall separation of the design along architectural lines
makes the specification clearer.(ii) Flexibility: segregation of medium-
dependent aspects in the physical layer allows the Data Link Layer to apply
to transmission media other than the stated coaxial cable.The architectural
model is based on a set of interfaces different from those emphasized in
the implementations. One essential aspect of the design, however, must be
addressed largely in terms of the implementation interfaces: compatibility.
Two important compatibility interfaces are defined within what is
architecturally the Physical Layer which is the coaxial cable interface and the
transceiver cable interface.The major division in the Ethernet architecture is
between the Physical Layer and the Data Link Layer, corresponding to the
lowest two levels in the ISO model. The upper levels of the overall network
architecture, which use the Data Link Layer, will be collectively referred
to as the “Client Layer” as, strictly speaking, the identity and function of
higher level facilities are outside the scope of this specification. The intent
is that the Ethernet physical and data link layers support the higher layers
of the ISO model (Network Layer, Transport Layer, etc.) as shown in the
figure below.
Figure 2.6: How LAN protocols map to the OSI reference model. Source:
http://www.ciscopress.com/articles/article.asp? p=2092245&seqNum=2
2.4.1 Layering
The major division in the Ethernet architecture is between the physical layer
and the data link layer, corresponding to the lowest two levels in the ISO
model. The higher levels of the overall network architecture, which use the
data link layer, will be collectively referred to as the “client layer” as, strictly
speaking, the identity and function of higher level facilities are outside the
scope of this specification. The purpose is that the Ethernet physical and
data link layers support the higher layers of the ISO model (Network Layer,
Transport Layer, etc.).
2.4.2 Data link layer

The data link layer packages data from the physical layer into groups
called blocks, frames, or packets. If frames are to be disseminated to
different systems on the network, the data link layer adds a header to the
frame to define the physical address of the sender (source address) and/
or receiver (destination address) of the frame. The data-link layer provides
flow-control, access-control, and error-control.Data link layer defines
a medium-independent link level communication facility, built on the
medium-dependent physical channel provided by the physical layer. It is
valid for a general class of local area broadcast media suitable for use with
the channel access discipline known as carrier-sense multiple-access with
collision–detection (CSMA-CD). Compatibility with non-contention media
(e.g., switched lines, token-passing rings, etc.) while a worthwhile topic for
further research, is not addressed in this specification. The data link layer
specified here is proposed to be as related as possible to that described in
the ISO model. In a broadcast network like the Ethernet, the notion of a
data link between two network entities does not correspond directly to a
distinct physical connection. Nevertheless, the two main functions generally
associated with a data link control procedure are present. The LLC sublayer
of the data link layer manages communications between devices over a
single link of a network. LLC is defined in the IEEE 802.2 specification.
IEEE 802.2 defines a number of fields in data link layer frames that allow
multiple higher-layer protocols to share a single physical data link. LLC
supports both connectionless and connection-oriented services used by
higher-layer protocols.The Media Access Control (MAC) sub layer of the
data link layer manages protocol access to the physical network medium.
The IEEE MAC specification defines MAC addresses, which allow multiple
devices to uniquely identify one another at the data link layer.
2.4.3 Data encapsulation

Data encapsulation involves three processes which includes; (i)Framing:
The framing process provides important delimiters that are used to identify
a group of bits that make up a frame. This process provides synchronization
between the transmitting and receiving nodes. (ii)Addressing: The
encapsulation process also provides for data link layer addressing. Each
Ethernet header added in the frame contains the physical address (MAC
address) that enables a frame to be delivered to a destination node.(iii) Error
detection: each Ethernet frame contains a trailer with a cyclic redundancy
check (CRC) of the frame contents. After reception of a frame, the receiving
node creates a CRC to compare to the one in the frame. If these two CRC
calculations match, the frame can be trusted to have been received without
error.
2.4.4 Physical layer

The physical layer as indicated provides a 10 Mbps physical channel through
a coaxial cable medium. Because one purpose of the layered architecture is to
insulate the data link layer from the medium-specific aspects of the channel,
the physical layer completely specifies the essential physical characteristics
of the Ethernet, such as data encoding, timing, voltage levels, and so forth.
Implementation details are left unspecified, to retain maximum flexibility
for the executor. In all cases, the criterion applied in differentiating between
critical features and execution details is guaranteed compatibility: any two
correct implementations of the physical layer specified here will be capable
of exchanging data over the coaxial cable, enabling communication between
their respective stations at the data link layer. The physical layer defined
in this specification performs two main functions generally associated
with physical channel control: (i)data encoding which includes preamble
generation removal (for synchronization) and bit encoding and decoding. (ii)
Channel access which involves bit transmission/reception, traffic signaling
on the channel and detection.
2.5 OPEN SYSTEMS INTERCONNECTIONS (ISO/

OSI REFERENCE MODEL)
There are n numbers of users who use computer network and are located over
the world. Therefore, to ensure, national and global data communication,
systems which are compatible must be developed to interconnect with each
other. ISO has developed a standard. ISO stands for International organization
of Standardization. This is called a model for OSI and is commonly
known as OSI model. The ISO-OSI model is seven-layer architecture. It

defines seven layers or levels in a complete communication system. The
representation of communication over network is comprehensible through
this OSI model. Wise how hardware and software work together. We can
understand new technologies as they are developed. Troubleshooting is
easier by separate networks. It can be used to compare basic functional
relationships on different networks. The OSI reference model has seven
layers. The principles that were applied to arrive at the seven layers can
be briefly summarized as follows: (i) A layer should be created where a
different abstraction is needed. (ii) Each layer should perform a well-defined
function. (iii) The function of each layer should be chosen with an eye toward
defining internationally standardized protocols. (iv) The layer boundaries
should be chosen to minimize the information flow across the interfaces. (v)
The number of layers should be large enough that distinct functions need not
be thrown together in the same layer out of necessity and small enough that
architecture does not become unwieldy. Advantages include; -OSI model
distinguishes well between the services, interfaces and protocols. Protocols
of OSI model are well concealed. Protocols can be exchanged with new
protocols as technology changes. It supports connection oriented services
as well as connectionless service. However, the disadvantage is that the
model was invented before the development of protocols and the fitting of
protocols is a difficult task. It is just used as a reference model.
2.5.1 Application layer protocol

It is the topmost layer. In this layer, files are also transferred to the user. Mail
services, directory services, network resource etc. are services offered by
application layer. This layer mainly holds application programs to act upon
the received and to be sent data.
2.5.2 Presentation protocol

Presentation layer takes care that the data is sent in such a way that the
receiver will understand the information (data) and will be able to use the
data. While receiving the data, presentation layer transforms the data to be
ready for the application layer. Languages (syntax) can be different of the
two communicating systems. Under this condition presentation layer plays
a role of translator. It performs data compression, data encryption, data
conversion and so forth.
2.5.3 Session protocol

Session layer manages and synchronize the conversation between two
different applications. Transfer of data from source to destination session
layer streams of data are marked and are resynchronized properly, so that
the ends of the messages are not cut prematurely, and data loss is avoided.
2.5.4 Transport layer protocol

The transport layer controls and ensures the end-to-end integrity of the data
message transmitted through the network between two devices, providing
the reliable, transparent transfer of data between two endpoints. It decides if
data transmission should be on parallel path or single path. Functions such
as multiplexing, segmenting,or splitting on the data are done by this layer.
It receives messages from the Session layer above it, converts the message
into smaller units and passes it on to the network layer. Transport layer can
be very complex, depending upon the network requirements. Transport
layer breaks the message (data) into small units so that they are handled
more efficiently by the network layer.
2.5.5 Network layer protocol

It routes the signal through different channels from one node to other. It
acts as a network controller. It manages the Subnet traffic. It decides by
which route data should take. It shares the outgoing messages into packets
and assembles the incoming packets into messages for higher levels. The
network layer provides details that enable data to be routed between devices
in an environment using multiple networks, subnetworks or both. This is
responsible for addressing messages and data, so they are sent to the correct
destination, and for decoding logical addresses and names (like a machine
name FLAME) into physical addresses. This layer is also in charge of
finding a path through the network to the destination computer.
2.5.6 Data link protocol

Data link layer synchronizes the information which is to be transmitted
over the physical layer. The main function of this layer is to make sure
data transfer is error free from one node to another, over the physical layer.
Transmitting and receiving data frames sequentially is managed by this
layer. This layer sends and expects acknowledgements for frames received
and sent respectively. Resending of non-acknowledgement received frames
is also handled by this layer. This layer establishes a logical layer between
two nodes and also manages the Frame traffic control over the network. It
signals the transmitting node to stop, when the frame buffers are full.
2.5.7 Physical layer protocol

It is the lowest layer of the OSI model. It activates, maintains, and deactivates
the physical connection. It is responsible for transmission and reception of
the unstructured raw data over network. Voltages and data rates needed for
transmission is defined in the physical layer. It translates the digital/analog
bits into electrical signal or optical signals. Data encoding is also done in
this layer.
Table 2.1: OSI Protocol Summary
Layer Description Examples

Application Protocols that are designed to meet the com- HTTP, FTP,
munication requirements of specific applica- SMTP, CORBA
tions, often defining the interface to a service. IIOP
Presentation Protocols at this level transmit data in a net- TLS security,
work representation that is independent of CORBA data
the representations used in individual com- representation
puters, which may differ. Encryption is also
performed in this layer if required.
Session At this level, reliability and adaptation mea- SIP
sures are performed, such as detection of
failures and automatic recovery.
Transport This is the lowest level at which messages TCP, UDP
(rather than packets) are handled. Messages
are addressed to communication ports at-
tached to processes. Protocols in this layer
may be connection-oriented or connection-
less.
Network Transfers data packets between computers in IP, ATM virtual
a specific network. In a WAN or an internet- circuits
work, this involves the generation of a route
passing through routers. In a single LAN, no
routing is required.
Data link Responsible for transmission of packets be- Ethernet MAC,

tween nodes that are directly connected by ATM cell
a physical link. In a WAN transmission is transfer, PPP
between pairs of routers or between routers
and hosts. In a LAN it is between any pair
of hosts.
Physical The circuits and hardware that drive the net- Ethernet base-
work. It transmits sequences of binary data band
by analogue signaling, using amplitude or signaling,
frequency modulation of electrical signals ISDN
(on cable circuits), light signals (on fiber op-
tic circuits) or other electromagnetic signals
(on radio and microwave circuits).
Source: Distributed Systems: Concepts and Design. 4th edition, Addison
Wesley
2.6 MIDDLEWARE
Constitutes a communication structure that is independent of operating
systems and the nature of transmission systems. In the OSI model which
defines the different communication levels between information systems,
middleware is located right at the top. It defines the communication protocols
between applications. This inter-application communication structure rests
on communication structures at lower levels such as network protocols
(TCP/IP, DECnet, SNA or OSI) and/or mechanisms offered by operating
systems (Daniel S., 2002).
2.6.1 Middleware using Remote Procedure Call

When a new application is designed and when it is desired to distribute it over
a number of platforms, there appears the problem of the unit of distribution.
When it is desired to decompose an application into distributable elements,
there occurs the task of defining the characteristics of these elements.
Their “size” must represent the resulting processing time in relation to the
transmission time for the request which asks for its execution. This “size”
represents the granularity level of the distributed entity. (Daniel S., 2002)
An RPC is similar to a function call. Like a function call, when an RPC is
made, the arguments are passed to the remote procedure and the caller waits
for a response to be returned. In the illustration below, the client makes a
procedure call that sends a request to the server. The client process waits
until either a reply is received, or it times out. When the request arrives at
the server, it calls a dispatch routine that performs the requested service,
and sends the reply to the client. After the RPC call is completed, the client
process continues. Threads are common in RPC-based distributed systems.
Each incoming request to a server typically spawns a new thread. A thread in
the client typically issues an RPC and then blocks (waits). When the reply is
received, the client thread resumes execution. A programmer writing RPC-
based code does three things: i. It stipulates the protocol for client-server
communication. ii. It develops the client program. iii. It develops the server
program. The communication protocol is created by stubs generated by a
protocol compiler. A stub is a routine that does not really do much other
than pronounce itself and the parameters it accepts. The stub contains just
enough code to allow it to be compiled and linked. The client and server
programs must communicate via the procedures and data types specified in
the protocol. The server side registers the procedures that may be called by
the client and receives and returns data required for processing. The client
side calls the remote procedure, passes any required data and receives the
returned data. Thus, an RPC application uses classes generated by the stub
generator to execute an RPC and wait for it to finish. The programmer needs
to supply classes on the server side that provide the logic for handling an
RPC request. RPC introduces a set of error cases that are not present in local
procedure programming. For example, a “binding error” can occur when a
server is not running when the client is started. “Version mismatches” occur
if a client was compiled against one version of a server, but the server has
now been updated to a newer version. A timeout can result from a server
crash, network problem, or a problem on a client computer. Some RPC
applications view these types of errors as unrecoverable. Fault-tolerant
systems, however, have alternate sources for critical services and fail-over
from a primary server to a backup server.
2.6.2 Interface definition languages (IDL)

An RPC mechanism can be integrated with a particular programming
language if it includes an adequate notation for defining interfaces, allowing
input and output parameters to be mapped onto the language‘s normal use
of parameters. This approach is useful when all the parts of a distributed
application can be written in the same language. It is also convenient because
it allows the programmer to use a single language, for example, Java, for local
and remote invocation. However, many existing useful services are written
in C++ and other languages. It would be beneficial to allow programs written
in a variety of languages, including Java, to access them remotely. Interface

definition languages (IDLs) are designed to allow procedures implemented
in different languages to invoke one another. An IDL provides a notation for
defining interfaces in which each of the parameters of an operation may be
described as for input or output in addition to having its type specified.
2.6.3 Middleware using message-oriented communication

An important class of middleware services is known as message-queuing
systems, or just MOM. Message-queuing systems provide extensive
support for persistent asynchronous communication. The essence of these
systems is that they offer intermediate-term storage capacity for messages,
without requiring either the sender or receiver to be active during message
transmission. Remote procedure calls and remote object invocations
contribute to hiding communication in distributed systems, that is, they
enhance access transparency. Unfortunately, neither mechanism is always
appropriate. In particular, when it cannot be assumed that the receiving
side is executing at the time a request is issued, alternative communication
services are needed. Likewise, the inherent synchronous nature of RPCs, by
which a client is blocked until its request has been processed, sometimes
needs to be replaced by something else. Many distributed systems and
applications are built directly on top of the simple message-oriented model
offered by the transport layer.
2.6.4 Middleware using service-oriented communication

The service-oriented middleware (SOM) augments DOM systems by the
concept of services. A service in this context is a number of objects and their
behavior. These objects use a defined interface to make a service available
for other systems/services. SOM defines communication protocols between
services, and provides for location- and migration-transparent access to
services, thus supporting a simple integration of services beyond platform
boundaries. One example of a SOM is Sun‘s Jini system (http://www.sun.
com/software/jini/). Architectures emerging within the field of Web services
also belong to this category.
2.7 THE TCP/IP REFERENCE MODEL

The complex tasks that are necessary for computer communication on
the Internet are regulated with the help of different hierarchically linked
protocols. Their functionality is best described with a layer model, as was

presented in the last chapter. A group of tasks is defined in each layer that
must be handled by the protocols assigned to that layer. The protocols of
any given layer must consider the neighboring layer above and below it.
The interface to the adjacent layers on the same terminal is called the service
interface. Over the service interface, a protocol provides a specific service
to a layer higher in the protocol stack and in carrying out its task can fall
back on the services of the layers below. In addition, a protocol defines a
further interface to its counterpart on a remote terminal in the form and
meaning of the information exchanged between the terminals. This interface
is therefore also called a partner interface. Communication within the layer
model proceeds in a vertical direction between neighboring layers, with
the actual data exchange only occurring on the lowest level, the physical
layer. In contrast, via the partner interface a seemingly virtual connection is
implemented over which data and control information is exchanged. In each
case only a specific protocol layer is affected. At the time of the Internet’s
development the focus was on making seamless communication possible
over a multiple number of network architectures. Based on both of the
primary IPs: TheIP and the TCP, the resulting architecture was designated the
TCP-IP reference model. The actual TCP/IP reference model encompasses
four layers (layers 2–5) as shown in figure. Those together with the addition
of the physical layer (layer 1) make up the five-layer hybrid. The link layer
of the TCP/IP reference model corresponds to the first two layers of the
ISO/OSI reference model (physical layer and data link layer). Its main task
focuses on the secure transmission of data packets of pooled bit sequences.
It is followed by the Internet layer, which corresponds to the network layer
of the ISO/OSI reference model. Its main responsibility is to enable the data
communication of two end systems at a given location in the heterogeneous
communication network. The transport layer above it corresponds to the
layer of the same name in the ISO/OSI reference model. It enables two user
programs on different computers in the communication network to exchange
reliable and connection-oriented data. The application layer of the TCP/IP
reference model includes the three upper layers of the ISO/OSI reference
model and serves as an interface for the actual application programs that
wish to communicate with each other over the network. The ISO/OSI
protocols, on the other hand, were planned theoretically and adopted before
protocols could be invented that implemented the different function for the
layers of the ISO/OSI reference model. Today these protocols are no longer
used and the TCP/IP reference model protocols, which had been developed
from practical application, dominate the Internet. The figure below shows a
representation of the layered components of TCP/IP model.
Figure 2.7: TCP/IP Model. Source: http://www.pearsonitcertification.com/ar-

ticles/article.aspx? p=1804869
2.7.1 The link layer

The link layer is the lowest layer of the TCP/IP model; it is also referred
to in some texts as the network interface layer. The link layer combines
the physical and data link layer functions into a single layer. This includes
frame physical network functions like modulation, line coding and bit
synchronization, frame synchronization and error detection, and LLC
and MAC sublayer functions. Common protocols include the Address
Resolution Protocol, Neighbor Discovery Protocol (NDP), IEEE 802.3, and
IEEE 802.11.
2.7.2 The internet layer

The Internet layer is the next layer up from the link layer and is associated
with the network layer of the OSI model. Functions include traffic routing,
traffic control, fragmentation, and logical addressing. Common protocols
include IP, ICMP, and IGMP.
2.7.3 The transport layer

The Transport layer is the next layer and is typically related directly
with the same named layer in the OSI model. Functions include message
segmentation, acknowledgement, traffic control, session multiplexing,
error detection and correction (resends), and message reordering. Common
protocols include the Transport Control Protocol (TCP) and User Datagram
Protocol (UDP).
2.7.4 The application layer

The Application layer is the highest layer in the TCP/IP model and is
related to the session, presentation and application layers of the OSI model.
The application layer of the TCP/IP model is used to handle all process-
to-process communication functions; these functions were carried out by
multiple different layers when referencing the OSI model. There are a
number of different functions which are carried out by this layer, including
session establishment, maintenance and termination, character code
translations, data conversion, compression and encryption, remote access,
network management and electronic messaging to name a few. Common
protocols include Named Pipes, NetBIOS, MIME, TLS, SSL, FTP, DNS,
HTTP, SMTP, and many others.
2.8 INTERPROCESS COMMUNICATION

Inter Process communication (IPC) allows bidirectional communication
between clients and servers using distributed applications. IPC is a mechanism
used by programs and multi-user processes. IPCs allow concomitantly
running tasks to communicate between themselves on a local computer or
between the local computer and a remote computer. IPC mechanisms are
used to support distributed processing. Applications that split processing
between networked computers are called distributed applications. The split
portions of a distributed application can be located on the same machine
or on separate machines. A client/server application uses distributed
processing, in which processing is shared between a workstation (the client)
and a more powerful server. The client portion is sometimes referred to as
the front end and the server portion is referred to as the back end. The client
portion of a client/server application can consist of just the user interface to
the application. However, the application can be split at various places in the
distributed application. It runs on the client workstation and takes a lesser
amount of processing power. For example, the client portion might control
only screen graphics, mouse movements, and keystrokes.
2.8.1 The API for the Internet protocols

The characteristics of intercrosses communication: Message passing
between a pair of processes can be supported by two message communication
operations, send and receive, defined in terms of destinations and messages.
To communicate, one process sends a message (a sequence of bytes) to a
destination and another process at the destination receives the message. This
activity involves the communication of data from the sending process to the
receiving process and may involve the synchronization of the two processes.
2.8.2 Sockets
Sockets are a dominant abstraction that programmers use for writing
synchronous and asynchronous communication. Both forms of
communication (UDP and TCP) use the socket abstraction, which provides
an endpoint for communication between processes. Sockets originate from
BSD UNIX but are also present in most other versions of UNIX, including
Linux as well as Windows and the Macintosh OS. IPC consists of transmitting
a message between a socket in one process and a socket in another process.
Coulouris G. et al. showed this as follows;
importjava.net.*;
importjava.io.*;
publicclassUDPClient {
publicstaticvoidmain (Stringargs []){
//argsgivemessagecontentsandserverhostname
DatagramSocketaSocket= null;
try {
aSocket= newDatagramSocket ();
byte [] m=args [0].getBytes ();
InetAddressaHost= InetAddress.getByName (args [1]);
intserverPort= 6789;
DatagramPacketrequest=
newDatagramPacket (m, m.length (), aHost, serverPort);
aSocket.send (request);
byte [] buffer=newbyte [1000];
DatagramPacketreply=newDatagramPacket (buffer, buffer.length);
aSocket.receive (reply);
System.out.println (“Reply:” + newString (reply.getData ()));
} catch (SocketExceptione){System.out.println (“Socket:”+e.getMessage
());
} catch (IOExceptione){System.out.println (“IO:”+e.getMessage ());

} finally {if (aSocket!=null) aSocket.close ();}
}
}
Coulouris et al. (2012)
2.8.3 External data Representation and Marshaling

External data representation is an agreed standard for the representation of
data structures and primitive values. There are three alternative approaches
to external data representation and marshaling. They are briefly discussed
as follows: (1) CORBA‘s common data representation, which is concerned
with an external representation for the structured and primitive types that
can be passed as the arguments and results of remote method invocations in
CORBA. It can be used by a variety of programming languages. (2) Java’s
object serialization, which is concerned with the flattening and external data
representation of any single object or tree of objects that may need to be
transmitted in a message or stored on a disk. It is for use only by Java.
(3) XML (Extensible Markup Language), which defines a textual format
for representing structured data. It was originally intended for documents
containing textual self-describing structured data—e.g., documents
accessible on the Web—but it is now also used to represent the data sent in
messages exchanged by clients and servers in web services. “Marshaling is
the process of taking a collection of data items and assembling them into a
form suitable for transmission in a message. Unmarshaling is the process
of disassembling them on arrival to produce an equivalent collection of
data items at the destination. Thus, marshaling consists of the translation of
structured data items and primitive values into an external data representation.
“Similarly, unmarshaling consists of the generation of primitive values from
their external data representation and the rebuilding of the data structures”
(Coulouris et al., 2012). It is beneficial to have a generic mechanism for
distributed mutual exclusion at our disposal—one that is autonomous;i.e.,
it must not depend on particular resource management scheme in question.
REFERENCES
1. Coulouris, G., Dollimore, J., & Kindberg, T. (2005).Distributed
systems: concepts and design(4th ed.). Addison Wesley.Retrieved
January 10, 2018,from http://www.gecg.in/papers/ds5thedn.pdf
2. Hinden , R., & Deering, S. (2003 April). Internet Protocol Version 6
(IPv6) Addressing Architecture. RFC 3513, Nokia, Cisco Systems.
3. Tanenbaum, A., & Steen, M. (2002). Distributed systems: principles
and paradigms. Prentice Hall. Retrieved January 15, 2018, from http://
barbie.uta.edu/~jli/Resources/MapReduce&Hadoop/Distributed%20
Systems%20Principles%20and%20Paradigms.pdf
CHAPTER 3
TIME AND GLOBAL STATES
“There is no special physical clock in the universe to which we can appeal

when we want to measure intervals of time.”
-George Coulouris
CONTENTS
3.1 Clocks and Concepts of Time................................................................................... 54
3.2 Timing Problem....................................................................................................... 55
3.3 Physical Clocks........................................................................................................ 55
3.4 Logical Clocks......................................................................................................... 61
3.5 Events Ordering Synchronization............................................................................. 65
3.6 Global States........................................................................................................... 68
3.7 Distributed Debugging............................................................................................ 69
References..................................................................................................................... 73
A distributed system is characterized by multiple processes that are spatially

separated and are running independently. As processes run, they change
their states by executing events. Processes communicate with each other
by exchanging messages over a set of communication channels. However,
message delays are arbitrary and may be unbounded. Two inherent
limitations of distributed systems are: lack of global clock and lack of shared
memory. These have two important implications. This chapter discusses
about these issues in detail. It also explains the importance and issues of
proper time ordering for distributed systems and the two algorithms for the
synchronization of physical clocks in distributed systems with respect to
external time source.
3.1 CLOCKS AND CONCEPTS OF TIME

Time is an important and interesting issue in the distribution system for
many reasons. First, time is the quantity we want to measure accurately. To
understand the time of day that a particular event happened on a computer,
you must synchronize your watch with a legitimate external source.
Secondly, algorithms based on clock synchronization were fashioned for
prevailing problems. These include maintaining distributed data validation
of requests sent to the server and removing the identical update process.
In the central system, there is no need to synchronize the clock, as there
is typically only one clock. This process takes time by simply invoking a
system call to the kernel. When another process tries to get time, it will get
a higher price. So, in such a system, there is a precise order of events and no
uncertainty about when these events occur. The distribution system does not
have a global clock or shared memory. Each brain has its own internal clock
and its notion of time. In practice, these clocks can be easily separated by a
few seconds a day, accumulating many errors over a period of time. Also,
because different watches respond to different prices, they may not be synced
even though they can sync at startup. This clearly generates serious issues
for applications that rely on synchronized concepts of time. The distribution
system is in the wrong time because some processes may lack an overview.
Due to the uncertainty of the delay time of the message, the synchronization
process is absolutely not known for such a system. As Lamport notes, the
concept of time is important to our thinking. In fact, in real time, they help
solve many problems in the real world of decentralization. Time is also an
expedient idea when considering the relationship between cause and effect.
Time and Global States 55
3.2 TIMING PROBLEM

It is important to determine the order in which the event occurs; this is
the basic standard for operating system integrity and access networking,
extensive audit, problem solving, and medical care. The right source
of timing plays an important role in tracking and debugging on different
platforms on the web. Events should be linked to each other, regardless of
where they are created. In addition, the concept of time (or interval) is used
in many forms of management, access, authentication, and encryption. In
some cases, these controls can be skipped or stopped if source of time can be
used. For example, a payroll function could be tricked into providing access
over a weekend when it would be limited to normal working hours.
3.3 PHYSICAL CLOCKS

Today, most computers are built to track time using a Complementary Metal
Oxide Semiconductor clock circuit which is powered by a battery and a quartz
resonator. This enables the time tracking function to take place even when
the machine is completely shut-down. When it is on, an operating system
will usually program a timer circuit (a Programmable Interval Timer, or PIT,
in earlier Intel designs and Advanced Programmable Interrupt Controller,
or APIC, in newer designs) to produce an interrupt at intervals (common
times are 60 or 100 times per second). The interrupt service process simply
adds one to a counter in memory. While the best quartz resonators can attain
a precision of one second in ten years, they are sensitive to factors such
as acceleration, temperature change and change in resonating frequency
as they age. Standard resonators are accurate to 6 parts per million at 31
Â°C, which tallies with Â±Â½ second per day. The problem with sustaining
a concept of time is when multiple units presume that they both have the
same idea of what the time is. There is barely an agreement of time between
two watches. Computers usually have the same issue: a quartz crystal on
a computer will oscillate at a slightly different frequency than on another
computer. The effect of this is that clocks will tick at different rates. The
phenomenon creates a wide gap in apparent time and it is known as clock
drift. The variance between two clocks at any point in time is called clock
skew and is as a result of both clock drift and the probability that the clocks
may have been set in a different way on separate machines.
Figure 3.1: Computation of mean solar day by Physical clock. Source: http://
www.myshared.ru/slide/1234782/
3.3.1 Compensating for drift

By plotting a graph with xy coordinates where true Coordinated Universal
Time (UTC) corresponds to x-axis while the computer’s clock reading
corresponds to y-axis. An exact or accurate clock will display a slope of
one. A faster clock will form a slope greater than unity while a slower clock
will form a slope less than unity. Suppose that we have a means of obtaining
the true time. One easy (and frequently adopted) solution is to simply update
the system time to the true time. To complicate matters, one constraint that
we will impose is that it is not a good idea to set the clock back. The illusion
of time moving backwards can complicate message ordering and software
development environments. If a clock is fast, it simply has to be made to
run slower until it synchronizes. If a clock is slow, the same method can
be applied, and the clock can be made to run faster until it synchronizes.
The operating system can do this by modifying the rate at which it requests
interrupts. For example, suppose the system requests interrupt every 17
milliseconds (pseudo-milliseconds)—which in real sense is the meaning
that the computer gives to a millisecond—and the clock runs a bit too
slowly, the system can request interrupts at a faster rate, say every 16 or 15
milliseconds, until the clock catches up. This regulation changes the slope
of the system time and is known as a linear compensating Function. After
the synchronization period is reached, one can choose to resynchronize
intermittently and/or keep track of these adjustments and apply them
continually to get a better running clock. This is equivalent to noticing that
your watch loses a minute every two months and making a mental note to
adjust the clock by that amount every two months (except the system does
it recurrently).
3.3.2 Universal Coordinate Time

The output of the atomic clocks is called International Atomic Time. UTC is an
international standard based on atomic time, with an occasional leap second
added or deleted. UTC signals are synchronized and broadcast regularly by
various radio stations (e.g., WWV in the US) and satellites (e.g., GEOS,
GPS). It has propagation delay due to speed of light, distance from broadcast
source, atmospheric conditions, and so forth and it’s received value is only
accurate to 0.1–10 milliseconds. Unfortunately, most workstations and PCs
don’t have UTC receivers. International Atomic Time is based on very
accurate physical clocks (drift rate 10–13). It is based on atomic time but is
rarely adjusted to astronomical time. It is transmission from radio stations
on land and satellite (e.g., GPS). Computers with receivers can synchronize
their clocks with these timing signals.
3.3.3 Synchronizing Physical Clocks

With physical clocks, our interest is not in advancing them just to ensure
proper message ordering, but to have the system clock keep good time. We
looked at techniques for adjusting the clock to compensate for skew and
drift, but it is important that we get the time first so that we would know what
to adjust. One possibility is to attach a Global Positioning System (GPS)
receiver to each computer. A GPS receiver will provide time within Â± 1
msec. of UTC time but unfortunately, they rarely work indoors. Alternatively,
if the machine is in the US., one can attach a WWV radio receiver to obtain
time broadcasts from Texas, Colorado or Washington, DC, giving accuracies
of Â± 3-10 msec. depending on the distance from the source. Another option
is to obtain a Geostationary Operational Environment Satellites receiver,
which will provide time within Â± 0.1 msec. of UTC time. For reasons of
economy, convenience, and reception, these are not practical solutions for
every machine. Most machines will set their time by asking another machine
for the time (preferably one with one of the aforementioned time sources).
A machine that provides this information is called a time server. Several
algorithms have been proposed for synchronizing clocks and they all have
the same underlying model of the system.
3.3.4 Cristian’s Algorithm

The simplest algorithm for setting the time would be to simply issue a remote
procedure call to a time server and obtain the time. That does not account
for the network and processing delay. We can attempt to compensate for this
by measuring the time (in local system time) at which the request is sent
(T0) and the time at which the response is received (T1). Our best guess
at the network delay in each direction is to assume that the delays to and
from are symmetric (we have no reason to believe otherwise). The estimated
overhead due to the network delay is then (T1- T0)/2. The new time can be
set to the time returned by the server plus the time that elapsed as the server
generated the timestamp: Suppose that we know the smallest time interval
that it could take for a message to be sent between a client and server (either
direction). Let’s call this time Tmin. This is the time when the network
and CPUs are completely unloaded. Knowing this value allows us to place
bounds on the accuracy of the result obtained from the server. If we sent a
request to the server at time T0, then the most primitive time stamp that the
server could generate the timestamp is T0 + Tmin. The latest time that the
server could generate the timestamp is T1 - Tmin, where we assume it took
only the minimum time, Tmin, to get the response. The range of these times
is: T1 - T0 - 2Tmin, so the accuracy of the result is:Errors are cumulative. If
machine A synchronizes from a server B and gets an accuracy of Â±5 ms but
server B in turn got its time from server C with an accuracy of Â±7 msec,
the net accuracy at machine A is Â±(5+7), or Â±12 msec. Several time
requests may be issued consecutively in the hope that one of the requests
may be delivered faster than the others (e.g., it may be submitted during a
time window when network activity is minimal). This can achieve improved
accuracy. Cristian’s algorithm suffers from the problem that afflicts all
single-server algorithms: the server might fail, and clock synchronization
will be unavailable. It is also subject to malicious interference.
3.3.5 Network time protocol

Network Time Protocol (NTP) systems can operate as a principal server,
secondary server, or client. The primary server derives its time directly from
a UTC reference clock like GPS or Galileo receiver. The NTP protocol can
be implemented in three variants which are Client/Server Variant, Symmetric
Variant and Broadcast Variant. NTP is organized as a tiered structure of
servers to which the clients are connected. The server’s level in the hierarchy
is given by the stratum number. In NTP networks, the synchronization mean
errors are relative to the server stratum number. For this reason, the NTP
topology should minimize the synchronization distance between servers
and between servers and clients, although loops should be avoided. NTP
servers are arranged into strata. The first stratum contains the primary
servers, which are computers that are connected directly to an accurate time
source (the time source hardware itself is considered to be at stratum 0).
The second stratum contains the secondary servers. These are machines that
synchronized from the main stratum machines. The third stratum contains
tertiary servers that synchronized from the secondary stratum machines
and so on. Together, all these servers form the synchronization subnet. A
computer will often try to synchronize with several servers, using the best
of all the results to set its time. The best result is a function of a number
of qualities, including: round-trip delay, consistency of the delay, round-
trip error, server’s stratum, the accuracy of the server’s clock, the last time
the server’s clock was synchronized, and the estimated drift on the server.
The Simple NTP (SNTP) is a subset of the NTP that allows operation in
a stateless remote procedure call mode or multicast mode. It is not a new
protocol but just a subset of NTP. It is intended for environments when the
full NTP implementation is not needed or is not justified. The intention is
that SNTP be used at the ends of the synchronization subnet (high strata)
rather than for synchronizing time servers. SNTP can operate in either a
unicast, multicast, or anycast modes: 1.
Figure 3.2: An illustration of NTP Server configuration.

Source: http://documentation.primexwireless.com/SNS/Content/AMP/
Time_Servers/About_Time_Servers.htm
In unicast mode, a client sends a request to a designated server. 2. In multicast

mode, a server periodically sends a broadcast or multicast message and
expects no requests from clients. This matches NTP’s multicast mode and
suffers from the same problem: there is no ability to estimate the delay. 3.
In anycast mode, a client sends a request to a local broadcast or multicast
address and takes the first response received by responding servers. From
then on, the protocol proceeds as in unicast mode.
3.3.6 Berkeley Algorithm

Gusella and Zatti developed the Berkeley algorithm. It is form of an internal
synchronization that does not assume that any machine has an accurate time
source with which to synchronize. Instead, it opts for obtaining an average
time from the participating computers and synchronizing all machines to
that average. The machines involved in the synchronization each run a time
daemon process that is responsible for implementing the protocol. One of
these machines is elected (or designated) to be the master. The others are
slaves. The server polls each machine periodically, asking it for the time.
The time at each machine may be estimated by using Cristian’s method to
account for network delays. When all the results are in, the master computes
the average time (including its own time in the calculation). The hope is
that the average cancels out the individual clock’s tendencies to run fast
or slow. Instead of sending the updated time back to the slaves, which
would introduce further uncertainty due to network delays, it sends each
machine the offset by which its clock needs adjustment. The operation of
this algorithm is expressed thus; three machines have times of 3:00, 3:25,
and 2:50. The machine with the time of 3:00 is the server (master). It sends
out a synchronization query to the other machines in the group.Each of these
machines sends a timestamp as a response to the query. The server now
averages the three timestamps: the two it received and its own, computing
(3:00+3:25+2:50)/3 = 3:05. Now it sends an offset to each machine so that
the machine’s time will be synchronized to the average once the offset is
applied. The machine with a time of 3:25 gets sent an offset of -0:20 and
the machine with a time of 2:50 gets an offset of +0:15. The server has to
adjust its own time by +0:05. The algorithm also has provisions to ignore
readings from clocks whose skew is too great. The master may compute a
fault-tolerant average—averaging values from machines whose clocks have
not drifted by more than a certain amount. If the master machine fails, any
other slave could be elected to take over (1989).
3.4 LOGICAL CLOCKS

Let us again study cases that involve allocating sequence numbers
(timestamps) to events upon which all cooperating processes can agree.
What matters in these cases is not the time of day at which the event occurred
but that all processes can reach a decision on the order in which related
events occur. Our interest is in getting event sequence numbers that make
sense system-wide. If we can do this across all events in the system, we have
something called total ordering: every event is assigned a unique timestamp
(number), every such timestamp is unique. However, we do notalways need
total ordering. If processes do not interact then we don’t care when their
events occur. If we only care about allocating timestamps to related (causal)
events, then we have something known as partial ordering.Leslie Lamport
developed a “happened before” notation to express the relationship between
events: aâ†’b means that a happened before b. If a represents the timestamp
of a message sent and b is the timestamp of that message being received,
then aâ†’b must be true; a message cannot be received before it is sent.
This relationship is transitive. If aâ†’b and bâ†’c then aâ†’c. If a and b are
events that take place in the same process the aâ†’b is true if a occurs before
b. The importance of measuring logical time is in assigning a time value
to each event such that everyone will agree on the final order of events.
Each event is assigned a timestamp by its respective process. The process
simply maintains a global counter that is incremented before each event gets
a timestamp. If we examine the timestamps from our global perspective,
we can observe a number of peculiarities. Event g, the event representing
the receipt of the message sent by event a, has the exact same timestamp as
event a when it clearly had to take place after event a. Event e has an earlier
time stamp (1) than the event that sent the message (b, with a timestamp of
2) (1978).
3.4.1 Lamport’s timestamps

Lamport proposed an algorithm that forces the resequencing of timestamps
to ensure that the happened before relationship is properly depicted for
events related to sending and receiving messages. It works as follows: Each
process has a clock, which can be a simple counter that is incremented
for each event. The sending of a message is an event and each message
carries with it a timestamp obtained from the current value of the clock
at that process (sequence number). The arrival of a message at a process
is also an event will also receive a timestamp - by the receiving process,
of course. The process’ clock is incremented prior to time stamping the

event, as it would be for any other event. If the clock value is less than the
timestamp in the received message, the system’s clock is adjusted to the
(message’s timestamp + 1). Otherwise nothing is done. The event is now
time stamped. If we apply this algorithm to the same sequence of messages,
we can see that correct message ordering among causally related events is
now conserved. Note that between every two events, the clock must tick at
least once. Lamport’s algorithm allows us to maintain proper time ordering
among causally- related events. In summary, Lamport’s algorithm requires
a monotonically increasing software counter for a “clock” that has to be
incremented at least when events that need to be time stamped take place.
These events will have the clock value, or “Lamport timestamp,” associated
with them. Lamport timestamps assure us that if there is a causal relationship
between two events, then the earlier event will have a smaller time stamp
than the later event. Causality is achieved by successive events on one
process or by the sending and receipt of messages on different processes. As
defined by the happened-before relationship, causality is transitive.
Figure 3.3: Lamport Clock Assignments. Source: https://www.cs.rutgers.

edu/~pxk/rutgers/notes/clocks/index.html
3.4.2 Implementing logical clocks

To implement logical clocks, each process p, maintains data structures that
give it the following two capabilities: i. A logical clock, denoted by C, that
helps P, measure its own progress; and ii. A global logical clock denoted by
gC, that represents Ps local view of the global logical time. A protocol is
presented to update the data structures; the protocol ensures that a process’s
logical clock and its view of the global time are consistent. The protocol
comprises the following two rules: R1—maintains how a process updates
the local logical clock when it executes an Event, whether send or receive.
R2—maintains how a process updates its global logical clock to update its
view of the Global time. It dictates what information about the logical time
a process sponge off of in a message and how the receiving process uses
this information to update its view of the global time. A distributed system
consisting of logical clocks differ in their representation of logical time and
in the protocol for updating logical clocks. However, all systems consisting
of logical clocks implements some form of R1 and R2 and thereby achieving
the fundamental monotonicity property associated with events and casualty.
3.4.3 Partial Ordering of Events

The relation “---->” on the set of events of a system is the smallest relation
satisfying the following three conditions: 1. If a and b are events in the same
process, and a comes before b, then a ~ b. 2. If a is the sending of a message
by one process and b is the receipt of the same message by another process,
then a ~ b. 3. If a ~ b and b ~ c then a ---* c. Two distinct events a and b are
said to be concurrent if a ~ b and b -/-* a. We assume that a ~ a for any event
a. (Systems in which an event can happen before itself do not seem to be
physically meaningful.) This implies that ~ is an irreflexive partial ordering
on the set of all events in the system. “Another way of viewing the definition
is to say that a → b means that it is possible for event a to causally affect
event b” (Lamport, 1978).”
3.4.4 Total ordering of events

Note that it is very possible for multiple non-causal (concurrent) events to
share identical Lamport timestamps. This may cause confusion if multiple
processes need to decide based on the timestamps of two events.The
selection of a specific event may not matter if the events are concurrent,
but we want all the processes to be able to make the same decision. This is
difficult if the timestamps are identical. Fortunately, there’s an easy remedy.
We can create a total order on events by further qualifying them with

identities of processes. We define a global logical timestamp (Ti, i) where
Ti represents the local Lamport timestamp and i represents the process ID
(in some globally unique way: for example, a concatenation of host address
and process ID). We are then able to globally compare these timestamps
and conclude that there is no physical significance to the order as process
identifiers can be arbitrary and do not relate to event ordering but the ability
to ensure that no two Lamport timestamps are the same globally is helpful
in algorithms that need to compare these timestamps. In real life, depending
on the application, one may use a combination of thread ID, process ID, and
IP address as a qualifier to the timestamp.
3.4.5 Vector clocks

If two events are causally related and event e happened before event e’ then
we know that L (e) < L (e’). However, the converse is not necessarily
true. If we look at Lamport timestamps, we cannot conclude which pairs
of events are causally related and which are not. One solution that has
been proposed to deal with this problem is the concept of vector clocks.
A vector clock in a system of N processes is a vector of N integers. Each
process maintains its own vector clock (Vi for a process Pi) to timestamp
local events. Like Lamport timestamps, vector timestamps (the vector of
N integers) are sent with each message. The vector is initialized to 0 at all
processes. Before a process Pi timestamps an event, it increases its element
of the vector in its local vector. A message is sent from process Pi with Vi
attached to the message. When a process Pj receives a vector timestamp t, it
compares the two vectors element by element, setting its local vector clock
to the higher of the two values. The shortcoming of vector clocks is the bulk
storage and message payload sizeas an entire vector rather than a single
integer must be manipulated. Lamport’s algorithm, the happened before
relation tends to impose a partial order on events that reflect the passage of
messages between them which allow us to maintain proper time ordering
among causally-related events, Vector clocks have been introduced as an
improvement on Lamport clocks reason being because by examining the
timestamps, it is possible to determine whether two events are concurrent or
are ordered by the happened before relation.
Figure 3.4: Vector Clock Assignments. Source: https://www.cs.rutgers.

edu/~pxk/rutgers/notes/clocks/index.html
3.5 EVENTS ORDERING SYNCHRONIZATION

We can use a system of clocks satisfying the Clock Condition to place a total
ordering on the set of all system events. We simply order the events by the
times at which they occur. To break ties, we use any arbitrary total ordering
< of the processes. More precisely, we define a relation ~ as follows: if a
is an event in process Pi and b is an event in process Pj, then a ~ b if and
only if either (i) Ci {a) < Cj (b) or (ii) El (a) ----"Cj (b) and Pi < Py. It is
easy to see that this defines a total ordering, and that the Clock Condition
implies that if a ----> b then a ~ b. In other words, the relation ~ is a way
of completing the “happened before” partial ordering to a total ordering, a.
The ordering ~ depends upon the system of clocks Cz, and is not unique.
Different choices of clocks which satisfy the Clock Condition yield different
relations ~. Given any total ordering relation ~ which extends --->, there
is a system of clocks satisfying the Clock Condition which yields that
relation. It is only the partial ordering which is uniquely determined by the
system of events. Being able to totally order the events can be very useful
in implementing a distributed system. In fact, the reason for implementing
a correct system of logical clocks is to obtain such a total ordering. We will
illustrate the use of this total ordering of events by solving the following
version of the mutual exclusion problem. Consider a system composed
of a fixed collection of processes which share a single resource. Only one
process can use the resource at a time, so the processes must synchronize
themselves to avoid conflict. We wish to find an algorithm for granting the

resource to a process which satisfies the following three conditions: (i) A
process which has been granted the resource must release it before it can be
granted to another process. (ii) Different requests for the resource must be
granted in the order in which they are made. (iii) If every process which is
granted the resource eventually releases it, then every request is eventually
granted. We can create a total order on events by further qualifying them with
identities of processes. We define a global logical timestamp (Ti, i) where
Ti represents the local Lamport timestamp and i represents the process ID
(in some globally unique way: for example, a concatenation of host address
and process ID). There is no physical significance to the order as process
identifiers can be arbitrary and do not relate to event ordering but the ability
to ensure that no two Lamport timestamps are the same globally is helpful
in algorithms that need to compare these timestamps. In real life, depending
on the application, one may use a combination of thread ID, process ID, and
IP address as a qualifier to the timestamp.
3.5.1 Synchronous Systems

In the synchronization model, the processor is executed in a key step.
Operations are divided into phases so that each processor can send a message
to each neighbor, are sent, and each process calculates based on the message
received recently. This model is very easy to set up algorithms. The algorithms
created in this template can in many cases be simulated automatically to
work in a more realistic synchronization pattern. In the synchronization
model, we say that an execution is admissible if it is boundless. From round
structure, then it follows that each processor takes each calculation steps
and each message is transmitted. Hence in a synchronous system with no
failures, once a (deterministic) algorithm has been fixed, the only relevant
aspect determining an execution that can change is the initial configuration.
On the other hand, in an asynchronous system, there can be many different
executions of the same algorithm, even with the same initial configuration
and no failures, as the interleaving of processor steps and the message
delays are not fixed. The notion of terminated states and the termination
of the algorithm is defined in the same way as in the asynchronous model.
The message complexity of an algorithm in the synchronous model is the
maximum over all admissible executions of the algorithm, of the total
number of messages sent. To measure time in a synchronous system we
simply count the number of rounds until termination. Hence the time
complexity of an algorithm in the synchronous model is the maximum
number of rounds in any admissible execution of the algorithm until the

algorithm has terminated. The term synchronous is used (in this context) to
designate a distributed system that has the following properties: i. There is
an upper bound on message delays; this consists of the time it takes to send,
transport and receive a message over some communications link. ii. Every
processor has a local clock, and there is a bounded drift rate between any
two clocks. iii. The processors themselves make progress at a minimum rate
at least.
3.5.2 Asynchronous Systems

We say that a system isasynchronousif there is no fixed upper bound on
how long it takes for a message to be delivered or how much time elapses
between consecutive steps of a processor. An obvious example of such an
asynchronous system is the Internet. In an implementation of a distributed
system there are often upper bounds on message delays and processor
step times. But as these upper bounds are often very large and can change
over time, it is often desirable to develop an algorithm that is independent
of any timing parameters, that is, an asynchronous algorithm. In the
asynchronous model, we say that an execution isadmissibleif each processor
has an infinite number of computation events, and every message sent is
eventually delivered. The first of these requirements models the fact that
processors do not fail. (It does not mean that a processor’s local program
contains an infinite loop. An algorithm can still terminate by having a
transition function not change a processors state after a certain point. We
assume that each processor’s set of states includes a subset of terminated
states. Once a processor enters such a state it remains in it. The algorithm
hasterminatedif all processors are in terminated states and no messages are
in transit. The message intricacy of an algorithm in the asynchronous model
is the maximum over all admissible executions of the algorithm, of the total
number of (point-to-point) messages sent. Atimed executionis an execution
that has a non-negative real number connected with each event, the time at
which the event occurs. To measure the time complexity of an asynchronous
algorithm we first assume that the maximum message delay in any execution
is one unit of time. Hence, the time complexity is the maximum time until
termination among all timed admissible executions in which every message
delay is at most one. Instinctively, this can be viewed as taking any execution
of the algorithm and regularizing it in such a way that the longest message
delay becomes one unit of time.
3.6 GLOBAL STATES

Often many primitive state transitions are necessary to accomplish a
larger semantically meaningful task, called a transaction. Transactions
are designed to take the system from one meaningful or consistent state
to another, but during the execution of the transaction, the system may go
through inconsistent intermediate states. Thus, to ensure consistency of the
system state, every transaction must either be run to completion or not run at
all. Transactions are often the basis for concurrency control. In a distributed
database system, a standard criterion for correctness of a system is that all
allowable “interleaving” of transactions be “serializable.” However, there
are systems which can run acceptably with unconstrained interleaving’s.
In a banking system, for example, a transfer transaction might consist of a
withdrawal step followed by a deposit step. To obtain fast performance, the
withdrawals and deposits of different transfers might be allowed to interleave
arbitrarily, even though the users of the banking system are thereby presented
with a view of the account balances which includes the possibility of money
being “in transit” from one account to another. One useful kind of transaction
is a “checkpoint”-a transaction that reads and returns all the current values
for the objects of the system. In a bank database, a checkpoint can be used
to audit all of the account balances (or the sum of all account balances). In
a population database, a checkpoint can be used to produce a census. In a
general transaction system, the checkpoint can be used for failure detection
and recovery: if a checkpoint produces an inconsistent system state, one
assumes that an error has occurred and takes appropriate recovery measures.
For a checkpoint transaction to return a meaningful result, the individual read
steps of the checkpoint must not be permitted to interleave with the steps
of the other transactions; otherwise an inconsistent state can be returned
even for a correctly operating system, and it might be quite challenging to
obtain useful information from such intermediate results. For example, in a
bank database with transfer operations, an arbitrarily interleaved audit might
completely miss counting some money in transit or count some transferred
money twice, thereby arriving at an incorrect value for the sum of all the
account balances. A checkpoint which is not allowed to interleave with
any other transactions is called a global checkpoint. In the bank database, a
global checkpoint would only see completed transfers; no money would be
overlooked in transit, and a correct sum would be obtained for all account
balances. In general, a global checkpoint views a globally consistent state
of the system.
3.7 DISTRIBUTED DEBUGGING

Distributed systems differ from single-machine programs in ways that are
simultaneously positive in providing systems with special capabilities, and
negative in presenting software-development and operational challenges.
Broadly, debugging is the process of finding and fixing errors, or in a system.
Debugging seeks to find and fix errors in both hardware and software.
Performance problems are considered bugs, so debugging can also include
performance tuning, which seeks to improve performance by removing
bottlenecks in the processing taking place within a system.
3.7.1 Heterogeneity
A distributed system’s nodes may include mobile phones, laptops, server-
class machines, and more. This hardware and software diversity in node
resources and network connectivity can make a distributed system more
robust, but this heterogeneity forces developers to manage compatibility
during both development and debugging.
3.7.2 Concurrency
Simultaneous operation by multiple nodes leads to concurrency, which
can make a distributed system outperform a centralized system. However,
concurrency may introduce race conditions and deadlocks, which are
notoriously difficult to diagnose and debug. Additionally, networks
introduce packet delay and loss, exacerbating the issues of understanding
and debugging concurrency.
3.7.3 Distributed state

Distributing system state across multiple nodes can remove a central point
of failure and improve scalability, but distributed state requires intricate
node coordination to synchronize state across nodes—for example, nodes
must ensure their local states are consistent. Potential inconsistencies are
prevented by distributed algorithms, such as those that guarantee a particular
flavor of data consistency and cache coherence. Developers may find it
difficult, or even impossible, to reconstruct the global state of the system
when it is distributed on many nodes. This complicates bug diagnosis and
validation. Here is an overview of seven methodologies designed to help
software engineers authenticate and debug distributed systems.
3.7.4 Testing
A test suite exercises a specific set of executions to ensure that they behave
properly. Most testing of distributed systems is done using manually written
tests, typically introduced in response to failures and then minimized.
Testing is an effective way to detect errors. However, as testing exercises
a limited number of executions, it can never guarantee to reveal all errors.
3.7.5 Model checking

Model checking is exhaustive testing, typically up to a certain bound
(number of messages or steps in an execution). Symbolic model checking
signifies and explores possible executions mathematically; explicit-state
model checking is more practical because it actually runs the program,
controlling its executions rather than attempting to abstract it. MoDist
performs black-box model checking, permuting message sequences and
changing the execution speed of a process relative to other processes in the
system. MaceMC is a white-box technique that achieves speedups by adding
programming-language support for model checking. Common problems of
all model-checking tools are scalability and environmental modeling, so
they rarely achieve a guarantee. Theorem proving Theorem proving can,
in principle, prove a distributed system to be free of defects. Amazon uses
TLA+ to verify its distributed systems.
3.7.6 Tracing
Tracks the flow of data through a system, even across applications and
protocols such as a database, web server, domainname server, load balancer,
or virtual private network protocol. For example, pivot tracing dynamically
instruments Java-based systems to collect user-defined metrics at different
points in the system and collates the final data to provide an inter-component
view of the metrics over multiple executions. Dapper is a lower-level tracing
system used at Google to trace infrastructure services. Tracing is more
efficient than record and replay because it focuses on a specific subset of
the data, but it requires instrumenting applications and protocols to properly
forward the tracing metadata.
3.7.7 Log analysis

Log analysis is an even lighter-weight approach that works with systems that
cannot be modified. It is a common black box approach in which a system’s
console logs, debug logs, and other log sources are used to understand the
system. For example, Xu et al. applied machine learning to logs to detect
anomalies in Google infrastructure services (2010). Detailed logs from
realistic systems contain a great deal of valuable detail, but they tend to be
so large that they are overwhelming to programmers, who as a result cannot
directly benefit from them.
3.7.8 Visualization
Threads and processes can be seen as a way to do more things at the same
time. In effect, they allow us build (pieces of) programs that appear to be
executed simultaneously. On a single-processor computer, this simultaneous
execution is, of course, an illusion. As there is only a single CPU, only an
instruction from a single thread or process will be executed at a time. By
rapidly switching between threads and processes, the illusion of parallelism
is created. This separation between having a single CPU and being able to
pretend there are more can be extended to other resources as well, leading
to what is known as resource virtualization. This virtualization has been
applied for many decades, but has received renewed interest as (distributed)
computer systems have become more commonplace and complex, leading
to the situation that application software is mostly always outliving its
underlying systems software and hardware. In this section, we pay some
attention to the role of virtualization and discuss how it can be realized. The
complexity of distributed systems has inspired the system to make them
more transparent to the developers. One of the most important reasons for the
introduction of virtual technology in the 1970s is to allow the old software
to run expensive hardware on mainframe. The program not only integrates
different applications, but really the operating system they have created.
This approach to preserving hereditary programs has been successfully
applied to the mainframe of IBM 370 (and their successor), which offers
virtual machines that multiple operating systems are transferred. As the
hardware has become cheaper, the PC has become more powerful and the
number of different operating systems has decreased, the virtual becomes
less of a problem. But many issues have changed again since the late 1990s,
with many reasons we will be debating for the first time, while the low-
end hardware and software systems are changing rapidly, with high-end
applications (such as middleware and applications) stabilized. In other
words, we face situations where the legacy program cannot be saved at
the same pace as the platform it is based on. Virtualization can help here
by transferring legacy interfaces to new platforms and thus opening it
immediately to existing classes. It is important to understand the fact that

the network becomes fully responsive. It is hard to imagine that modern
computers are not connected to a network. In the implementation of this link,
administrators require system administrators to maintain a large collection
and a variety of server computers that have very different applications that
can be accessed by customers. At the same time, other resources must be
easy for these applications. Virtualization can help a great deal: Platform
and machine differences can be reduced by allowing each application to
run on its own virtual machine, including libraries related to the operating
system that will work on a general platform. This latest virtualization
provides a high level of transmission and flexibility. For example, to realize
content delivery networks that can easily support replication of dynamic
content, Awadallah and Rosenblum argue that management becomes much
easier if edge servers would support virtualization, allowing a complete
site, including its environment to be dynamically copied. As we will discuss
later, it is primarily such portability arguments that make virtualization an
important mechanism for distributed systems (2002).
REFERENCES
1. Distributed systems: principles and paradigms, Physical and logical
clocks (2010).
2. Gusella, R., & Zatti, S. (1989).The accuracy of the clock synchronization
achieved by TEMPO in Berkeley UNIX 4.3BSD.Software Engineering,
IEEE Transactions on, IEEE,15(7), 847-853.
3. Leslie, L. (1978 July). Time, clocks, and the ordering of events in a
distributed system. Communications of the ACM,21(7), 558-565.
4. Sinha, P. (2009). Distributed operating systems: concepts and design
(pp. 282-336). PHI Learning Private Limited.
5. Xu, W., Huang, L., Fox, A., Patterson, D., & Jordan, M. (2010).
Experience mining Google’s production console logs. Proceedings of
the Workshop on Managing Systems via Log Analysis and Machine
Learning Techniques. Retrieved January 15, 2018, from http://iiis.
tsinghua.edu.cn/~weixu/files/slaml10.pdf
CHAPTER 4
COORDINATION
“The theories of computation are evolving from notions like value, evalua-
tion and function to those of link, interaction, and process.”
-Robin Milner
CONTENTS
4.1 Distributed Mutual Exclusion................................................................................... 76
4.2 Multicast Communication....................................................................................... 85
4.3 Group Communication............................................................................................ 86
4.4 Failure..................................................................................................................... 87
4.5 Elections.................................................................................................................. 91
References..................................................................................................................... 94
Big companies such as Google or Facebook have millions of users; therefore,

they need to respond to millions of requests per second. More essentially,
they have to make sure that their service does not go down at least for a
second. In simple terms, availability is the major concern in these use cases.
So, distributed systems are the solution for high availability. Instead of
keeping just one server to serve the client requests, we will use a cluster
of interconnected servers or nodes along with load balancers to serve the
requests. This chapter introduces a collection of algorithms whose goals
vary but that share an aim that is fundamental in distributed systems: for a
set of processes to coordinate their actions or to agree on one or more values
and elucidates the various algorithms and processes needed to coordinate
operations of computers in a distributed system. Failure models used in
designing the algorithms were also discussed.
4.1 DISTRIBUTED MUTUAL EXCLUSION

Mutual exclusion is a fundamental issue in the design of distributed systems
and an efficient and robust technique for mutual exclusion is essential to
the viable design of distributed systems.“Distributed processes often need
to coordinate their activities. If a collection of processes share a resource or
collection of resources, then often mutual exclusion is required to prevent
interference and ensure consistency when accessing the resources. This is
the ‘critical section’ problem, familiar in the domain of operating systems.
In a distributed system, however, neither shared variables nor facilities
supplied by a single local kernel can be used to solve it, in general. We
require a solution to ‘distributedmutual exclusion’: one that is based solely
on message passing” (George C. et. al, 2012).Distributed mutual exclusion
algorithms must deal with unpredictable message delays and incomplete
knowledge of the system state. Three elementary approaches for distributed
mutual exclusion: 1. Token-based approach 2. Non-token-based approach 3.
Quorum-based approach 1. Token-based approach: A unique token is shared
among the sites. A site is allowed to enter its CS if it possesses the token.
Mutual exclusion is ensured because the token is unique.2. Non-token based
approach: Two or more successive rounds of messages are exchanged among
the sites to determine which site will enter the CS next. 3. Quorum based
approach: Each website requests the permission to execute the CS from a
subset of sites (called a quorum). Any two quorums contain a common site.
This common site is responsible to make sure that only one request executes
the CS at any time.
Coordination 77
4.1.1 Requirements of Mutual Exclusion Algorithms

A mutual exclusion algorithm should satisfy the following properties: 1.
Safety Property: The safety property states that at any instant, only one
process can execute the critical section. This is an essential property of a
mutual exclusion algorithm. 2. Liveness Property: This property states the
absence of deadlock and starvation. Two or more sites should not endlessly
wait for messages which will never arrive. In addition, a site must not wait
indefinitely to execute the CS while other sites are repeatedly executing the
CS. That is, every requesting site should get an opportunity to execute the CS
in finite time. 3. Fairness: Fairness in the context of mutual exclusion means
that each process gets a fair chance to execute the CS. In mutual exclusion
algorithms, the fairness property generally means the CS execution requests
are executed in the order of their arrival (time is determined by a logical
clock) in the system
4.1.2 Lam-port’s algorithm

Lam-port’s mutual exclusion in distributed systems defines an algorithm
for mutual execution of a critical section. This algorithm makes sure that
no two processes enter the critical section simultaneously. The decision is
made based on the timestamps which the protocol messages and application
messages carry. The basic concept of this algorithm is that if a process wants
to enter the critical section, it sends REQUEST to all the other process in
the network and waits for their REPLY. Once it receives the replies from
all the other processes, it enters the critical section if it is at the top of the
queue else waits till it reaches the top of the queue. When a process exits
the critical section, it sends a RELEASE message to all the other processes.
When a process receives a RELEASE message, it removes the respective
REQUEST from its QUEUE, to move the next REQUEST ahead. Thus,
this condition makes sure that only one process enters the critical section
at a time. The project here has two versions. In the first version, when
successful connection is established between each node, a random number
is generated. And based on the random number, each node either sends
application messages to other nodes or broadcasts request message to other
nodes. When a node received an application message it increments its clock
value and when it receives a request message, it enters the request message
into a queue and sends corresponding reply message. On receiving the reply,
the requesting node checks if it has received all the replies, if yes then is
it at the head of the queue, if yes then the node enters critical section. The
received replies are stored in a Boolean array, which turns to false whenever
it receives a reply from the respective node. On exiting the critical section,
the node broadcasts a release message and all the processes remove the
request from their queue. In the second version, there is an optimization.
It goes like this: when a process receives a request, if it has already sent a
message with clock value greater than the request message, then it does not
send a reply message. Similarly, when a process sends a request message it
also checks if it has received any message with a timestamp higher than its
request, if yes then that message is considered as a reply and its Boolean
value is set to false. Rests of the operations are performed as it is. When a
process enters critical section, it creates a log file and writes about its entry
in critical section and also about its exit from critical section on exiting.
Figure 4.1: Lamport’s algorithm. Source: http://www.cs.fsu.edu/~xyuan/

cop5611/lecture8.html
4.1.3 Ricart-Agrawala algorithm:

The Ricart-Agrawala algorithm assumes the communication channels
are First-in, First-Out (FIFO). The algorithm uses two types of messages:
REQUEST and REPLY. A process sends a REQUEST message to all other
processes to request their permission to enter the critical section. A process
sends a REPLY message to a process to give its permission to that process.
Processes use Lamport-style logical clocks to assign a timestamp to critical
section requests. Timestamps are used to decide the priority of requests in
case of conflict—if a process pi that is waiting to execute the critical section,
receives a REQUEST message from process pj, then if the priority of pj’s
request is lower, pidefers the REPLY to pj and sends a REPLY message to
pjonly after executing the CS for its pending request. Otherwise, pi sends a
REPLY message to pj immediately, provided it is currently not executing the
CS. Thus, if several processes are requesting execution of the CS, the highest
priority request succeeds in collecting all the needed REPLY messages and
gets to execute the CS. Each process pi maintains the Request-Deferred
Coordination 79
array, RDi, the size of which is the same as the number of processes in the
system. Initially, ∀i ∀j: RDi [j]=0. Whenever pi defer the request sent by pj, it
sets RDi [j]=1 and after it has sent a REPLY message to pj, it sets RDi [j]=0.
Requesting the critical section 1. When a site Si wants to enter the CS,
it sends a timestamped REQUEST message to all the sites in its request set.
2. When site Sjreceives a REQUEST message from site Si, it sends a REPLY
message to site Si if site Sj is neither requesting nor executing the CS or if
site Sj is requesting and Si’s request’s timestamp is smaller than Sj’s own
request’s timestamp. The request is deferred otherwise.
Executing the critical section Site Sienters the CS after it has received
REPLY messages from all the sites in its request set.
Releasing the critical section i. When site Si exits the CS, it sends
REPLY messages to all the deferred requests. A site’s REPLY messages are
blocked only by sites that are requesting the CS with higher priority (i.e.,
a smaller timestamp). Thus, when a site sends out REPLY messages to all
the deferred requests, the site with the next highest priority request receives
the last needed REPLY message and enters the CS. The execution of CS
requests in this algorithm is always in the order of their timestamps.
Figure 4.2: Ricart-Agrawala Algorithm. Source: http://slideplayer.com/

slide/10747842/
4.1.4 Singhal’s Dynamic Information-Structure Algorithm

Most mutual exclusion algorithms use a static approach to invoke mutual
exclusion; i.e., they always take the same course of actions to invoke
mutual exclusion no matter what is the state of the system. A problem with
these algorithms is the lack of efficiency because these algorithms fail to
exploit the changing conditions in the system. Note that an algorithm can
exploit dynamic conditions of the system to optimize the performance. For
example, if few sites are invoking mutual exclusion very frequently and
other sites invoke mutual exclusion much less frequently, then a frequently
invoking site need not ask for the permission of less frequently invoking
site every time it requests access to the CS. It only needs to take permission
from all other frequently invoking sites. Singhal developed an adaptive
mutual exclusion algorithm based on this observation. The information-
structure of the algorithm evolves with time as sites learn about the state
of the system through messages. Dynamic information structure mutual
exclusion algorithms are attractive because they can adapt to fluctuating
system conditions to optimize the performance.
Requesting the CS
1. If the requesting site Si does not have the token, then it takes the following
actions: - a. It sets SVi [i]:=R. b. It increments SNi [i]:=SNi [i]+1. c. It
sends REQUEST (i, sn) message to all sites Sjfor which SVi [j]=R. (sn is the
updated value of SNi [i].) 2. When a site Sj receives the REQUEST (i, sn)
message, it discards the message if SNj [i]≥sn because the message is out
dated. Otherwise, it sets SNj [i] to sn and takes the following actions based
on its own state:
SVj [j]=N: Set SVj [i]:=R. SVj [j]=R: If SVj [i] R, then set SVj [i]:=R
and send a REQUEST (j, SNj [j]) message to Si (else do nothing).
SVj [j]=E: set SVj [i]:=R. SVj [j]=H: Set SVj [i]:=R, TSV [i]:=R,
TSN [i]:=sn, SVj [j]:=N, and send the token to site Si.
Executing the CS 3. Si executes the CS after it has received the token. Just
before entering the CS, Si sets SVi [i] to E
Releasing the CS 4. Having finished the execution of the CS, site Si sets SVi
[i]:=N and TSV [i]:=N, updates its local and token vectors in the following
way: For all Sj, j=1 to N do
if SNi [j] > TSN [j]

then (* update token information from local information *)
{TSV [j]:= SVi [j]; TSN [j]:= SNi [j]}
else (* update local information from token information *)
{SVi [j]:= TSV [j]; SNi [j]:= TSN [j]}
5. If (∀j: SVi [i]=N), then set SVi [i]:=H, else send the token to a site
Sjsuch that SVi [j]=R.
Coordination 81
4.1.5 Maekawa’s algorithm

Maekawa’s algorithm was the first quorum-based mutual exclusion algo-
rithm. The request sets for sites (i.e., quorums) in Maekawa’s algorithm are
constructed to satisfy the following conditions:
M1: ( "i "j : i ¹ j, 1 £ i, j £ N ￠Ri ¹ f )
M2: ( "i : 1 £ i £ N ￠ Si Î Ri )
M3: ( "i : 1 £ i £ N ￠ Ri = k )
M4: Any site is contained in number of 1 ≤ j , j ≤ N Maekawa used the
theory of projective planes and showed that N = K (K − 1) + 1. This relation
gives “Ri” = √ N (Maekawa, 1985). As there is at least one common site be-
tween the request sets of any two sites (condition M1), every pair of sites has
a common site which mediates conflicts between the pair. A site can have
only one unresolved REPLY message at any time; that is, it gives permis-
sion to an incoming request if it has not given permission to some other site.
Therefore, mutual exclusion is guaranteed. This algorithm requires delivery
of messages to be in the order they are sent between every pair of sites.
Conditions M1 and M2 are necessary for correctness; whereas conditions
M3 and M4 provide other desirable features to the algorithm. Condition M3
states that the size of the requests sets of all sites must be equal implying that
all sites should have to do equal amount of work to invoke mutual exclusion.
Condition M4 enforces that exactly the same number of sites should request
permission from any site implying that all sites have “equal responsibility”
in granting permission to other sites.
Requesting the CS 1. A site Si requests access to the CS by sending RE-
QUEST (i) messages to all the sites in its request Ri 2. When a site Sj re-
ceives the REQUEST (i) message, it sends a REPLY (j) message to Si pro-
vided it has not sent a REPLY message to a site from the time it received the
last RELEASE message. Otherwise, it queues up the REQUEST for later
consideration.
Executing the CS 3. Site Si accesses the CS only after receiving REPLY
messages from all the sites in Ri. Releasing the CS 4. After the execution
of the CS is over, site Si sends RELEASE (i) message to all the sites in Ri..
4.1.6 Agarwal-El Abbadi Quorum-based

Algorithm Agarwal and El Abbadi developed a simple and efficient mutual
exclusion algorithm by introducing tree quorums. They gave a novel algorithm
for constructing tree-structured quorums in the sense that it uses hierarchical

structure of a network. The mutual exclusion algorithm is independent of
the underlying topology of the network and there is no need for a multicast
facility in the network. However, such facility will improve the performance
of the algorithm. The mutual exclusion algorithm assumes that sites in the
distributed system can be organized into a structure such as tree, grid, binary
tree, etc. and there exists a routing mechanism to exchange messages between
different sites in the system. Agarwal-El Abbadi constructs quorums from
trees. Such quorums are called ‘tree-structured quorums’. The following
sections describe an algorithm for constructing tree-structured quorums and
present an analysis of the algorithm and a protocol for mutual exclusion in
distributed systems using tree-structured quorums. Quorum-based mutual
exclusion algorithms represented a withdrawal from the trend in the following
two ways: 1. A site does not request permission from all other sites, but
only from a subset of the sites. This is a fundamentally different approach
as compared to Lamport and Ricart-Agrawala algorithms where all sites
contribute to resolution of conflict for every other site. In quorum-based
mutual exclusion algorithm, the request set of sites are selected such that
∀i∀j: 1 ≤ i, j ≤ N: Ri∩ Rj≠Φ. As a result, every pair of sites has a site which
arbitrates conflicts between that pair. 2. In quorum-based mutual exclusion
algorithm, a site can send out only one REPLY message at any time. A site
can send a REPLY message only after it has received a RELEASE message
for the previous REPLY message. Therefore, a site Silocks all the sites in Ri
in exclusive mode before executing its CS. Quorum-based mutual exclusion
algorithms significantly reduce the message complexity of invoking mutual
exclusion by having sites ask permission from only a subset of sites.
Examples of Tree-Structured Quorums

When there is no node failure, the number of quorums formed is equal to
the number of leaf sites. -Consider the tree of height 3 (see Figure 4.3),
constructed from 15 (=23+1−1) sites. -In this case 8 quorums are formed from
8 possible root-leaf paths: 1-2-4-8, 1-2-4-9, 1-2-5-10, 1-2-5-11, 1-3-6-12,
1-3-6-13, 1-3-7-14 and 1-3-7-15. -If any site fails, the algorithm substitutes
for that site two possible paths starting from the site’s two children and
ending in leaf nodes. For example, when node 3 fails, we consider possible
paths starting from children 6 and 7 and ending at leaf nodes. The possible
paths starting from child 6 are 6-12 and 6-13, and from child 7 are 7-14 and
7-15. So, when node 3 fails, the following eight quorums can be formed:
Coordination 83
{1,6,12,7,14}, {1,6,12,7,15}, {1,6,13,7,14}, {1,6,13,7,15}, {1,2,4,8},

{1,2,4,9},{1,2,5,10}, {1,2,5,11}.
Figure 4.3: A tree organization of 15 copies of an object. Source: https://www.

slideshare.net/Tigabu/chapter9-60218661
4.1.7 Suzuki–Kasami’s broadcast algorithm

In Suzuki–Kasami’s algorithm, if a site that wants to enter the CS, does
not have the token; it broadcasts a REQUEST message for the token to all
other sites. A site which possesses the token sends it to the requesting site
upon the receipt of its REQUEST message. If a site receives a REQUEST
message when it is executing the CS, it sends the token only after it has
completed the execution of the CS. The basic idea underlying this algorithm
may sound rather simple; however, there are the following two design issues
must be efficiently addressed: 1. How to distinguish an outdated REQUEST
message from a current REQUEST message: Due to variable message
delays, a site may receive a token request message after the corresponding
request has been satisfied. If a site cannot determine if the request analogous
to a token request has been satisfied, it may dispatch the token to a site
that does not need it. This will not violate the accuracy; however, this may
seriously diminish the performance by wasting messages and increasing the
delay at sites that are genuinely demanding the token. Therefore, suitable
mechanisms should be implemented to determine if a token request message
is obsolete. 2. How to determine which site has an outstanding request for
the CS: After a site has finished the execution of the CS, it must determine
what sites have an outstanding request for the CS so that the token can be
dispatched to one of them. The problem is complicated because when a
site Si receives a token request message from a site Sj, site Sjmay have an
outstanding request for the CS. However, after the corresponding request for
the CS has been satisfied at Sj, an issue is how to inform site Si (and all other
sites) efficiently about it.
4.1.8 Raymond’s tree-based algorithm

Raymond’s tree-based mutual exclusion algorithm uses a spanning tree of
the computer network to reduce the number of messages exchanged per
critical section execution. The algorithm exchanges only O (log N) messages
under light load, and roughly four messages under heavy load to execute
the CS, where N is the number of nodes in the network. The algorithm
assumes that the underlying network guarantees message delivery. The time
or order of message arrival cannot be predicted. All nodes of the network are
completely reliable. If the network is viewed as a graph, where the nodes in
the network are the vertices of the graph, and the links between nodes are
the edges of the graph, a spanning tree of a network of N nodes will be a tree
that contains all the N nodes. A minimal spanning tree is that particular tree
with minimum cost. Normally, this cost function is based on the network
link characteristics. The algorithm operates on a minimal spanning tree of
the network topology or a logical structure imposed on the network. The
variables used in the algorithm are indicated in this section (see table below).
The algorithm is as follows;
i. If a node i wishes to receive the token to enter into its critical
section, it sends a request to its parent, node j.
- If node j FIFO is empty, node j shifts i into its FIFO queue; j
then issues a request to its parent, k, that it desires the token
- If node j FIFO queue is not empty, it simply shifts i into the
queue
ii. When node k has token and receives the request from j it sends
token to j and sets j as its parent
iii. When node j receives the token from k, it forwards the token to i
and i is removed from the queue of j
If the queue of j is not empty after forwarding the token to i, j must issue
a request to ito get the token back. Note that however, if j wishes to request
a token, and its queue is not empty, then it places itself into its own queue.
Node j will utilize the token to enter into its critical section if it is at the head
of the queue when the token is received.
Coordination 85
Table 4.1: Variables used in the Algorithm
Variable Name Possible values Comments

HOLDER “Self” or the identity of Indicates the location
one of the immediate of the privileged node
neighbors. in relation to the cur-
rent node.
USING True of false. Indicates the current
node is executing the
critical section.
REQUEST_Q A FIFO queue that could The REQUEST_Q of
contain “self” or the a node consists of the
identities of immediate identities of those im-
neighbors as elements. mediate neighbors that
have requested for the
privilege but have not
been sent the privilege.
ASKED True or false. Indicates if the node
has sent a request for
the privilege.
Source: Distributed Computing: Principles, Algorithms, and Systems
4.2 MULTICAST COMMUNICATION

In computer networking, multicast is group communication where data
transmission is addressed to a group of destination computers simultaneously.
Multicast can be one-to-many or many-to-many distribution. Multicast
should not be muddled up with physical layer point-to-multipoint
communication. Group communication may either be application layer
multicast or network assisted multicast, where the latter makes it possible
for the source to resourcefully send to the group in a single transmission.
Copies are mechanically created in other network elements, such as routers,
switches and cellular network base stations, but only to network segments
that currently contain members of the group. Network assisted multicast
may be implemented at the data link layer using one-to-many addressing
and switching such as Ethernet multicast addressing, Asynchronous
Transfer Mode (ATM), point-to-multipoint virtual circuits (P2MP) or
Infiniband multicast. Network assisted multicast may also be executed at the
Internet layer using IP multicast. In IP multicast the implementation of the
multicast concept occurs at the IP routing level, where routers create optimal
distribution paths for datagrams sent to a multicast destination address. In

basic multicast there are no ordering guarantees. Messages may be delivered
in any order. The sterner orderings can all be described and executed making
use of basic multicast to send messages to all group members. This means
that any suitable basic multicast implementation, such as IP multicast, can
be used to implement the following. FIFO (First-in, First-out) multicast
guarantees that message order is maintained per sender. This means that
messages from a single sender are always delivered in the same order as
they were sent. FIFO multicast can be implemented by giving each group
member a local send counter and a vector of the counters received from the
other group members. The send counter is incorporated with each message
sent, while the receive vector is used to delay delivery of messages until all
previous messages from a particular sender have been delivered. Multicast
is often employed in IP applications of streaming media, such as IPTV and
multipoint videoconferencing.
4.3 GROUP COMMUNICATION

Although RPC is a good abstraction for the request/reply type of
communication, there is a large body of applications that require a group
of several processes to interact closely. Group communication allows a
message to be sent reliably from 1 sender to n receivers. Many applications
can profit from such a communication primitive and many networks provide
mechanism to do broadcast or multicast at the data-link layer. One of the
difficulties in making a protocol that allows user applications to use the
data-link broadcast or multicast capability of a network is routing. A group
address has to be mapped on one or more data-link addresses, possibly on
different networks. The protocol has to make sure that messages will not
loop and that a minimum number of messages are used to transmit user
data to the group. Groups may change over time, so routing tables have
to be dynamically updated. Furthermore, to achieve good performance,
the routing protocol should use a data-link multicast address to send a
message to a number of receivers whenever possible. Recall that group
communication provides a model of communication whereby a process can
send a single message to a group of other processes. When such a message
is sent to a predefined group of recipients (as opposed to all nodes on the
network), we refer to the communication as multicast. As a multicast is sent
out to a specific group, it is important to have agreement on the membership
of that group. We distinguish between static group membership, where
Coordination 87
membership does not change at runtime, and dynamic membership, where

the group membership may change. Likewise, we distinguish between open
and closed groups. In an open group anyone can send a message to the
group, while in a closed group only group members can send messages to
the group. Besides group membership there are two other key properties
for multicast: reliability and ordering. With regards to reliability, we are
interested in message delivery guarantees in the face of failure. There are
two delivery guarantees that a reliable multicast can provide: the guarantee
that if the message is delivered to any member of the group it is guaranteed
to be delivered to all members of the group; and the slightly weaker assures
that if a message is delivered to any non-failed member of the group, it will
be delivered to all non-failed members of the group. We will further discuss
multicast reliability in a future lecture. With regards to ordering we are
interested in guarantees about the order in which messages are delivered to
group members. This requires synchronization between the group members
to ensure that everyone delivers received messages in an appropriate order.
4.4 FAILURE
Four types of failures that may occur in a distributed system are crash,
timing, omission, and byzantine failures. The failures usually fall into two
different categories, hardware and software. The following is an outline of
the four types of failures and a method to isolate and fix two of the types of
failures in a distributed system.
4.4.1 Byzantine failure

First, the failures with which we are concerned may be normal or Byzantine.
The Byzantine fault model is inspired by the idea that there are n generals
defending Byzantium, t of whom have been bribed by the Turks to cause
as much confusion as possible in the command structure. The generals
can pass oral messages by courier, and the couriers are trustworthy. Each
general can exchange confidential and authentic communications with each
other general (we can also imagine them encrypting and computing a MAC
on each message). What is the maximum number t of traitors that can be
tolerated? The key observation is that, if we have only three generals, say
Anthony, Jakes, and Andrew, and Anthony is the traitor, then he can tell
Jakes, “Let’s attack,” and Andrew “Let’s retreat.” Jakes can now say to
Andrew “Anthony says let’s attack,” but this doesn’t let Andrew conclude
that Anthony’s the traitor. It could just as easily be Jakes; Anthony could
have said “Let’s retreat” to both of them, but Jakes lied when he said,
“Anthony says let’s attack.” This scenario as defined by Leslie Lamport,
Robert Shostak, and Marshall Pease in their 1982 paper, a general must
communicate his order to attack or retreat to his lieutenants, but any number
of participants, including the general, could be a traitor. This beautiful insight
is due to Lamport, Shostack, and Peace, who prove that the problem has a
solution if and only if n≥ 3t + 1. Of course, if the generals are able to sign
their messages, then no general dare say different things to two different
colleagues. This illustrates the power of digital signatures in particular and
of end to end security mechanisms in general. Relying on third parties to
introduce principals to each other or to process transactions between them
can give great savings, but if the third parties ever become untrustworthy
then it can impose significant costs. There are two main concerns indicating
that the Byzantine failure model should be used with care in the context
of secure systems. The first concern is that Byzantine-tolerant solutions
(for example to Interactive Consistency) are not concerned with secrecy.
For example, if a database is fully replicated to maintain availability in
the presence of Byzantine failures, an attacker compromising at least one
database server will know the entire contents of the database. If file contents
are required to be kept secret, then standard algorithms for Interactive
Consistency from the fault-tolerance area can only be applied if specific
firewall architectures are used. If secrecy of replicated data is required,
mechanisms from cryptography have to be applied, usually some instance
of secret sharing. In this approach, data is stored in a distributed way so that
it needs a certain fraction of nodes to collaborate in the reconstruction of the
data. If this fraction is higher than the number of nodes which may be faulty,
then the Byzantine nodes cannot by themselves reconstruct arbitrary data.
However, if standard agreement protocols are used, nothing can prevent a
Byzantine node from receiving information about what has been proposed
as the database update by individual processes. Interestingly, a similar
problem to Interactive Consistency where individual process inputs can be
kept secret has been studied for years in the area of cryptography under
the heading 128 of secure multi-party computation. In a secure multi-party
computation, a set of processes wants to compute a deterministic function
of all their inputs without trusting each other. A common example is the
millionaires’ problem: Two millionaires want to know who of them has more
money but they do not want to tell each other how much they really have.
A multi-party computation can compute any function even though a certain
fraction of nodes exhibits Byzantine behavior. It does this in a way so that a
Coordination 89
Byzantine process learns nothing about the inputs of other processes to the
computation (apart from what is derivable from the result of the function).
It is obvious that Interactive Consistency can be formulated as an instance
of secure multi-party computation and often researchers in fault-tolerance
are not aware of this fact leading to multiple re-inventions of the wheel. The
second concern suggesting care in using Byzantine failures in security is
related to measures of reliability. The Interactive Consistency problem (as
well as secure multiparty computation) is provably impossible if at least one
third of the processes can behave in a Byzantine fashion. If we denote by the
maximum number of faulty processes and by the total number of processes,
this means that we need for the problem to be solvable. In practice, we
cannot predict with certainty that will hold, we can merely give a probability,
which is called the assumption coverage. The relevant input measure is
the reliability of a component which is defined as the probability that the
component is not faulty until a certain time. Experience from large data
collections of component failures shows that the reliability of components
can be modeled as a random variable satisfying a certain distribution. The
overall reliability of a complex system can then be calculated from the
reliability of its components.
Figure 4.4: The Byzantine Generals Problem. Source: https://cacm.acm.org/

magazines/2009/7/32080-contemporary-approaches-to-fault-tolerance/fulltext
An important assumption which makes these calculations possible (and
which can be defensible) is that the failures of the nodes are statistically
independent. In the area of security, there are no extensive and standardized
databases of security violations except the recently established Internet
Storm Center. It is also often argued that Byzantine failures in the security
setting are not random events: If new security vulnerability is published, the
probability of a server being compromised rises. But maybe most importantly
it is very difficult to argue that the occurrences of security related Byzantine
failures are statistically independent (especially if all servers run the same
operating system). So, although Byzantine failures still result in arbitrary
behavior, they are not random events in security.
4.4.2 Omission failure

When a process or channel fails to do something that it is expected to it is
termed an omission failure. Process omission failures: A process makes an
omission failure when it crashes—it is assumed that a crashed process will
make no further progress on its program. A crash is considered to be clean if
the process either functions correctly or has halted. A crash is termed a fail-
stop if other processes can detect with certainty that the process has crashed.
A process makes an omission failure when it crashes. It is assumed that a
crashed process will make no further progress on its program. A crash is
considered to be clean if the process either functions correctly or has halted.
A crash is termed a fail-stop if other processes can detect with certainty that
the process has crashed. Communication omission failures may occur in
the sending process (send-omission failures), the receiving process (receive
omission failures) or the channel (channel omission failures).
4.4.3 Timing failure

Timing failures transpire across the server of a distributed system. The usual
behavior of these timing failures would be when the server response time
toward the client requests exceeds the expected range. Control flow out of
the responses of the timing failures, and the corresponding clients may give
up as they are unable to wait for the required response from the server,
and thus the server operations fail. For example, different computers clocks
which are utilized to coordinate processes are not synchronized; when a
message is stalled for an extension beyond a threshold period.
4.4.4 Crash failure

Crash failures across the server of a typical distributed system and if these
failures happen operations of the server for some time. Operating system
failures are the best examples of this case and the corresponding fault
tolerant systems developed with respect to these affects.
Coordination 91
Table 4.2: Failure Models
Type of failure Description

Crash failure A server halts but is working correctly until it halts
Omission failure A server fails to respond to incoming requests
Receive omission A server fails to receive incoming messages
Send omission A server fails to send messages
Timing failure A server’s response lies outside the specified time in-
terval
Response failure The server’s response is incorrect
Value failure The value of the response is wrong
State transition f. The server deviates from the correct flow of control
Arbitrary (Byzan- A server may produce arbitrary responses at arbitrary
tine) times
failure
Source: http://www.ejbtutorial.com/lectures/jussi/DistSys-08f-5.pdf
4.5 ELECTIONS
In a distributed environment, most applications often require a single entity
to act temporarily as a central controller to coordinate the execution of a
particular task by the entities. In some cases, the need for a single coordinator
arises from the desire to simplify the design of the solution protocol for a
rather complex problem; in other cases, the presence of a single coordinator
is required by the nature of the problem itself. The problem of choosing such
a coordinator from a population of autonomous symmetric entities is known
as Leader Election (Elect). Formally, the task consists in moving the system
from an initial configuration where all entities are in the same state (usually
called available), into a final configuration where all entities are in the
same state (traditionally called follower), except one which is in a different
state (traditionally called leader). There is no restriction on the number of
entities that can start the computation, nor on which entity should become
leader. We can think of the Election problem as the problem of enforcing
restriction Unique Initiator in a system where actually no such a restriction
exists: the multiple initiators would first start the execution of an Election
protocol; the sole leader will then be the unique initiator for the subsequent
computation. As election provides a mechanism for breaking the symmetry
among the entities in a distributed environment, it is at the basis of most
control and coordination processes (e.g., mutual exclusion, synchronization,
concurrency control, etc.) employed in distributed systems, and it is closely

related to other basic computations (e.g., minimum finding, spanning-tree
construction, traversal).
4.5.1 Election in trees

The tree is the connected graph with the scarcest topology: m = n − 1. Hence
strategy Elect Minimum leads to an election protocol where the number
of messages in the worst case is 3n + k⋆ − 4 ≤ 4n – 4. Interestingly, also
ssstrategy Elect Minimum Initiator will have the same complexity. Consider
now applying strategy Elect Root. As the network is a tree, the only work
required is to transform it into a rooted tree. It is not difficult to see how
saturation can be used to solve the problem. In fact, if Full Saturation is
applied, then a saturated node knows that itself and its parents are the only
saturated nodes; furthermore, as a result of the saturation stage, every non-
saturated entity has identified as its parent the neighbor closest to the saturated
pair. In other words, saturation will root the tree not in a single node but in
a pair of neighbors: the saturated ones. Thus, to make the tree rooted in a
single node we just need to choose only one of the two saturated nodes. In
other words, the “election” among all the nodes is reduced to an “election”
between the two saturated ones. This can be easily accomplished by having
the saturated nodes communicate their identities and having the node with
smallest identity become elected, while the other stays processing. Thus,
the Tree Election protocol will be Full Saturation with the new rules and the
routine Resolve shown in Figure 2. The number of message transmissions
for the election algorithm Tree Election will be exactly the same as the
one experienced by full saturation with notification plus two “election”
messages; i.e., M [Tree Election]= 3n + k⋆− 2 ≤ 4n − 2. In other words,
it uses two more messages than the solution obtained using the strategy
Elect Minimum. It should be noted that messages that do not carry values
but only a constant number of bits are called signals and in most practical
systems, they have reduced communication costs that value messages. In
Elect Minimum, only the n messages in the saturation stage carry a value,
while the rest are signals; hence, the total number of bits transmitted will be;
B [Tree: Elect_Min] = n (c + log id) + c (2n + k⋆ − 2) (1)where id denotes
the biggest value sent in a message, and c = O (1) denotes the number of bits
required to distinguish among the different messages. In Elect Root, only the
“election” message transmits a node identity; thus, the total number of bits
transmitted is; B [Tree: Elect Root] = 2 (c + log id) + c (3n + k⋆ − 2) (2)That
is, in terms of number of bits, Elect Root is order of size better than Elect
Coordination 93
Minimum. In terms of signals and value messages, with Elect Root strategy,
we have just 2 value messages; with the Elect Minimum strategy we have n
value messages. Remember: measuring the number of bits gives us always
a representation of the efficiency at a more refined level of granularity.
Fortunately, it is not always necessary to go to such a level.
4.5.2 Election in rings

Rings can be described as the networks with the (scarcest) topology: m = n;
however, rings have a complete symmetry in terms of structure in the sense
that all nodes look similar as opposed to the intrinsic asymmetry of trees
which signifies the existence of internal and leaf nodes. We will represent
the ring by R = (x0, x1, …, xn−1). Let us study a case of electing a leader in
a ring R, under the regular set of restriction for election, IR= {Bidirectional
links, Connectivity, Total Reliability, Initial Distinct Values}, coupled
with the fact that the network is a ring (Ring). Denote by id (x) the unique
value associated to x. Because of its structure, in a ring we will use almost
exclusively the approach of minimum- finding as a tool for leader election.
In fact, we will consider both the Elect Minimum and the Elect Minimum
Initiator approaches. Clearly the first solves both Min and Elect, while the
latter solves only Elect. Take note that every protocol that elects a leader in
a ring can be made to find the minimum value it is not predetermined with
an additional n message and time. Further notice that, in the worst case,
the two approaches coincide: all entities might be initiators. Let us now
examine how minimum-finding and election can be efficiently performed in
a ringceAs, in a ring each entity has only two neighbors, for conciseness, we
will use the notation other to indicate N (x)−sender at an entity x (Nicola,
S. 2007).
REFERENCES
1. Kopetz, H. (1997). Real-time systems: design principles for distributed
embeddedapplications. New York: Kluwer International. Retrieved
January 15, 2018, from http://utdallas.edu/~bhd130030/Lamport’s%20
Mutual%20Exclusion%20Algorithm/PROJECT_REPORT.pdf
2. Nicola, S. (2005). Design and analysis of distributed algorithms (pp.
99, 102-104). Hoboken, New Jersey: John Wiley & Sons, Inc.
3. Tanenbaum, A., & Renesse, R. (1985). Distributed operating systems.
ACM Computing Surveys, 17(4), pp. 419-70.
4. Tanenbaum, A.S. (2003). Computer networks (4th ed.). Upper
SaddleRivee, NJ: Prentice-Hall International.
CHAPTER 5
DISTRIBUTION AND
OPERATING SYSTEMS
“UNIX is an operating system, OS/2 is half an operating system, Windows

is a shell, and DOS is a boot partition virus.”
-Peter Coffin
CONTENTS
5.1 Introduction to Operating Systems........................................................................... 96
5.2 Batch Operating System.......................................................................................... 99
5.3 Time-Sharing Operating Systems.............................................................................. 99
5.4 Distributed Operating System................................................................................ 100
5.5 Real-Time Operating System.................................................................................. 101
5.6 Network Operating System.................................................................................... 102
5.7 Unix Operating System.......................................................................................... 105
5.8 Windows Operating System................................................................................... 107
5.9 Distributed and Network File System..................................................................... 108
References................................................................................................................... 114
A computer system has many resources that may be required to solve a

problem: CPU time, memory space, file-storage space, I/0 devices, and
so on. The operating system acts as the manager of these resources. By
providing the user with access to the various resources that it maintains, a
distributed system can improve computation speed and data availability and
reliability. Such a system also provides the user with a distributed file system,
which is a file-service system whose users, servers, and storage devices are
dispersed among the sites of a distributed system. This chapter discusses the
basic functions of system startup, I/0, and storage. It also describes the key
components of an operating systems and the basic computer architecture
that makes it possible to write a functional operating system.
5.1 INTRODUCTION TO OPERATING SYSTEMS

An operating system is software that uses the hardware resources of a
computer system to provide support for the execution of other software.
An operating system is a program that manages the computer hardware. It
also provides a basis for application programs and acts as an intermediary
between the computer user and the computer hardware. An amazing aspect
of operating systems is how varied they are in accomplishing these tasks.
Mainframe operating systems are designed primarily to optimize utilization
of hardware. Personal computer (PC) operating systems support complex
games, business applications, and everything in between. Operating
systems for handheld computers are designed to provide an environment
in which a user can easily interface with the computer to execute programs.
Thus, some operating systems are designed to be convenient, others to be
efficient, and others some combination of the two. Most software programs
are designed to work with just one company’s operating system, like just
Windows (Microsoft) or just macOS (Apple). A piece of software will
openly declare which operating systems it supports and will get very
specific if necessary. For example, a video production software program
might say it supports Windows 10, Windows 8, and Windows 7, but does
not support older versions of Windows such as Windows Vista and XP.
Specifically, an operating system provides the following services: Program
execution, I/0 operations, File System manipulation, Communication,
Error Detection, Resource Allocation, and Protection. However, operating
systems are essential to business operations, system security, and software
applications. Operating systems allow administrators to control access to the
system, install and configure third-party commercial-off-the-shelf (COTS)
Distribution and Operating Systems 97
software and monitor activity with built in auditing tools. Users count on
operating systems to provide easy to use graphical user interfaces (GUI),
operate multiple applications at one time, and store and access data and
information needed for daily operations (UMUC, 2011). Businesses count
on operating systems to address and provide for the four basic security
concerns of confidentiality, integrity, availability and authenticity (Stallings,
2011). Although many operating systems include built in controls to address
these security concerns, additional measures should be taken to ensure the
required level of security is achieved.
5.1.1 Program execution

Operating systems handle many kinds of activities from user programs to
system programs like printer spooler, name servers, file server, etc. Each of
these activities is encapsulated as a process. A process includes the complete
execution context (code to execute, data to manipulate, registers, OS
resources in use). Following are the major activities of an operating system
with respect to program management: i. It loads a program into memory. ii.
It executes the program. iii. It handles program’s execution. iv. It provides
a mechanism for process synchronization. v. It provides a mechanism for
process communication. vi. It provides a mechanism for deadlock handling.
5.1.2 I/O operation

An I/O subsystem comprises of I/O devices and their corresponding driver
software. Drivers hide the peculiarities of specific hardware devices from
the users. An Operating System manages the communication between user
and device drivers. I/O operation means read or write operation with any
file or any specific I/O device. Operating system provides the access to the
required I/O device when required.
5.1.3 File system manipulation

A file represents a collection of related information. Computers can store files
on the disk (secondary storage), for long-term storage purpose. Examples
of storage media include magnetic tape, magnetic disk, and optical disk
drives such asCD and DVD. Each of these media has its own properties
such as speed, capacity, data transfer rate, and data access methods. A file
system is normally organized into directories for easy navigation and usage.
These directories may contain files and other directions. Following are the
major activities of an operating system with respect to file management: i.
Program needs to read a file or write a file. ii. The operating system gives
the permission to the program for operation on file. iii. Permission varies
from read-only, read-write, denied, and so on. iv. Operating System provides
an interface to the user to create/delete files. v. Operating System provides
an interface to the user to create/delete directories. vi. Operating System
provides an interface to create the backup of file system.
5.1.4 Communication
In case of distributed systems which are a collection of processors that
do not share memory, peripheral devices, or a clock, the operating system
manages communications between all the processes. Multiple processes
communicate with one another through communication lines in the network.
The OS handles routing and connection strategies, and the problems of
contention and security. Following are the major activities of an operating
system with respect to communication: Two processes often require data to
be transferred between them. i. Both the processes can be on one computer
or on different computers, but are connected through a computer network.
ii. Communication may be implemented by two methods, either by Shared
Memory or by Message Passing.
5.1.5 Error Handling

An operating system that uses protected memory can guard against many
kinds of hardware and application errors, so that a complete system failure
is not the usual result of each minor mechanical glitch. Devices and I/0
transfers can fail in many ways, either for transient reasons, as when a
network becomes overloaded, or for “permanent” reasons, as when a disk
controller becomes defective. Operating systems can often compensate
effectively for transient failures. For instance, a disk read () failure results
in a read () retry, and a network send () error results in a resend (), if the
protocol so specifies. Unfortunately, if an important component experiences
a permanent failure, the operating system is unlikely to recover (Abraham
S. et. al, 2009).
Errors can occur anytime and anywhere. An error may occur in CPU, in
I/O devices or in the memory hardware. Following are the major activities
of an operating system with respect to error handling: i. The OS constantly
checks for possible errors. ii. The OS takes appropriate action to ensure
correct and consistent computing.
5.1.6 Resource management

In case of multi-user or multi-tasking environment, resources such as main
memory, CPU cycles,and files storage are to be allocated to each user or
job. Following are the major activities of an operating system with respect
to resource management: i. The OS manages all kinds of resources using
schedulers. ii. CPU scheduling algorithms are used for better utilization of
CPU.
5.1.7 Protection
Considering a computer system having multiple users and concurrent
execution of multiple processes, the various processes must be protected
from each other’s activities. Protection refers to a mechanism or a way to
control the access of programs, processes, or users to the resources defined
by a computer system. Following are the major activities of an operating
system with respect to protection: i. The OS ensures that all access to system
resources is controlled. ii. The OS ensures that external I/O devices are
protected from invalid access attempts. iii. The OS provides authentication
features for each user by means of passwords.
5.2 BATCH OPERATING SYSTEM

The users of a batch operating system do not interact with the computer
directly. Each user prepares his job on an off-line device like punch cards
and submits it to the computer operator. To speed up processing, jobs with
similar needs are batched together and run as a group. The programmers
leave their programs with the operator and the operator then sorts the
programs with similar requirements into batches. The problems with Batch
Systems are lack of interaction between the user and the job. CPU is often
idle because the speed of the mechanical I/O devices is slower than the
CPU, and it is difficult to provide the desired priority.
5.3 TIME-SHARING OPERATING SYSTEMS

Time-sharing is a technique which enables many people, located at
various terminals, to use a particular computer system at the same time.
Time-sharing or multitasking is a logical extension of multiprogramming.
Processor’s time which is shared among multiple users simultaneously is
termed as time-sharing. The main difference between multi-programmed
batch systems and time-sharing systems is that in case of multi-programmed

batch systems, the objective is to maximize processor use, whereas in time-
sharing Systems, the objective is to minimize response time. Multiple jobs
are executed by the CPU by switching between them, but the switches
occur so frequently. Thus, the user can receive an immediate response.
For example, in a transaction processing, the processor executes each user
program in a short burst or quantum of computation. That is, if n users are
present, then each user can get a time quantum. When the user submits the
command, the response time is in few seconds at most. The operating system
uses CPU scheduling, and multi-programming, to provide each user with a
small portion of a time. Computer systems that were designed primarily
as batch systems have been modified to time-sharing systems. Advantages
of timesharing operating systems are as follows: i. It provides the benefit
of quick response. ii. It avoids replication of software. iii. It reduces CPU
standby time. Disadvantages of Time-sharing operating systems are as
follows: i. It has the issue of reliability ii. Question of security and integrity
of user programs and data comes to play. iii. It bears a challenge of data
communication
5.4 DISTRIBUTED OPERATING SYSTEM

Distributed systems use multiple central processors to serve multiple real-
time applications and multiple users. Data processing jobs are distributed
among the processors accordingly. The processors communicate with one
another through various communication lines (such as high-speed buses or
telephone lines). These are referred as loosely coupled systems or distributed
systems. Processors in a distributed system may vary in size and function.
These processors are referred as sites, nodes, computers, and so on. The
advantages of distributed systems are as follows: i. With resource distribution
facility, a user at one site may be able to use the resources available at another
site. ii. It speeds up the exchange of data with one another via e-mail. iii.
If one site fails in a distributed system, the remaining sites can potentially
continue operating. iv. It offers better service to the customers. v. It enables
reduction of the load on the host computer. vi. It enables reduction of delays
in data processing.
Figure 5.1: Distributed Operating Systems. Source: https://www.quora.com/

What-is-distributed-operating-system
5.5 REAL-TIME OPERATING SYSTEM

A real-time system is defined as a data processing system in which the time
interval required to process and respond to inputs is so small that it controls
the environment. The time taken by the system to respond to an input and
display of required updated information is termed as the response time. So, in
this method, the response time is very less as compared to online processing.
Real-time systems are used when there are rigid time requirements on the
operation of a processor or the flow of data and real-time systems can be
used as a control device in a dedicated application. A real-time operating
system must have well-defined, fixed time constraints, otherwise the system
will fail. For example, scientific experiments, medical imaging systems,
industrial control systems, weapon systems, robots, air traffic control
systems, etc. There are two types of real-time operating systems.
5.5.1 Hard real-time systems

Hard real-time systems guarantee that critical tasks complete on time. In
hard real-time systems, secondary storage is limited or missing and the data
is stored in ROM. In these systems, virtual memory is almost never found.
The goal of a hard real-time system is to ensure that all deadlines are met,
but for soft real-time systems the goal becomes meeting a certain subset
of deadlines to optimize some application-specific criteria. The particular
criteria optimized depend on the application, but some typical examples
include maximizing the number of deadlines met, minimizing the lateness
of tasks and maximizing the number of high priority tasks meeting their
deadlines. Also, hard real-time systems are used when it is imperative that
an event be reacted to within a strict deadline. Such strong guarantees are
required of systems for which not reacting in a certain interval of time would
cause great loss in some manner, especially damaging the surroundings
physically or threatening human lives (although the strict definition is
simply that missing the deadline constitutes failure of the system). For
example, a car engine control system is a hard real-time system because
a delayed signal may cause engine failure or damage. Other examples of
hard real-time embedded systems include medical systems such as heart
pacemakers and industrial process controllers. Hard real-time systems
are typically found interacting at a low level with physical hardware, in
embedded systems. Early video game systems such as the Atari 2600 and
Cinematronics vector graphics had hard real-time requirements because of
the nature of the graphics and timing hardware.
5.5.2 Soft real-time systems

Soft real-time systems are less restrictive. A critical real-time task gets
priority over other tasks and retains the priority until it completes. Soft real-
time systems are typically used to solve issues of concurrent access and the
need to keep a number of connected systems up-to-date through changing
situations. An example can be software that maintains and updates the flight
plans for commercial airliners: the flight plans must be kept reasonably
current, but they can operate with the latency of a few seconds. Live audio-
video systems are also usually soft real-time; violation of constraints results
in degraded quality, but the system can continue to operate and also recover
in the future using workload prediction and reconfiguration methodologies.
Soft real-time systems have limited utility than hard real-time systems. For
instance, virtual reality, multimedia Advanced Scientific Projects such as
undersea exploration and planetary rovers etc.
5.6 NETWORK OPERATING SYSTEM

A network operating system (NOS) is a computer operating system
that is designed for network use. Usually a NOS is a complete operating
system with file, task and job management. However, with some earlier
operating systems, it was a separate component that enhanced a basic, non-
networking operating system by adding networking capabilities. Examples
include Novell’s Netware and Artisoft’s LANtastic. A server-based network

operating system provides networking support for multiple simultaneous
users, each with the ability to access network resources, as well as security
and other administrative functions. Network operating systems, in the first
sense, have existed for more than 35 years. In particular, UNIX was designed
from the beginning to support networking, and all of its descendants (i.e.,
Unix-like operating systems), including Linux and Mac OSX, feature built-
in networking support. The Microsoft Windows operating systems did not
initially support networking. Thus, Novell NetWare was introduced and
became the first popular network operating system for personal computers.
Windows 95 and Windows for Workgroups were Microsoft’s first network
operating system products. Today, almost every consumer operating system
qualifies as a NOS. This is in large part due to the popularity of the Internet
and the consequent need to support the IP suite. In a peer-to-peer network,
such as Microsoft Windows 98 or XP, in which each host can also be a
server, the operating system might still be considered a network operating
system, but it is more light weight than a full-blown NOS. Examples of
NOS; i. Windows NT server and workstation which can utilize multiple
processors and run on Intel or RISC computers and also performs preventive
multitasking. ii. Windows 95 which supports older drivers but cannot use
NT drivers or multiple processors. iii. OS/2 which supports preemptive
multitasking and multithreading and protects applications from each other. It
runs on Intel or RISC computers. Supports 1 processor. Requires a minimum
of a 386 and 8M of RAM. iv. MacIntosh which supports compliant and
preventive multitasking and utilizes Windows, icons, mouse environment
for system control.To transmit signals across a network, it is necessary for
the computer to communicate with its modem or Network Interface Card.
Network Operating Systems (NOS) provide the protocols necessary to
achieve this goal, but each different type of modem or NIC needs to be able
to communicate with the particular NOS. It is therefore necessary to install
the special software that comes with the interface device. This software is
often referred to as a driver. Computers made today usually come with both
the interface and necessary drivers installed. Occasionally, you must install
the modem or NIC yourself. It is necessary to install the correct driver for that
interface device. Failure to so install the driver means that the device will be
unable to communicate over the network or with the computer it is installed
in. Network Operating Systems not only allow communication across a
network, they also allow a network administrator to organize resources,
control access, and ensure that the network is operating efficiently. Sharing
of network resources can be peer-to-peer or client/server. Which one is the

best is dependent on the end goal of the network. To transmit signals across
a network, it is necessary for the computer to communicate with its modem
or Network Interface Card. Network Operating Systems (NOS) provide the
protocols necessary to achieve this goal, but each different type of modem or
NIC needs to be able to communicate with the particular NOS. It is therefore
necessary to install the special software that comes with the interface device.
This software is often referred to as a driver. Computers made today usually
come with both the interface and necessary drivers installed. Occasionally,
you must install the modem or NIC yourself. It is necessary to install the
correct driver for that interface device. Failure to so install the driver means
that the device will be unable to communicate over the network or with
the computer it is installed in. Network Operating Systems not only allow
communication across a network, they also allow a network administrator to
organize resources, control access, and ensure that the network is operating
efficiently. Sharing of network resources can be peer-to-peer or client/server.
Which one is the best is dependent on the end goal of the network.
Figure 5.2: General structure of a Network Operating System. Source: https://

www.slideshare.net/suhitkulkarni/distributed-os-an-introduction
5.6.1 Required NOS services

Red Hat Enterprise Linux uses a combination of kernel-level support and
daemon processes to provide NFS file sharing. All NFS versions rely on
Remote Procedure Calls (RPC) between clients and servers. RPC services
under Linux are controlled by theportmapservice. To share or mount NFS
file systems, the following services work together, depending on which
version of NFS is implemented: i. nfs—(/sbin/service nfs start)
starts the NFS server and the appropriate RPC processes to service requests
for shared NFS file systems. ii. nfslock—(/sbin/service nfslock
start) is a mandatory service that starts the appropriate RPC processes

to allow NFS clients to lock files on the server. iii. portmap—accepts port
reservations from local RPC services. These ports are then made available
(or advertised) so the corresponding remote RPC services access them.
portmapresponds to requests for RPC services and sets up connections to
the requested RPC service. This is not used with NFSv4. The following RPC
processes facilitate NFS services: i. rpc.mountd—this process receives
mount requests from NFS clients and verifies the requested file system is
currently exported. This process is started automatically by thenfsservice
and does not require user configuration. This is not used with NFSv4. ii. rpc.
nfsd—Allows explicit NFS versions and protocols the server advertises to
be defined. It works with the Linux kernel to meet the dynamic demands
of NFS clients, such as providing server threads each time an NFS client
connects. This process corresponds to thenfsservice. iii. rpc.lockd—
allows NFS clients to lock files on the server. Ifrpc.lockdis not started,
file locking will fail.rpc.lockdimplements theNetwork Lock Manager
(NLM)protocol. This process corresponds to thenfslockservice. This is not
used with NFSv4. iv. rpc.statd—This process implements theNetwork
Status Monitor (NSM)RPC protocol which notifies NFS clients when an
NFS server is restarted without being gracefully brought down. This process
is started automatically by thenfslockservice and does not require user
configuration. This is not used with NFSv4. v. rpc.rquotad—This process
provides user quota information for remote users. This process is started
automatically by thenfsservice and does not require user configuration.
vi. rpc.idmapd—This process provides NFSv4 client and server upcalls
which map between on-the-wire NFSv4 names (which are strings in the
form of user@domain) and local UIDs and GIDs. Foridmapdto function
with NFSv4, the/etc/idmapd.confmust be configured. This service is
required for use with NFSv4.
5.7 UNIX OPERATING SYSTEM

The UNIX system is mainly composed of three different parts: the kernel,
the file system, and the shell. [The kernel] is that part of the system which
manages the resources of whatever computer system it lives on, to keep
track of the disks, tapes, printers, terminals, communication lines and any
other devices. The file system is the organizing structure for data. The file
system is perhaps the most important part of the UNIX operating system.
The file system goes beyond being a simple repository for data, and provides
the means of organizing the layout of the data storage in complex ways. The
shell is the command interpreter. Although the shell is just a utility program,
and is not properly a part of the system, it is the part that the user sees. The
shell listens to your terminal and translates your requests into actions on
the part of the kernel and the many utility programs. UNIX/Linux UNIX
is one of the most primitive operating systems in the computer world, and
is still widely used today. However, it is not a very conspicuous operating
system. Somewhat arcane in its operation and interface, it is ideally suited
for the needs of large enterprise computing systems. It is also the most
common operating system run by servers and other computers that form the
bulk of the Internet. While you may never use UNIX on your local PC, you
are using it indirectly in one form or another every time you log on to the
net. While few people run UNIX on their own systems, there are in fact a
number of different versions of UNIX available for the PC, and millions of
PC users have chosen to install “UNIXy” operating systems on their own
desktop machines. There are dozens of variants of the basic UNIX interface;
the most common one for the PC platform is Linux, which is itself available
in many flavors. While UNIX operating systems can be difficult to set up
and require some knowledge to operate, they are very stable and robust, are
efficient with system resources and are generally free or very inexpensive
to obtain. Unix operating systems are widely used in both servers and
workstations. The Unix environment and the client-server program model
were essential elements in the development of the Internet and the reshaping
of computing as centered in networks rather than in individual computers.
Both Unix and the C programming language were developed by AT&T
and distributed to government and academic institutions, causing both to
be ported to a wider variety of machine families than any other operating
system. As a result, Unix became synonymous with “open systems.” Unix
was designed to be handy, multi-tasking and multi-user in a time-sharing
pattern. Unix systems are characterized by various concepts: the use of plain
text for storing data; a hierarchical file system; treating devices and certain
types of inter-process communication (IPC) as files; and the use of a large
number of small programs that can be strung together through a command
line interpreter using pipes, as opposed to using a single monolithic program
that includes all of the same functionality. These concepts are known as the
Unix philosophy. Under Unix, the “operating system” consists of many of
these utilities along with the master control program, the kernel. The kernel
provides services to start and stop programs, handle the file system and
other common “low level” tasks that most programs share, and, perhaps
most importantly, schedules access to hardware to avoid conflicts if two

programs try to access the same resource or device simultaneously. To
mediate such access, the kernel was given special rights on the system and
led to the division between user-space and kernel-space. The microkernel
tried to reverse the growing size of kernels and return to a system in which
most tasks were completed by smaller utilities. In an era when a “normal”
computer consists of a hard disk for storage and a data terminal for input
and output (I/0), the Unix file model worked quite well as most I/0 was
“linear.” However, modern systems include networking and other new
devices. Describing a graphical user interface driven by mouse control in
an “event driven” fashion worked poorly under the old model. Work on
systems supporting these new devices in the 1980s led to facilities for non-
blocking I/0, forms of inter-process communications other than just pipes,
as well as moving functionality such as network protocols out of the kernel.
Figure 5.3: Different Layers of the UNIX Architecture. Source: http://testing-

pool.com/the-unix-architecture/
5.8 WINDOWS OPERATING SYSTEM

The File Allocation Table (FAT) filing system, supported by all versions
of Microsoft Windows, was an evolution of that used in Microsoft’s
earlier operating system (MS-DOS which in turn was based on 86-DOS).
FAT ultimately traces its roots back to the ephemeral M-DOS project and
Standalone disk BASIC before it. Over the years, various features have
been added to it, inspired by similar features found on file systems used
by operating systems such as Unix. Older versions of the FAT file system
(FAT12 and FAT16) had file name length limits, a limit on the number of
entries in the root directory of the file system and had restrictions on the
maximum size of FAT-formatted disks or partitions. Specifically, FAT12 and
FAT16 had a limit of 8 characters for the file name, and 3 characters for the
extension (such as.exe). This is commonly referred to as the 8.3 filename
limit. FAT32 also addressed many of the limits in FAT12 and FAT16, but
remains limited compared to NTFS. NTFS introduced with the Windows
NT operating system, allowed ACL-based permission control. Hard links,
multiple file streams, attribute indexing, quota tracking, sparse files,
encryption, compression, reparse points (directories working as mount-
points for other file systems, symlinks, junctions, remote storage links) are
also supported, though not all these features are well-documented. Unlike
many other operating systems, Windows uses a drive letter abstraction at the
user level to differentiate one disk or partition from another. For example,
the path C:\WINDOWS represents a directory WINDOWS on the partition
represented by the letter C. The C drive is most commonly used for the
primary hard disk partition, on which Windows is usually installed and from
which it boots. This “culture” has become so firmly deep-rooted that bugs
came about in older versions of Windows which made assumption that the
drive that the operating system was installed on was C. The practice of using
“C” for the drive letter can be traced to MS-DOS, where the letters A and B
were reserved for up to two floppy disk drives. Network drives may also be
mapped to drive letters.
5.9 DISTRIBUTED AND NETWORK FILE SYSTEM

Distributed file systems (DFS) are usually built around the impression of one
or more file servers that store files, and numerous clients that can request
file access. In one design, remote access, every time a process wants to read
or write a file, it sends a request to some server, which then performs the
work. In another design, local access, to access a file, a client asks a server
to send it a copy of the file, which it then caches locally, in its memory or on
its disk. The client can then perform one or more operations locally. When it
is done, it can send the whole file back to the server. If only a small number
of operations need to be performed, and/or files are very large, the first
model works better. However, if a large number of operations are needed,
and/or files are very small, the latter works better. When multiple processes
are interested in reading and writing the same file, the exact semantics get
complicated. On a single processor, the semantics are usually clear: if one
process writes to a file and then a second process reads from the file, the
second process sees the results of the first process “write.” In a distributed
system using remote access, the results are the same as on a single processor,
but in a system in which files are cached locally, the following situation can
occur. Client 1 asks for a gets a copy of some file. Then client 2 asks for a
gets a copy of the same file. Now process 1 modifies the file. When process
2 reads its copy, it does not see the alterations that process 1 made. Worse
yet, if both processes modify the file and send it back to the server, the first
copy sent back will eventually be overwritten by the second one. There are
two possible solutions to this problem. In the first one, once a process has
asked for and been granted a file, no other copies will be sent out until the
first one has been returned. Effectively, the file is then locked. The second
solution allows multiple copies, but redefines the semantics to say that once
a file has been cached by a client, the effect of a simultaneous operation
by another client is undefined. The effect of one or more operations only
becomes definitive when the file is closed and written back to the server.
While this approach changes the meaning of concurrent operation, it is
much more efficient. A Network File System (NFS) allows remote hosts
to mount file systems over a network and interact with those file systems
as though they are mounted locally. This enables system administrators
to combine resources onto centralized servers on the network. Currently,
there are three versions of NFS. NFS version 2 (NFSv2) is older and is
widely supported. NFS version 3 (NFSv3) has more features, including
64bit file handles, Safe Async writes and more robust error handling. NFS
version 4 (NFSv4) works through firewalls and on the Internet, no longer
requires portmapper, supports ACLs, and utilizes stateful operations. Red
Hat Enterprise Linux supports NFSv2, NFSv3, and NFSv4 clients, and
when mounting a file system via NFS, Red Hat Enterprise Linux uses
NFSv3 by default, if the server supports it. All versions of NFS can useTCP
running over an IP network, with NFSv4 requiring it. NFSv2 and NFSv3
can use theUDP running over an IP network to provide a stateless network
connection between the client and server. When using NFSv2 or NFSv3
with UDP, the stateless UDP connection under normal conditions has less
Protocol overhead than TCP which can translate into better performance on
very clean, non-congested networks. The NFS server sends the client a file
handle after the client is authorized to access the shared volume. This file
handle is an opaque object stored on the server’s side and is passed along
with RPC requests from the client. The NFS server can be restarted without
affecting the clients and the cookie remains intact. However, because UDP
is stateless, if the server goes down unexpectedly, UDP clients continue
to saturate the network with requests for the server. For this reason, TCP
is the preferred protocol when connecting to an NFS server. NFSv4 has
no interaction with portmapper,rpc.mountd,rpc.lockd, andrpc.statd,
as protocol support has been incorporated into the v4 protocol. NFSv4
listens on the well-known TCP port (2049) which eliminates the need for
theportmapperinteraction. The mounting and locking protocols have been
incorporated into the V4 protocol which eliminates the need for interaction
withrpc.mountdandrpc.lockd.
Figure 5.4: A DFS operating in Web Server System. Source: https://flylib.com/

books/en/2.393.1.122/1/
5.9.1 Processes and thread

A process is a program in execution. Traditionally a process consists of an
address space with a single thread of control operating within that address
space. The operating system maintains environmental and accounting
information for each process under its control in a process control block
(PCB). This includes the processor state, descriptors for open files and
communication links, I/O buffers, locks and other OS resources in use by the
process as well as keeping track of past resource usage for cost and auditing
purposes. The PCB contains the necessary information for context switching
by the native operating system. A process is sequential if a single thread of
control regulates its address space. Allowing multiple threads of control in a
process introduces concurrency. Each thread shares and operates within the
common process address space but each has its own local processor state
maintained in a thread control block (TCB) associated with the process.

Thread management is very lightweight as thread creation and context
switching involves little overhead. Threads communicate and synchronize
with each other using fast shared memory mechanisms. Max Hailperin
gave a better distinctive meaning to threads in his statement; “Computer
programs consist of instructions, and computers carry out sequences of
computational steps specified by those instructions. We call each sequence
of computational steps that are strung together one after another a thread.
The simplest programs to write are single-threaded, with instructions that
should be executed one after another in a single sequence” (Max H., 2005).
Threads are quite beneficial for distributed system applications. Many
systems interact using a client/server model of communication where a
server process listens for client requests, executes them and returns the
results. If the server was operating as a sequential process and attempting to
support multiple client requests then two or more concurrent requests would
have to be executed in sequence by the server process. This would keep a
number of buffered unanswered requests waiting indefinitely until the server
finished with earlier ones. The outstanding requests may timeout giving the
client the impression that the server has failed. One alternative is to have the
server fork a new process to deal with every new request. A listener process
receives messages and creates a new process to execute the service passing
it the parameters from the client. Requests then execute asynchronously
under the control of the operating system. The listener process could also
provide an immediate initial response to the client if required. The problem
however is that process creation can be quite slow as the operating system
has to find sufficient free memory space for the process and set up other
parts of its control block. The operating system also has a limited number of
PCBs available. This would be very inefficient if the amount of time spent
servicing requests was small. In addition, if the server is maintaining data
of some kind, then the server processes must synchronize their accesses
to this data using IPC introducing propagation delays which reduce server
performance. A better alternative is to have the server create threads to deal
with new requests. A controlling thread receives new requests and creates
a lightweight thread to execute it. This is a more scalable approach from
the operating system’s point of view as it is a more efficient use of system
resources. Coordination and synchronization between the cooperating parts
of the server process are achieved more efficiently with shared memory
mechanisms. Threads allow parallelism to be combined with the easily
understood blocking communication of the client/server model. That is,
programmers feel more comfortable with sequential code execution and

blocking communication because it is easier to specify. We can retain the
model of our sequential process interaction with blocking calls but still
achieve parallelism in the application with threads. This is because when a
thread in a process blocks, waiting for a reply from a server, another thread
within that process can be scheduled and so the process does not lose its
allotted CPU time. Another benefit is that threads allow the process to take
advantage of a multiprocessor system.
5.9.2 Concurrent threads

If two threads have overlapping lifetimes, as illustrated in the figure
below, we say they are concurrent. One of the most fundamental goals of
an operating system is to allow multiple threads to run concurrently on
the same computer. That is, rather than waiting until the first thread has
completed before a second thread can run, it should be possible to divide
the computer’s attention between them. If the computer hardware includes
multiple processors, then it will naturally be possible to run threads.
Fundamentally, most uses for concurrent threads enables responsiveness by
allowing the computer system to respond quickly to something external to
the system, such as a human user or another computer system. Even if one
thread is in the midst of a long computation, another thread can respond to
the external agent. Even if one thread has no need for a particular piece of
hardware, another may be able to make productive use of it concurrently,
one per processor (Max H., 2005).
5.9.3 Multithreaded clients

A process may be multithreaded, in which case many executions of the code
co-exist together. Each such thread has its own CPU state and stack, but
they share the rest of the address space and the environment. In terms of
abstractions, a thread embodies the abstraction of the flow of the computation,
or in other words, what the CPU does. A multithreaded process is, therefore,
an abstraction of a computer with multiple CPUs that may operate in parallel.
“All of these CPUs share access to the computer’s memory contents and its
peripherals (e.g., disk and network)” (Dror, G. F., 2011). Multithreading is
sometimes useful as a tool for structuring the program. For example, a server
process may create a separate thread to handle each request it receives. Thus,
each thread does not have to worry about additional requests that arrive
while it is working—such requests will be handled by other threads. To
establish a high degree of distribution transparency, distributed systems that

operate in wide-area networks may need to conceal long interposes message
propagation times. The round-trip delay in a wide-area network can easily
be in the order of hundreds of milliseconds or sometimes even seconds.
A Web browser often starts with fetching the HTML page and subsequently
displays it. To hide communication latencies as much as possible, some
browsers start displaying data while it is still coming in. While the text is
made available to the user, including the facilities for scrolling and such, the
browser continues with fetching other files that make up the page, such as
the images. The latter are displayedas they are brought in. The user needs
thus not wait until all the component of the entire page is fetched before the
page is made available.In effect, it is seen that the Web browser is doing a
number of tasks simultaneously. As it turns out, developing the browser as
a multithreaded client simplifies matters considerably. As soon as the main
HTML file has been fetched, separate threads can be activated to take care
of fetching the other parts. Each thread sets up a separate connection to the
server and pulls in the data. Setting up a connection and reading data from
the server can be programmed using the standard (blocking) system calls,
assuming that a blocking call does not suspend the entire process. As is also
illustrated in Stevens (1998), the code for each thread is the same and, above
all, simple. Meanwhile, the user notices only delays in the display of images
and such, but can otherwise browse through the document (Andrew S. T.
and Maarten V. S. (2007).
Another advantage of multithreading is the implementation of
asynchronous I/O operations, thereby overlapping I/0 with computation. The
idea is that one thread performs the I/O operations, while another computes.
Only the I/O thread blocks to wait for the I/O operation to complete. In the
meanwhile, the other thread can continue to run.
REFERENCES
1. Coulouris, G., Dollimore, J.,&Kindberg, T. (2001). Distributed systems:
concepts and design. Pearson Education Ltd. Retrieved January 2018,
fromhttp://www.gecg.in/papers/ds5thedn.pdf
2. Hailperin, M. (2005). Operating systems and middleware: supporting
controlled interaction. Thomas Course Technology, a division of
Thomas Learning Inc. RetrievedJanuary 2018, from https://gustavus.
edu/mcs/max/os-book/osm-rev1.1.2.pdf
3. Serain, D. (2002). Middleware and enterprise application integration.
London: Springer-Verlag London Limited.
4. Sinha, P. (2002). Distributedoperating systems: concepts and design.
Prentice Hall of India Pvt, Ltd.
5. Tanenbaum, A., & Steen, M. (2002).Distributed systems: principles and
paradigm. Pearson EducationRetrieved January 15, 2018, from http://
barbie.uta.edu/~jli/Resources/MapReduce&Hadoop/Distributed%20
Systems%20Principles%20and%20Paradigms.pdf
CHAPTER 6
PEER TO PEER SYSTEMS
“Peer-to-peer applications have been used to provide file sharing, web cach-
ing, information distribution and other services, exploiting the resources of
tens of thousands of machines across the Internet.”
-George Coulouris
CONTENTS
6.1 Introduction to Peer to Peer System....................................................................... 116
6.2 Routing in P2P....................................................................................................... 117
6.3 Classification of P2P.............................................................................................. 121
6.4 First Generation of P2P.......................................................................................... 124
6.5 Second Generation P2P......................................................................................... 126
6.6 Third Generation P2P............................................................................................ 130
6.7 Current Generation P2P......................................................................................... 133
References................................................................................................................... 135
Another structure for a distributed system is the peer-to-peer (P2P) system

model. In this model, clients and servers are not distinguished from one
another; instead, all nodes within the system are regarded as peers, and each
node act as either a client or a server, depending on whether it is requesting or
providing a service. Peer-to-peer systems offer an advantage over traditional
client-server systems. In a client-server system, the server is a bottleneck;
but in a peer-to-peer system, services can be provided by several nodes
distributed throughout the network. Peer-to-peer systems aim to support
useful distributed services and applications using data and computing
resources available in the personal computers and workstations that are
present in the Internet and other networks in ever-increasing numbers. This
chapter deals extensively with the various peer to peer systems and their
application in distributed systems.
6.1 INTRODUCTION TO PEER TO PEER SYSTEM

Peer-to-peer (P2P) is an alternative network model to that provided by
traditional client server architecture. P2P networks use a decentralized
model in which each machine, referred to as a peer, functions as a client with
its own layer of server functionality. A peer plays the role of a client and a
server at the same time. That is, the peer can initiate requests to other peers,
and at the same time respond to incoming requests from other peers on the
network. It differs from the traditional client-server model where a client
can only send requests to a server and then wait for the server’s response.
With a client-server approach, the performance of the server will deteriorate
as the number of clients requesting services from the server increase.
However, in P2P networks, overall network performance actually improves
as an increasing number of peers are added to the network. These peers can
organize themselves into ad-hoc groups as they communicate, collaborate
and share bandwidth with each other to complete the tasks at hand (e.g.,
file sharing). Each peer can upload and download at the same time, and in a
process like this, new peers can join the group while old peers leave at any
time. This dynamic re-organization of group peer members is transparent
to end-users. Another characteristic of a P2P network is its capability in
terms of fault-tolerance. When a peer goes down or is disconnected from
the network, the P2P application will continue by using other peers. For
example, in a BitTorrent system, any clients downloading a certain file are
also serving as servers. When a client finds one of the peers is not responding,
it searches for other peers, picks up parts of the file where the old peer was,
Peer to Peer Systems 117
and continues the download process. Compared to a client-server model,

where all communication will stop if the server is down, a P2P network is
more fault-tolerant.
Figure 6.1: A Peer to Peer Relationship. Source: http://483eclass.com/spring16/

build_1/Taran/Pages/page2.html
6.2 ROUTING IN P2P

Routing on these networks is either centralized or statically configured and
is therefore unproblematic. Another class of P2P networks is the overlay
network. Overlay networks build a virtual topology on top of the physical
links of the network. Nodes leave and join this network dynamically and
the average uptime of individual nodes is relatively low. The topology of
an overlay network may change all the time. In peer-to-peer systems a
distributed algorithm known as a routing overlay takes responsibility for
locating nodes and objects. The name denotes the fact that the middleware
takes the form of a layer that is responsible for routing requests from any client
to a host that holds the object to which the request is addressed. The objects
of interest may be placed at and subsequently relocated to any node in the
network without client involvement. It is termed an overlay as it implements
a routing mechanism in the application layer that is quite separate from any
other routing mechanisms deployed at the network level such as IP routing.
This approach to the management and location of replicated objects was
first analyzed and shown to be effective for networks involving sufficiently
many nodes in a groundbreaking paper by (Plaxton et al., 1997). Once a
route is established, there is no guarantee of the length of time that it will be
valid. Routing in these networks is therefore very problematic and will be
the focus of our report. Some of the issues facing designers of P2P routing
algorithms are scalability, anonymity and complexity.
6.2.1 Semantic Routing

Semantic Routing is a method of routing which is more focused on the nature
of the query to be routed than the network topology. Essentially semantic
routing improves on traditional routing by prioritizing nodes which have
been previously good at providing information about the types of content
referred to by the query. To be able to search for information on a p2p network
semantically the data needs to have a semantic description associated with it,
one popular solution is the use of RDF meta-data for this purpose. Tagging
documents/data with RDF would provide a rich ‘semantic web’ which
could be structured in a p2p fashion. A schema-based p2p network such as
this would benefit greatly from semantic routing. Semantic routing differs
fundamentally from other routing techniques because prospective nodes are
selected because of another node’s confidence in their ability to respond
correctly to a given query irrespective of their position within the network.
There have been several different projects started with a view to examining
the power of semantic routing. Arguably the most interesting of these is the
Remindinsystem which incorporates a semantic routing algorithm developed
with the intention of mimicking social networks. In addition to this many of
the techniques developed for collaborative filtering are equally applicable
to the ranking of peers within a semantically routed network. Each time
a node answers a query its peers adjust their confidence in that node with
regard to that type of query. The nature of this adjustment depends upon
whether the node answered correctly, i.e., if the search result was selected
by the searcher. The information associated with ‘types’ depends greatly on
the kind of semantic data being dealt with by the network and the strictness
of the peer confidence ranking algorithm. How this data is stored and how
the semantic routing algorithm uses this data is beyond the scope of this
book; however, it has been shown that automated relaxation of queries can
lead to more robust searches. An important factor in order for the routing
algorithm to be effective in the long term is persistence. Nodes must have
a constant identifier within the network’s namespace if they are to retain
their confidence ratings. There is an initial forming stage where none of the
peers have ratings for any nodes, and nodes might be returned randomly
(or indeed using traditional routing methods). It has been observed that a
certain amount of random responses to all requests (even after the forming
stage) can avoid an effect called “overfitting,” which is when the confidence
data associated with the nodes becomes too rigid and inflexible. Semantic
routing is a reasonably new idea and as such is in its infancy as a technique. A
universal consensus on a specific algorithmic approach has not been reached
and there is not yet a paradigm under which research into p2p semantic
routing is conducted. The advent of semantic networking is making this an
important topic, and one that is sure to grow and flourish in future.
6.2.2 Dynamic Hierarchical Routing

Another P2P routing architecture has recently appeared, which tries to
combine the advantages of centralized and decentralized routing. Within
this approach, which is the basis for the FastTrack [5] architecture, servents
are elected at logon to become so called SuperNodes, if they offer sufficient
bandwidth and processing power. Further on they additionally receive a list
of already active SuperNodes, to which they connect. These SuperNodes
thus establish a network, with high bandwidth connections to each other and
high computing power at each SuperNode. If a servent without sufficient
capabilities logs on to this network, it is bound to one of the existing
Supernodes in its neighborhood. Thus, clusters are established, which
consist of several “normal” servents, and one SuperNode, which has higher
capabilities, i.e., a higher bandwidth connection and higher computing power.
After having connected to a SuperNode, the servent uploads information
about hosted data on to its SuperNode, and thus becomes “visible” to the
overlay network. As a normal servent has only one connection, i.e., the
connection to the SuperNode, it directs queries only to the SuperNode of
its cluster. Upon receiving a query, the SuperNode first searches its own
database, whether the demanded data is available in its own cluster. In this
is the case, the IP-addresses of the servents hosting the demanded data is
sent back to the querying servent. Otherwise, the SuperNode broadcasts
this query in the upper layer, namely the SuperNode layer, within which
all SuperNodes are connected to each other via one or more hops. Every
SuperNode, which receives this query, searches its database and in case of
success sends back the according IP-address of the servent of its cluster, to
the querying SuperNode. This SuperNode then forwards this response to the
querying servent. Thus the necessary bandwidth for a successful query can
be reduced significantly, as the query is only broadcasted in a small part of
the network, namely the SuperNode layer.
6.2.3 Query routing

Rohrs presented a concept to reduce the number of flooded query messages,
by routing these queries based on the search keywords (2001). The basic
idea of query routing in the virtual overlay network is, that servents
exchange their query routing tables with their neighbors periodically. The
query routing tables contain metadata of hosted content, i.e., keywords and
the corresponding IP-address, of the servent from which the metadata was
received. Any incoming query is then analyzed for its search keywords, and
then compared to the local query-routing table. If one of the search keywords
matches to one or more entries in the routing table, the query is forwarded
in the direction, given by the routing table, instead of being flooded to all
neighbors of the servent. If no match with the routing table can be found, the
query is forwarded to all neighbors of the servent, as long as the TTL-value
of the query message has not expired. To minimize the amount of bandwidth
necessary to propagate the routing tables, a variant of Bloom Filters are
used (Bloom, 1970). This means, that each keyword is hashed, and then all
keywords of the content of one servent are compressed in a bitmap. Thus not
a whole set of keywords and IP-addresses has to be exchanged periodically,
but only a comparatively small bitmap. Further on incremental updates
could also be used, if only small changes have taken place as the last routing
table has been propagated to its neighbors. However, the major problem
with the implementation of query-routing tables is again, how to keep them
up to date, if the network is very dynamic. The problem is, that routing
information for a certain file A which is hosted by the servent X, may still
propagate through the network, although the servent X is not anymore a
member of the network. Thus queries may be directed in a wrong direction,
which leads to useless traffic, and to unsatisfied users, as the content they
search for cannot be found anymore. A solution to this problem could be to
set a timer for every routing table entry. After the expiration, this routing
table entry is deleted again, to prevent any misleading routings. Further on,
the propagation reach of each routing table must be limited, to prevent the
routing table, from propagating through the whole network. This could be
done with a hop-counter, which avoids routing tables from being spread any
further, as soon as a certain value for the hop-count has been reached.
Figure 6.2: An example of query routing from peer n to m. Source: http://medi-

anet.kent.edu/surveys/IAD06S-p2psearch-alok/index.html
6.3 CLASSIFICATION OF P2P

We begin by looking at a taxonomy of P2P systems. This taxonomy is
derived from examining existing P2P systems. In general, we can categorize
the systems into three broad categories, centralized, decentralized, and
fully decentralized based on the availability of one or more servers, and to
what extent the peers depend on the services provided by those servers. As
expected, most of the research focuses on decentralized systems. Besides
these categories, there are also hybrid P2P systems that combine both
centralized and decentralized architectures to leverage the advantages of
both architectures. We shall examine each of these issues here.
6.3.1 Centralized P2P Systems

Centralized P2P systems beautifully mix the features of both centralized
(e.g., client–server) and decentralized architectures. Like a client-server
system, there are one or more central servers, which help peers to locate
their desired resources or act as task scheduler to coordinate actions among
them. To locate resources, a peer sends messages to the central server to
determine the addresses of peers that contain the desired resources (e.g.,
Napster, or to fetch work units from the central server directly. However,
like a decentralized system, once a peer has its information or data, it can
communicate directly with other peers (without going through the server
anymore). As in all centralized systems, this category of P2P systems is
susceptible to malicious attacks and single point of failure. Moreover, the
centralized server will become a bottleneck for a large number of peers,

potentially degrading performance dramatically. Finally, this type of system
lacks scalability and robustness. Some examples of this architecture include
Napster and BOINC.
6.3.2 Decentralized system

In a decentralized P2P system, peers have equal rights and responsibilities.
Each peer has only a partial view of the P2P network and offers data/
services that may be relevant to only some queries/peers. As such, locating
peers offering services/data quickly is a critical and challenging issue. The
advantages of these systems are obvious: (a) they are immune to single point
of failure, and (b) possibly enjoy high performance, scalability, robustness,
and other desirable features.
6.3.3 Fully decentralized system

In a P2P system of fully decentralized architecture, each peer is of equal
responsibilities and rights, so that none is superior to the other. Furthermore,
there are neither centralized servers nor other auxiliary mechanisms, e.g.,
“supernodes” to coordinate the operations among peers, including resource
location, replication and caching, etc. The system can run smoothly while
nodes joining or leaving the network at any time. Several existing P2P
systems belong to this category, such as the original Gnutella, FreeNet,
FreeHaven, Chord, PAST, OceanStore, etc. As mentioned before, they can
be further classified into two subcategories, i.e., unstructured P2P systems
and structured P2P systems, based on the criterion of “the structure of
overlay network.”
Unstructured P2P Systems

In unstructured P2P systems, the content resided on each peer has no
relationship to the “structure” of the underlying overlay network. That is
to say, each peer chooses the content to store at will. So given a query, it is
hard to know precisely the location where the results are. The solution is
to search all or a subset of the peers in the network. Usually, a lot of nodes
need to be checked before the desired files are found. Most of unstructured
P2P systems adopt broadcast-based query routing strategies to discover
expected resources, for example, BFS-based (breadth-first search) broadcast
in Gnutella. The advantage is that it can easily accommodate a highly
transient node population, as the query can be spread to a large number of

peers within a short time. The disadvantage is that it widely floods the query
to many peers in the network no matter whether they can answer the query
or not, which causes heavy network traffic of exponential query messages.
Therefore, this routing strategy is efficient as far as network bandwidth
consuming is concerned. Consequently, the scalability of an unstructured
system is problematic. Examples of the unstructured P2P systems are the
original Gnutella, FreeNet, and FreeHaven.
Structured P2P system

In a structured P2P system, there is a certain mechanism to determine the
location of files in the network; that is to say, files are placed at precisely
specified locations. For example, by applying a distributed hash function
(e.g., SHA-1) on both files and peers’ name, files are placed on the peers
whose hash values are numerically close to that of the files. Thus, a mapping
is built up between files and peers. Given a query, the location of desired
files can be decided quickly and deterministically, so it is unnecessary to
aimlessly visit unrelated nodes to find the answers to the query. As a result,
the efficiency of searching and routing can be improved greatly. Usually,
peers need to maintain some data structures (e.g., distributed hash table)
to guarantee the correctness and efficiency of query routing. When nodes
join and leave the network very frequently, the cost to maintain the routing
information is quite high. Systems such as Chord, PAST, and Ocean Store
belong to this category.
Hybrid P2P systems

The main advantage of centralized P2P systems is that they are able to
provide a quick and reliable resource locating. Their limitation, however,
is that the scalability of the systems is affected by the use of servers. While
decentralized P2P systems are better than centralized P2P systems in this
aspect, they require a longer time in resource locating. As a result, hybrid
P2P systems have been introduced to take advantages of both centralized
and decentralized architectures. Basically, to maintain the scalability,
similar to decentralized P2P systems, there are no servers in hybrid P2P
systems. However, peer nodes that are more powerful than others can be
selected to act as servers to serve others. These nodes are often called super
peers. In this way, resource locating can be done by both decentralized
search techniques and centralized search techniques (asking super peers),
and hence the systems benefit from the search techniques of centralized P2P
systems. Hybrid P2P systems draw advantages from the other types of P2P
architectures, i.e., centralized and fully distributed ones, while distinguish
themselves from the other two types by their elegant auxiliary mechanisms
that facilitate resource location. In some P2P systems of hybrid architecture,
there are some peers possessing much more powerful capabilities and
having more responsibilities than other peers, which are usually referred to
as “super” peers (or supernodes). These supernodes form an “upper level”
of a hybrid system, which provides similar services for the ordinary peers
as the central server does in a centralized P2P system. The common peers,
on the other hand, can enjoy much more services from the supernodes in
the “higher” layer, especially in the process of resource location. Though
supernodes share some similar features to the central server in centralized
P2P systems, it is easy to distinguish one from the other based on the
following metrics: (i) A supernode is not as powerful as the central server
of a centralized P2P system, and it is only in charge of a subset of peers in
the network. (ii) A server as in Napster just helps peers to locate desired
files without sharing any file by itself; however, a supernode has to not only
coordinate the operations among the peers under its supervision, but also
perform the same operations by itself and contribute its own resources as
the common peers do.
6.4 FIRST GENERATION OF P2P

Centralized directory model was the first peer-to-peer model that was widely
used. It is used in hybrid P2P systems, because it perfectly fits the definition:
majority of peers are equal, but some peers have more advanced functions
and are called servers. This is how this algorithm works: peers inform the
server about the files they are willing to share and server stores location
information of the shared files. When a peer wants to get some file it sends
a request to the server. Using location information that it has gathered, the
server finds peers containing the requested file and matches the request with
the best suited peer based on connection speed, size of the file or some other
parameter. After that peers do not need the server anymore and can negotiate
file exchange directly between them. Centralized directory model was used
in Napster, probably the most well-known P2P file sharing application. The
main disadvantage of centralized directory model comes from the fact that
when the number of peers grows, the size of the servers must also grow and
this implies a scalability limit. But as we can see from Napster’s experience,
this model works really well in most of the aspects and its main weakness
concerns copyright issues. The figure below shows an example of centralized
directory model.
6.4.1 Napster
Napster-CPP, also known as music exchange system, and other similar
systems have a constantly updated object directory maintained at central
Napster server (s). Nodes login to this server and send the list of files they
can offer, then issue queries to the server to find which other nodes hold
their desired files, and finally download the desired objects directly from the
object home. It has a Server-Client structure where there is a central server
system which directs traffic between individual registered users. The central
servers maintain directories of the shared files stored on the respective PCs
of registered users of the network. These directories are updated every time a
user logs on or off the Napster server network. Clients connect automatically
to an internally designated “metaserver” that acts as common connection
arbiter. This metaserver assigns at random an available, lightly loaded server
from one of the clusters. Servers appeared to be clustered about five to a
geographical site and Internet feed, and able to handle up to 15,000 users
each. The client then registers with the assigned server, providing identity
and shared file information for the server’s local database. In turn, the client
receives information about connected users and available files from the
server. Although formally organized around a user directory design, the
Napster implementation is very data centric. Although Napster’s centralized
database naturally avoids query routing and other problems of other P2P
systems, it is clear that such centralized approach has single point of failure
and very poor scalability. Another feature of this architecture is that it can
support partial-match queries (e.g., searching for all objects whose titles
contain two or more specific words. Napster was shut down as a result of
legal proceedings instituted against the operators of the Napster service by
the owners of the copyright in some of the material (i.e., digitally encoded
music) that was made available on it. The architecture of Napster is shown
in the figure below.
Figure 6.3: The Napster P2P. Source:http://www.i-programmer.info/babbages-

bag/650-peer-to-peer-file-sharing-.html? start=1
6.5 SECOND GENERATION P2P

Flooded requests model appeared next. In this model, there do not exist any
servers, and all peers are equal, which makes systems using this model to be
pure P2P systems. Here, peers do not inform anyone about the content they
are willing to share, instead when a peer wants to locate some file, it sends
a request to those peers it is directly connected to, if the requested file is
not found among them, each peer resend the request to peers it is connected
to, etc. This resending of the request is called flooding, and the common
number of flooding steps varies from 5 to 9. Flooded requests model is used
in Gnutella. In this application to join the system, the peer has to connect
to one of several known hosts which forward information about IP and port
address to other Gnutella peers. After that, peer can start sending requests.
Gnutella has shown to be popular, especially when the number of peers is
relatively small. However, when the number of peers grows, flooded requests
models start to consume a lot of bandwidth reducing the scalability of the
system. This is one of the problems, discovered in Gnutella. Another problem
concerned “freeriding.” Freeriding means downloading files from other
peers but not sharing them. According to research by Adar, more than 70%
of Gnutella users are free riders. Such behavior results in a smaller number
of files available in the system and decreases the level of anonymityas the
number of peers possessing the files decreases considerably; these peers
might be considered to behave like servers. The figure shown below is an
example of flooded requests model.
Figure 6.4: Gnutella. Source: http://slideplayer.com/slide/9079673/
6.5.1 Gnutella
Gnutella is a decentralized file-sharing system whose participants form a
virtual network and communicate peer-to-peer via the Gnutella protocol for
distributed file search. There is neither a centralized directory nor any precise
control over the network topology or object placement in such architecture
as the typical Gnutella. Gnutella is factually a decentralized file-sharing
system whose participants self-organize a virtual mesh network running in
a P2P fashion for distributed file search. To participate, a peer first connects
to a known Gnutella host. In other words, a node first must connect to a
known Gnutella node to get lists of some existed Gnutella nodes for start-up.
Gnutella’s software architecture is markedly different than that of Napster.
Upon receiving a message, the servent decrements the time-to-live (TTL)
field of the message. If the TTL is greater than 0 and the servent has never
seen the identifier of the message (loop detection), it resends the message
to all known peers. The servent also checks whether it should respond to
the message. If it receives a Query, for example, it checks its local file store
and responds with a QueryHit if it can satisfy the request. Responses are
routed along the same path as the originating message. As discussed above,
Napster uses a centralized server architecture, where a user logs on to a
server or group of Napster owned servers, connecting that user to others.
In contrast, Gnutella directly connects users and eliminates the need for an
intermediary server. A user connects directly with another user, who then
connects them with other users, and so on-creating a virtually limitless web
of users spreading throughout the Internet. If a user has linked to you, they
have also linked to virtually everyone to whom you have linked, and vice
versa. Gnutella has the following properties: i. Scalability. The broadcasting
mechanism of Gnutella is a two-edged sword. On one hand, because each

query may be broadcasted to as many nodes as possible in the network,
Gnutella is powerful at\discovering all potential results. On the other hand, as
more and more nodes join the Gnutella network and the nodes issue queries
continuously, the network may be congested with floods of messages.
Thus, the scalability of Gnutella is problematic. ii. Self-organization. When
a node connects to the Gnutella network at the first time (or even rejoins
after a departure or failure), it is just like a person entering a totally new
environment. It randomly chooses a node as its entry point and stays there.
As time goes, it becomes familiar with more nodes and builds connections
with them. These connections are not permanent. To make sure that queries
can be best and quickly satisfied, it is up to the node itself to decide which
connections are to be established and which established connections are to
be severed. Obviously, the node tends to maintain connections with those
nodes who have often answered its queries and have enough bandwidth.
From the viewpoint of the whole network, high-speed nodes will gradually
be placed in the central part of the topology, while low-speed ones will be
pushed to the edge of the topology. iii. Anonymity. Gnutella is a system with
good certain degree of anonymity. It uses a message-based broadcasting
mechanism to deliver a query. The broadcast based routing strategy is
influenced by the routing tables of quite a lot of Gnutella nodes, which are
dynamic and changing all the time. Therefore, it is almost impossible to
figure out from which nodes a query came or to which nodes the query would
go. However, the anonymity is broken when the original node chooses one
or several nodes to establish direct connection and download files. At this
phase, the IP addresses of the providers and the requesters are exposed to
each other. iv. Availability. As a node can connect to and disconnect from
the Gnutella network at any time without warning and because there is no
mechanism to control the availability and the stability of the replies from
other nodes, the availability is not guaranteed. Studies have shown that
only a small fraction of Gnutella nodes will be online long enough to share
files with other nodes. Therefore it cannot be guaranteed that queries can be
answered well, and the desired files can be downloaded successfully. When
it fails, the only available solution is to retry the query or download from
other peers.
6.5.2 BitTorrent
BitTorrent [www.bittorrent.com] is a popular peer-to-peer file-sharing
application designed particularly for downloading large files (including
video files). It is not intended for the real-time streaming of content but
rather for the initial downloading of files to be played back later. The
principal design feature in BitTorrent is the splitting of files into fixed-sized
chunks and the subsequent availability of chunks at various sites across
the peer-to-peer network. Clients can then download a number of chunks
in parallel from different sites, reducing the burden on any one particular
site to service the download (remembering that BitTorrent relies on the
capabilities of ordinary user machines and also that there may be many
simultaneous requests for popular files). This compares favorably to more
centralized strategies where a client would download a file from a server
using, for example, HTTP. In more detail, the BitTorrent protocol operates
as follows. When a file is made available in BitTorrent, a.torrent file is
created that holds metadata associated with that file including: i. the name
and length of the file; ii. the location of a tracker (specified as a URL), which
is a centralized server that manages downloads of that particular file; iii. a
checksum associated with each chunk, generated using the SHA-1 hashing
algorithm, that enables content to be verified following download. The use
of trackers is a compromise against pure peer-to-peer principles, but this
allows the system to easily maintain the above information in a centralized
manner. Trackers are responsible for keeping track of the download status
associated with a particular file. To understand the information held by the
tracker, it is necessary to stand back and consider the lifecycle of a given
file.Any peer with a complete version of a file (in terms of all its chunks)
is known asa seeder in BitTorrent terminology. For example, the peer that
initially creates the file will provide the initial seed for the file distribution.
Peers that want to download a fileare known as leechers, and a given leecher
at any given time will contain a number ofchunks associated with that
file. Once a leecher downloads all the chunks associatedwith a file, it can
become a seeder for subsequent downloads. In this way, files spreadvirally
through the network, with the spread stimulated by demand. Based on this,
thetracker maintains information about the current state of downloads of a
given file interms of the associated seeders and leechers.
6.5.3 Freenet
Like Gnutella, Freenet is a peer-to-peer, decentralized system. Each user’s
computer is labeled a “node,” which stores and retrieves encrypted files that
can be opened by text strings called “keys.” The nodes pass the keys back
and forth in an attempt to find the encrypted file that the key will unlock.
Each node knows only its immediate neighbors, and it is extremely difficult
to tell whether your requesting neighbor originated the search or simply

passed along another user’s request. When a file is found, it is stored on the
both the requesting user’s node and another user’s node along the request
stream. The encrypted file remains on both machines for a finite period of
time, phasing out files not regularly searched for and keeping alive more
popular files.
6.6 THIRD GENERATION P2P

Document routing model is the most recent model. It is used in pure P2P
systems, where all peers are equal (Milojicic, D. S. et. al, 2000). In this
model each peer is assigned an ID and each peer knows several other peers.
When a peer wants to share a file, the name and the contents of the file are
hashed, producing an ID which is assigned to that file. Then the file is routed
to the peer, whose ID is most similar to the file ID. This way, each peer is
responsible for a range of file IDs. When a peer wants to get some file, it
sends a request containing the ID of the file. This request is forwarded to the
peer whose ID is most similar to the file ID. After the file has been located
it is transferred to the peer that has requested it. Each peer that participates
in either of the routing operations keeps a local copy of the file. Figure4
shows an example of document routing model. Document routing model
is used in Freenet, software application that has been around for several
years, but is still under development. Document routing model has proved
to be effective in networks with large number of peers. But the problem
with this model comes from the fact that ID of the requested file must be
known before sending a request, which makes the search more difficult to
implement. A peer that wants to locate a specific file has to know what
information was used by the peer that is sharing the file when the ID of
the file was created. Hashing different filename or contents will result in a
different ID and the required file will not be found. Another problem is so
called “islanding problem,” when peers split into groups with no connection
between each other. In the following 4 sections we will look at 4 different
algorithms that implement the document request model: Chord, Tapestry,
Pastry and CAN. Although they differ between each other, they all have the
same goal: decreasing the number of hops needed to locate the requested
file.
6.6.1 Chord
Chord is a protocol for looking up nodes by a key in a decentralized P2P
system. “The Chord protocol supports just one operation: given a key,
it maps the key onto a node. Depending on the application using Chord,
that node might be responsible for storing a value associated with the key.
Chord uses a variant of consistent hashing to assign keys to Chord nodes.
Consistent hashing tends to balance load, as each node receives roughly the
same number of keys, and involves relatively little movement of keys when
nodes join and leave the system” (Ion Stoica et.al, 2001). Each node can then
have some arbitrary value, but that is outside of the scope of the protocol. It
provides a single key operation lookup (k): which provides the location of a
node responsible for that key k. It can thus be a key component of adistributed
hash table. It does this without using any special nodes, unlike previous peer-
to-peer systems such as Napster or DNS. DNS, for example, comes with a
set of special root servers pre-programmed. This makes the Chord protocol
more decentralized and resilient to failure. Chord usesconsistent hashing,
which means the values of keys are evenly distributed despite nodes joining
and leaving the system. One key innovation is that the consistent hashing
in a distributed hash table doesn’t require a node to know about all other
nodes. Instead, each node only knows about a select set of other nodes. This
way of implementing routing means that it only takes on the order ofO (log
n) operations to find the value you are looking for, despite nodes joining
and leaving. Thenetwork topologycan be thought of as a ring of nodes. If
we look up a key at a node and it doesn’t have the value, the node can point
us in the right direction. It does this using a finger table which includes the
address of other nodes. By using some nifty modular arithmetic this ensures
we will always get closer to the actual value.
6.6.2 Tapestry
Tapestry is an extensible infrastructure that provides decentralized object
location and routing focusing on efficiency and minimizing message
latency. This is accomplished as Tapestry creates locally optimal routing
tables from initialization and preserves them to lessen routing stretch.
Furthermore, Tapestry allows object distribution determination according to
the needs of a given application. Similarly Tapestry allows applications to
implement multicasting in the overlay network. Tapestry is an infrastructure
that provides decentralized object location and routing (DOLR). Similar to
Chord, Tapestry routes messages to nodes based on the keys assigned to
the messages. What distinguishes Tapestry from Chord is the introduction
of location mapping, which decreases the search time. Location mapping
is described in the following paragraphs. Tapestry has been implemented
in such real-life applications as Bayeux, Mnemosyne and OceanStore. In

Tapestry each node and object (e.g., file) are assigned unique ids using
a hash function (e.g., SHA-1). Each node has a routing table, which lists
IDs and IP addresses of the nodes that it communicates with. These nodes
are called its neighbors and the routing table is called neighbor table.
DOLR communication is packet-based. It supports 4 types of operations:
PublishObject publishes the object on the local node, UnpublishObject
removes location mappings, meaning that the object is no longer shared,
RouteToObject routes message to the location of the object, RouteToNode
routes message to the node. Routing is performed digit by digit and at each
node possible IDs are chosen from a neighbor table of this node. Figure6
shows an example of the path taken by a message with origin at node 5230
and destination at node 42AD. When an object is published by a node, a
mapping message is sent from this node to the node whose ID is most similar
to the ID of the published object. Each node on the path of the message
stores a location mapping, instead of a copy of the object like in Chord.
When some node wants to locate an object, it does not have to find the node
whose ID is most similar to the ID of the object in question, it is enough
to find any node that stored the location mapping. Tapestry proves to be
scalable, with the cost of lookup of logbN, where N is the number of nodes
and b is the base of the IDs.
6.6.3 Pastry
Pastry is an overlay and routing network for the implementation of a
distributed hash table (DHT) similar to Chord. The key-value pairs are
stored in a redundant peer-to-peer network of connected Internet hosts.
The protocol is bootstrapped by supplying it with the IP address of a peer
already in the network and from then on via the routing table which is
dynamically built and repaired. It is claimed that because of its redundant
and decentralized nature there is no single point of failure and any single
node can leave the network at any time without warning and with little or no
chance of data loss. The protocol is also capable of using a routing metric
supplied by an outside program, such as ping or traceroute, to determine the
best routes to store in its routing table. This P2P system was analyzed in a
publication, written by Antony Rowstron and Peter Druschel, awarded ten-
yearbest paper award from Middleware in 2011;
A Pastry system is a self-organizing overlay network of nodes, where
each node routes client requests and is capable of storing application-specific
objects. Any computer that is connected to the Internet and runs the Pastry
node software can act as a Pastry node, subject only to application-specific

security policies. Inserted objects are replicated across multiple nodes. The
system ensures, with high probability, that the set of nodes over which an
object is replicated is diverse in terms of geographic location, ownership,
administrative entity, network connectivity, rule of law and so forth. Each
node in the Pastry peer-to-peer overlay network is assigned a 128-bit node
identifier (nodeId). The nodeId is used to indicate a node’s position in a
circular namespace, which ranges from to 2128 – 1. This nodeId is drawn
randomly when a node joins the system. It is assumed that the nodeId is
generated by a high-quality uniform random number generator, so that the set
of existing node identifier is uniformly distributed in the 128-bit namespace.
The fundamental capability Pastry provides is to efficiently route messages
among the nodes in the system. Specifically, given a destination id (destId)
of at least 128 bits, Pastry routes an associated message to the node whose
nodeId is numerically closest to the 128 most significant bits of the destId
associated with the message, among all live nodes. Furthermore, it is assumed
that each object is assigned an object id (objId) that is at least 128 bits long.
The set of existing objIds is further assumed to be uniformly distributed. To
insert an object, a client asks Pastry to route a message to the node whose
nodeId is numerically closest to the 128 most significant bits of the objId;
that node then stores the object. To look up an object, a client similarly sends
a message using the objId as the destId; the receiving node responds with
the requested object. To achieve high availability and/or load balancing, an
object is stored on the k nodes whose nodeIds are numerically closest to the
objId. The object is then available as long as one of the k nodes is live and
reachable (in the Internet) from a client. Furthermore, Pastry ensures, with
high probability, that a lookup message is routed to one of the k nodes that is
near the client. This provides for load balancing, reduced network load and
low client response time. (Rowstron, A; Druschel, P. 2001).
6.7 CURRENT GENERATION P2P
6.7.1 Oneswarm
OneSwarm is a new BitTorrent based application for distributing data
over the Internet. As already known, the BitTorrent protocol have some
weaknesses regarding security concerns, and OneSwarm was developed as
an effort to fix these problems. OneSwarm is what is called a F2F (friend-to-
friend) protocol which means that users only can connect to users with whom
they are friends with. This way a third party can’t connect to a network in
which it has no friends, and thus cannot see the traffic inside the network.
This is however not the only measure taken to ensure better privacy of
the transfers. All data is encrypted with the RSA encryption algorithm, so
that sniffing a connection won’t give away the content of the traffic either.
OneSwarm is a free application that helps you to share your data or file in a
secure manner and with a full control, when you install the application you
will notice that it will automatically open your default browser on localhost
http://127.0.0.1:29615/.First you start by inviting your friend to server by
clicking invite button OneSwarm will launch your local e-mail client to
send invitation to different user with a unique code, this code is as one-time
password that will be used to connect the node.OneSwarm is illustrated in
the figure below. Bob downloads public data using One-Swarm’s backwards
compatibility with existing BitTorrent implementations, and makes the
downloaded file available to other One-Swarm users. Alice downloads the
file from Bob without attribution using OneSwarm’s privacy-preserving
overlay, but she is then free to advertise the data to friends. Advertisements
include a cryptographic capability, which allows only permitted friends to
observe the file.
Figure 6.5: Range of data sharing scenarios supported by OneSwarm.

Source:http://www.sectechno.com/oneswarm-a-secure-p2p-file-sharing-
utility/
REFERENCES
1. Adar, E., & Huberman, B. (2000). A. Free Riding on Gnutella.
2. Bloom, B. (1970 July). Space/time trade-offs in hash coding with
allowable errors.CACM, 13(7), 422-426.
3. Druschel, P., & Rowstron, A. (2001a). Pastry: Scalable, decentralized
object location and routing for large-scale peer-to-peersystems.
Middleware.
4. Druschel, P. & Rowstron, A. (2001b May). PAST: A large-scale,
persistent peer-to-peer storage utility. Proceedings of the eighth
workshop on hot topics in operating systems (HotOS-VIII)(pp. 75-80).
Germany:Schloss Elmau.
5. Rohrs, C. (2001). Query routing for the gnutella network. Retrieved from
http://www.limewire.com/developer/query_ routing/keyword%20
routing.htm. dec
CHAPTER 7
SECURITY AND PRIVACY
“Security in a computer system is strongly related to the notion of depend-

ability. Informally, a dependable computer system is one that we justifiably
trust to deliver its services.”
-Laprie
CONTENTS
7.1 Concepts of Security.............................................................................................. 138
7.2 Kerberos................................................................................................................ 144
7.3 SSL Security........................................................................................................... 145
7.4 Firewall................................................................................................................. 145
7.5 Authorization......................................................................................................... 146
7.6 Auditing................................................................................................................ 148
7.7 Digital Signatures.................................................................................................. 148
7.8 Cryptography......................................................................................................... 152
References................................................................................................................... 161
The security techniques in distributed systems are the important issues. Several
elements of distributed system security are identified, like authentication,
authorization, encryption and system protection. In initial days, the security
management environment was based on single authority systems but now the
focus is on the development per activity, authorities and groups with shared
responsibilities. The general security attacks on the distributed systems
are eavesdropping, masquerading, and message tempering, replaying the
message and denial of services. The trustworthiness of distributed systems
is important in a number of environments. Having discussed distributed
system architecture in the previous chapters; this chapter enumerates and
analyzes the factors affecting security in distributed systems and the various
tools in the framework used in securing these systems.
7.1 CONCEPTS OF SECURITY

There is a general need to protect the integrity and confidentiality of
information and other resources belonging to individuals and organizations
in both the real and digital world. It stems from the aspiration to share
resources. In the physical world, organizations implement security policies
that cater to the sharing of resources within specified limits. For example,
a company may permit entry to its buildings only to its employees and
accredited visitors. A security policy for documents may specify groups of
employees who can access classes of documents, or it may be defined for
individual documents and users.
Security policies are enforced with the help of security mechanisms.
For example, access to a building may be controlled by a reception clerk,
who issues badges to accredited visitors, and enforced by a security guard
or by electronic door locks. Access to paper documents is usually controlled
by concealment and restricted distribution. In the electronic world, the
distinction between security policies and mechanisms is equally important;
without it, it would be difficult to determine whether a particular system
was secure. Security policies are independent of the technology used, just as
the provision of a lock on a door does not ensure the security of a building
unless there is a policy for its use (for example, that the door will be locked
whenever nobody is guarding the entrance). The security mechanisms that
we describe here do not in themselves ensure the security of a system. In the
section, we outline the requirements for security in various simple electronic
commerce scenarios, illustrating the need for policies in that context. The
provision of mechanisms for the protection of data and other resources in
Security and Privacy 139
distributed systems while allowing interactions between computers that are

permitted by security policies is the concern of this chapter. The mechanisms
that we shall describe are designed to enforce security policies against the
most determined attacks.
Confidentiality refers to the property of a computer system whereby
its information is disclosed only to authorized parties. Integrity is the
characteristic that alterations to a system’s assets can be made only in an
authorized way. In other words, improper alterations in a secure computer
system should be detectable and recoverable. Major assets of any computer
system are its hardware, software, and data.
Another way of looking at security in computer systems is that we
attempt to protect the services and data it offers against security threats.
There are four types of security threats to consider (Pfleeger, 2003):
i. Interception
ii. Interruption
iii. Modification
iv. Fabrication
Simply stating that a system should be able to protect itself against all
possible security threats is not the way to actually build a secure system. What
is first needed is a description of security requirements, that is, a security
policy. A security policy describes precisely which actions the entities in a
system are allowed to take and which ones are prohibited. Entities include
users, services, data, machines, and so on. Once a security policy has been
laid down, it becomes possible to concentrate on the security mechanisms
by which a policy can be enforced. Important security mechanisms are:
i. Encryption
ii. Authentication
iii. Authorization
iv. Auditing
7.1.1 Encryption
We have already identified the need for authentication, both of the client
and the server. Client authentication usually involves authentication of the
principal. Server authentication is important not only because of the threat
of active tapping (Trojan Horse) but also because many RPC binders only
offer hints as to where a service is located. If it crashes, it may be replaced by
another, totally different server, but the client needs to know of this mismatch
so that the binder may be consulted again. Cryptography can be used for
such purposes. A related term is message integrity, often called message
authentication. It is often important to be sure that a received message has
not been tampered with in transit. Sometimes there is no requirement for
secrecy of the message in transit; sometimes there is. A form of strong
sumcheck based on cryptographic techniques is appended to messages for
such purposes. This is sometimes called a digital signature or a message
authentication code (MAC).
Encryption is widely used on the Internet to protect user information
being sent between a browser and a server, including passwords, payment
information and other personal information that should be considered
private. Organizations and individuals also commonly use encryption to
protect sensitive data stored on computers, servers and mobile devices like
phones or tablets.
Unencrypted data, often referred to as plaintext, is encrypted using an
encryption algorithm and an encryption key. This process generates cipher
text that can only be viewed in its original form if decrypted with the correct
key. Decryption is simply the inverse of encryption, following the same
steps but reversing the order in which the keys are applied. Today’s most
widely used encryption algorithms fall into two categories: symmetric and
asymmetric. These two categories are explained succinctly later in this
chapter. The primary purpose of encryption is to protect the confidentiality
of digital data stored on computer systems or transmitted via the Internet
or any other computer network. A number of organizations and standards
bodies either recommend or require sensitive data to be encrypted to
prevent unauthorized third parties or threat actors from accessing the data.
For example, the Payment Card Industry Data Security Standard requires
merchants to encrypt customers’ payment card data when it is both stored at
rest and transmitted across public networks.
7.1.2 Authentication
There are several steps necessary in providing authentication in a distributed
environment. The first step is authenticating or verifying the identity of a
user. There are three basic methods for accomplishing this. First, one may
verify a user by something that is known by the user such as a password, the
most popular method although not necessarily the most secure. The second
method involves something that is possessed by a user, such as a key. The
third method involves something the user is, such as the user’s fingerprints
or retina patterns, the most secure and expensive method. Observe that
up until this point, these methods are all possible to use on a centralized
system as well. A distributed operating system must also accommodate the
following concerns.
• Eavesdropping: How do we prevent someone from eavesdropping
on the communication line?
• Multiple password management: If we are accessing multiple
systems, does every system keep a copy of the user ID and
password? Every database, storing authentication information,
is a target for a system security loophole. Furthermore, do we
need to present our password every time we want to accomplish
something?
• Replay: Someone could copy authentication information while it
is transmitted on the network, even if it is encrypted, and replay it
at a later time, thus allowing inappropriate access.
• Trust: Should authentication be unilateral or should the user be
able to verify and have confidence that the service being utilized is
legitimate as well. A centralized system trusts itself; a distributed
system has to find a way to trust others.
A common solution to these concerns is using one of the certificate
management systems. A certificate is a computer-generated, frequently time-
valid, authenticated packet of information utilized in distributed systems
to allow easy access to the various resources. The time-valid feature helps
prevent replay at a later time. This may be accomplished with a timestamp
or with a nonce. Anonceis a random value unique for each communication.
Thus, no two communications share a nonce and replays are easy to
detect. There are two basic approaches to certificate management. The first
approach involves utilizing certificate lists that contain a list of certificates
from a trusted certificate authority and is exemplified by X.509. Any service
wishing to verify an identity must examine a list to verify the authenticity of
the client. The second approach involves a centralized certificate distribution
center where clients obtain a certificate for each service that the user they
wish to use. The client then presents this service certificate when utilizing
a service.
1. Authentication based on shared keys

The authentication process based on shared keys is explained better by
Reza Nayebi S. in a 2015 journal titled Security Techniques in Distributed
Systems.
He described it as thus; “First Alice sends his identity to Bob (message
1) and suggests that wants to establish a communication channel between
them. Then B sends the challenge RB to A (message 2).” Such a challenge
can be a random number. A must encrypt the challenge with KA, B secret
key, which is shared by Band sends the encrypted challenge to B (message
3). When B receives a reply from KA, B (RB) to its own challenge RB, it
can decrypt the message using the shared key to check whether including
RB. In this way, she knows A exists on the other side and determines who
else needed for encryption of RB with RA, B. B demonstrates that speaks
with A, but A still did not prove speaks with B, so it sends the challenge RA
(message 4) that it is replied with return of KA, B (RA)(message 5). When
A decodes this by KA, B and RA see itself, it knows speaks with B. In this
way, we need N hosts for management of (N (N-1))/2 keys.
Figure 7.1: Authentication based on shared keys.
Source: http://csis.pace.edu/~marchese/CS865/Lectures/Chap9/Chap-
9New/Chapter9.html
2. Authentication Using a Key Distribution Center

Reza further to describe another authentication method which is the using of
a key distribution center (KDC). KDC collaborates with every other host for
a secret key, but any pair of hosts does not require to have shared key. With
KDC, it is necessary to manage N keys. This view is shown in Figure 3. A
initially sends a message to the KDC and wants to talk with B. Ali returns a
message that contains secret shared keys KA, B that A can uses it. Moreover,
KDC also sends the shared key KA, B to B that is encrypted with secret
key KB, KDC. TheNeedham–Schroeder authentication protocol is designed
based on this model. i. This KDC shares a secret key with each of the hosts
ii. No pair of hosts is required to have a shared secret key as well. Iii. Using a
KDC requires that we manage N keys instead of N (N - 1)/2 iv. IfAlicewants
to set up a secure channel with Bob, she can do so with the help of a (trusted)
KDC. v. The KDC hands out a key to both Alice and Bob that they can use
for communication,
Figure 7.2: Principle of using a KDC.
Source: http://csis.pace.edu/~marchese/CS865/Lectures/Chap9/Chap-
9New/Chapter9.html
3. Authentication using public key encryption

The last authentication method involves the application of public key.First
person Alice, initiates sending challenge RA to person B, which is coded by
its public key K+B. Bob must decrypt the message and send a challenge to
Alice. As Bob is the only person who can decrypt this message using the
private key related to the public key of Alice, Alice realizes talking to Bob.
When Bob receives the channel establishment request from Alice, it returns
the decrypted challenge accompanying its own challenge RB to authenticate
of Alice and generate session key KA, B. An encrypted message with public
key K+A related to A includes Bob response to the challenge Alice, own
challenge RB and session key that is shown as message 2 in the figure
below. Only Alice is able to decrypt the message using the private key K-A
related to K+A. Finally, Alice returns his response to the challenge B using
the session key K A, B which is produced by Bob. Therefore, it has proved
that can decode messages 3,and in fact, Bob talks to A (Reza, N. S, 2015).
Overview authentication protocol utilizes public key cryptography is shown

in the figure below.
Figure 7.3: Mutual Authentication using public key encryption.
Source: http://csis.pace.edu/~marchese/CS865/Lectures/Chap9/Chap9New/
Chapter9.html
7.2 KERBEROS
The Kerberos system is a widely used implementation of secure
communication channels, based on the DES encryption scheme (see Schiller,
Steiner et al.). Integrated into the DCE environment, Kerberos is quite
popular in the UNIX community. The approach genuinely offers a major
improvement in security over that which is traditionally available within
UNIX. Its primary limitations are, first, that SSL security dominates in the
Internet and Web, making Kerberos increasingly “non-standard.” Secondly,
applications using Kerberos must be modified to create communication
channels using the Kerberos secure channel facilities. Although this may
seem to be a minor point, it represents a surprisingly serious one for
potential Kerberos users, as application software using Kerberos is not yet
common. Nonetheless, Kerberos has had some important successes any
years ago. Kerberos per-se is perhaps less important than the basic ideas it
illustrates. The basic Kerberos protocols revolve around the use of a trusted
authentication server, which creates session keys between clients and servers
upon demand. The basic scheme is as follows. At the time the user logs in,
he or she presents a name and password to a log-in agent, which runs in
a trusted mode on the user’s machine, and establishes a secured channel
to the Kerberos authentication server at boot time. Having logged in, the
user is able to connect securely to various applications using Kerberos as an
intermediary. The role of Kerberos is to mediate during connection setup,
helping the client and server to authenticate one-another and to agree on a

key for use to protect their shared communication channel. The Kerberos
authentication server keeps a database of user names and passwords, and
of course also remembers the key it negotiated with the log-in agent at boot
time. It decrypts the request, verifies that Ken Birman’s password was really
used to sign it, and then creates a “certificate” containing information by
which each end-point can validate the other, encrypting the piece destinated
for use by Fromages.com with a secret key known only to Fromages.
com, and the piece destinated for the user’s computer with the session key
employed by the log-in agent. It sends this back to the log-in agent, which
decrypts it and extracts the two pieces of the certificate.
7.3 SSL SECURITY

The Secure Sockets Layer (SSL) standard defines a scheme for obtaining
security over a TCP channel, typically between a Web browser and a secure
Web server to which it connects. SSL consists of two elements: a chain of
trust model used to find a trustworthy authentication server, and a protocol
by which a client system can obtain security certificates containing a security
key (normally, an RSA public key) from that authentication server and then
use it to create a secured TCP connection to the target platform. In the SSL
model, unlike Kerberos, the focus is on establishing trust in the client that
it is talking to the correct server; the server is expected to authenticate
the client using some other end-to-end mechanism (a password, or a visa
card, etc). The chain of trust model works as follows. A client system is
pre-loaded with a security key and network address for an initial directory
server. For example, the Microsoft Windows platform has a preinstalled
public key and network address by which it can contact a Microsoft security
directory service, and the Netscape browser has a preinstalled key and
address for a Netscape directory service. This information is maintained
using a mechanism designed to be as tamper-proof as possible
7.4 FIREWALL
So far, we have shown how protection can be established using cryptographic
techniques, combined with some implementation of an access control
matrix. These approaches work fine as long as all communicating parties
play according to the same set of rules. Such rules may be enforced when
developing a standalone distributed system that is isolated from the rest of
the world. However, matters become more complicated when outsiders are
allowed to access the resources controlled by a distributed system. Examples
of such accesses including sending mail, downloading files, uploading tax
forms, and so on. To protect resources under these circumstances, a different
approach is needed. In practice, what happens is that external access to any
part of a distributed system is controlled by a special kind of reference
monitor known as a firewall (Cheswick and Bellovin, 2000; and Zwicky
et al., 2000). Essentially, a firewall - disconnects any part of a distributed
system from the outside world. All outgoing, but especially all incoming
packets are routed through a special computer and inspected before they are
passed. Unauthorized traffic is discarded and not allowed to continue. An
important issue is that the firewall itself should be heavily protected against
any kind of security threat: it should never fail.
Figure 7.4: Operation of Web Application Firewall.
Source: https://docs.microsoft.com/en-us/azure/application-gateway/applica-
tion-gateway-web-application-firewall-overview
7.5 AUTHORIZATION
Authorization is the process of determining whether an already identified and
authenticated user is allowed to access information resources in a specific
way. Authorization is often the responsibility of the service providing access
to a resource. For example, if a user tries to access a file that resides on a file
server, it will be the responsibility of the file service to determine whether
the user will be allowed this type of access. Authorization can provide for
granular control and may distinguish between operations such as reading
or writing to a file, deleting a file, launching an executable file, etc. Before
authorization takes place, the user must be identified and authenticated.

Authorization relies on identification information to maintain access control
lists for each service. Operating systems typically facilitate the process of
authorization by providing authorization tools to applications. The operating
system will typically provide for a security kernel (or an operating system
Security Reference Monitor) that can be used to mediate access to resources
by making sure that the operation is authorized. Alternatively, applications
can implement their own authorization model, and Security Reference
Monitor. A user can be authenticated using a certain identity but he can
request to be authorized to access a resource under a different identity. When
the user explicitly requests this upon access to an application or resource,
this is typically referred to as authorization identity. When this is performed
by an application or service acting on behalf of the user, this is referred
to as impersonation. In the case of impersonation, a user may possess an
authentication identity that has been ascertained by the authentication
process. In addition, the user may temporarily or permanently use an
authorization identity, if the user is authorized by the operating system
or application to impersonate another user by assuming the other user’s
identity. Impersonation is very useful in client/server computing where a
server application running under a server account can access resources on
behalf of users connecting to that server. Impersonation also allows a user to
connect to a server using somebody else’s broader or more restricted access
permissions.Authorization is related to the problem of controlling access
to resources. All the authorization of client must be distributed by server,
which means the client can’t authorize any other clients. Authorization is
also related to access control in which they specify whether a sequence of
actions are permitted or forbidden to a specified object. Authorization is
implemented using restricted proxies. Proxy is defined as a token that allows
one to operate with the rights and privileges primary to grant the proxy.
Proxy can be used by any person and the person can do virtually anything
that the granted could do. Restricted proxy is a proxy that places conditions
during the usage. In this case the authorization server implemented using
restricted proxy does not specify that a particular principal is authorized to
use the specified service or access a particular object. The server grants a
restricted proxy allowing the authorized client to act as the authorization
server for the purpose to allow the client to access the accurate object or
service.
7.6 AUDITING
Auditing is a never-ending process Auditing system involve two parts, such
as logging and auditing, i.e., analyzing and notifying.Logging is collection
of data and information according to system or configuration parameters.
The logs should note who has entered the system as well as what they have
done. Auditing consists of analysis, i.e., study of information received
from the log entries and notification, which is the reporting of the results
of analysis study. An analyzer receives and analyzes recorded data to detect
some unwanted or forbidden event or problem, i.e., detect violation of
security policy. The result of analysis is sent by notifier as a notification
or alarm to the responsible entity, usually system administrator. Logs must
contain security levels of the involved subjects and objects, the action and
constraints, as well as the results, i.e., success or failure [3]. Auditing system
can be configured to record identity of the subjects and objects as well and
connect those to the security level action, and result. Some existing types of
auditing are NFS auditing and logging and auditing file system. Logging and
auditing file system is a system that records user level actions taken on file
in a human readable format. A system administrator is allowed to automate
checks for violation of security policy. The audit reports all violations to
the security policy. Traditional logging and auditing file system remove
important information, such as facility and level from the audit logs that can
negatively affect log analysis.
7.7 DIGITAL SIGNATURES

The basic idea is that a signature on a message can be created by only one
person, but checked by anyone. It can thus perform the sort of function in the
electronic world that ordinary signatures do in the world of paper. Signature
schemes can be deterministic or randomized: in the first, computing a
signature on a message will always give the same result; in the second, it
will give a different result each time you compute it. (The latter is more like
handwritten signatures; no two are ever alike but the bank has a means of
deciding whether a given specimen is genuine or forged). Also, signature
schemes may or may not support message recovery. If they do, then, given
the signature, anyone can recover the message on which it was generated; if
they don’t, then the verifier needs to know or guess the message before he
can perform the verification. (There are further, more specialized, signature
schemes, such as blind signatures and threshold signatures, but I’ll postpone
discussion of them for now.) Formally, a signature scheme, like public key
encryption scheme, has a keypair generation function that, given a random
input R will return two keys, σ R (the private signing key) and VR (the
public signature verification key) with the properties that
i. Given the public signature verification key VR, it is infeasible to
compute, the private signing key σ R.
ii. There is a digital signature function that, given a message M and
a private signature key σ R, will produce a signature SigσR (M).
iii. There is a signature verification function that, given the signature
SigσR (M) and the public signature verification key VR, will
output TRUE if the signature was computed correctly with σ R;
otherwise, it will output FALSE.
Just as handwritten signatures or physical thumbprints are commonly
used to uniquely identify people for legal proceedings or transactions, so
digital signatures (“digital thumbprints”) are commonly used to identify
electronic entities for online transactions. Adigital signatureuniquely
identifies the originator of digitally signed data and also ensures the integrity
of the signed data against tampering or corruption.
One possible method for creating a digital signature is for the originator of
data to create the signature by encrypting all of the data with the originator’s
private key and enclosing the signature with the original data. Anyone
with the originator’s public key can decrypt the signature and compare the
decrypted message to the original message. Because only someone with the
private key can create the signature, the integrity of the message is verified
when the decrypted message matches the original. If an intruder alters the
original message during transit, the intruder cannot also create a new valid
signature. If an intruder alters the signature during transit, the signature does
not verify properly and is invalid.
However, encrypting all data to provide a digital signature is impractical
for three reasons:
• The ciphertext signature is the same size as the corresponding
plaintext, so message sizes are doubled, consuming large amounts
of bandwidth and storage space.
• Public key encryption is slow and places heavy computational
loads on computer processors, so network and computer
performance can be significantly degraded.
• Encrypting the entire contents of information produces large
amounts of ciphertext, which can be used for cryptanalysis

attacks, especially known plaintext attacks (where certain parts of
the encrypted data, such as e-mail headers, are known beforehand
to the attacker).
Digital signature algorithms use more efficient methods to create digital
signatures. The most common types of digital signatures today are created
by signing message digests with the originator’s private key to create a
digital thumbprint of the data. Because only the message digest is signed, the
signature is usually much shorter than the data that was signed. Therefore,
digital signatures place a relatively low load on computer processors during
the signing process, consume insignificant amounts of bandwidth, and
produce small amounts of ciphertext for cryptanalysis. Two of the most
widely used digital signature algorithms today are the RSA digital signature
process and the Digital Signature Algorithm (DSA).
7.7.1 RSA data security digital signature process

The Rivest, Shamir and Adelman (RSA) design for a public-key cipher) is
based on the use of the product of two very large prime numbers (greater than
10100), relying on the fact that the determination of the prime factors of such
large numbers is so computationally difficult as to be effectively impossible
(Rivest et al., 1978). In the RSA digital signature process, the private key
is used to encrypt only the message digest. The encrypted message digest
becomes the digital signature and is attached to the original data. The figure
belowillustrates the basic RSA Data Security digital signature process.
To verify the contents of digitally signed data, the recipient generates a
new message digest from the data that was received, decrypts the original
message digest with the originator’s public key, and compares the decrypted
digest with the newly generated digest. If the two digests match, the integrity
of the message is verified. The identify of the originator also is confirmed
because the public key can decrypt only data that has been encrypted with
the corresponding private key.
Figure 7.5: Basic RSA Data Security Digital Signature Process. Source: https://
technet.microsoft.com/en-us/library/cc962021.aspx
7.7.2 Digital signature algorithm

Another widely used technology for creating digital signatures is the Digital
Signature Security Standard (DSS) that was developed by the National
Security Agency and adopted by the United States government as its digital-
signature standard. DSS defines the Digital Signature Algorithm (DSA),
which functions in a manner similar to RSA. Although similar to RSA,
DSA does not encrypt message digests with the private key or decrypt the
message digest with the public key. Instead, DSA uses special mathematical
functions to generate a digital signature composed of two 160-bit numbers
that are derived from the message digest and the private key. DSA uses
the public key to verify the signature, but the verification process is more
complex than RSA.
The digital signature processes for DSA and RSA are generally
considered to be of equal strength. However, DSA requires the use of the
SHA-1 message digest function to ensure strong digital signatures. RSA can
be used with other message digest functions (besides SHA-1) that might
produce weaker digital signatures. Because the DSA signature verification
process increases computer processor load significantly, relative to the
verification process for RSA (all other conditions being equal), the RSA
digital signature process generally provides better overall performance.
Because DSA is used only for digital signatures and makes no provisions
for data encryption (for example, to provide secure secret key exchange),
DSA is usually not subject to the export or import restrictions commonly

imposed on RSA cryptography technology. Therefore, DSS digital signature
technology can often be used when RSA digital signature technology cannot
be used because of government-imposed export or import restrictions.
7.7.3 Uses of digital signatures

Anyone with the public key can use it to perform a validity check of digital
signatures created by the private key. Only a digital signature created by the
appropriate private key decrypts and validates properly with the public key.
If a different private key was used to sign the data, the validity check fails.
If the contents of digitally signed data or the digital signature have been
tampered with or are corrupted, the validity check also fails. Valid digital
signatures can be used to perform the following functions:
i. Authenticate online entities.
ii. Verify the authorship or origin of digital data.
iii. Ensure the integrity of digital data against tampering.
Many security technologies use digital signatures. For example,
Microsoft® Authenticode® can be used to digitally sign software programs,
safeguarding them when they are distributed on the intranet or Internet to
help counter the threat of software tampering and the spread of viruses
and other malicious code. Likewise, the S/MIME protocol can be used to
digitally sign e-mail messages to ensure the integrity of mail.
7.8 CRYPTOGRAPHY
Encryption is the process of encoding a message in such a way as to hide
its contents. Modern cryptography includes several secure algorithms
for encrypting and decrypting messages. They are all based on the use of
secrets called keys. A cryptographic key is a parameter used in an encryption
algorithm in such a way that the encryption cannot be reversed without
knowledge of the key.
There are two main classes of encryption algorithm in general use.
The first uses shared secret keys—the sender and the recipient must share
knowledge of the key,and it mustnot be revealed to anyone else. The second
class of encryption algorithms uses public/private key pairs. Here the sender
of a message uses a public key—one that hasalready been published by
the recipient—to encrypt the message. The recipient uses acorresponding
private key to decrypt the message. Although many principals mayexamine
the public key, only the recipient can decrypt the message, because they
havethe private key.
Both classes of encryption algorithm are extremely useful and are used
widely in the construction of secure distributed systems.
Figure 7.6: Secured Communication via Encryption.
Source: http://www.nucrypt.net/overview_encryption.html
7.8.1 Publickey cryptography

The Public key encryption can be defined as encrypting the message with
the help of public key that can again be decrypted by the private key. It also
allows message integrity and confidentiality. In the public key cryptography
approach the asymmetric key algorithm (Stallings (2004)) is used in place
of symmetric key algorithm. The mathematically related key pair is used
to design the asymmetric key algorithm. This involves two types of keys,
i.e., a secret private key and a public key. With the help of these keys a
digital signature is being created by using the private key which provides the
protection and the authenticity of the message which can be verified by using
the public key. Moreover, asymmetric key algorithm is used in the different
techniques used in the public key cryptography. It is defined as the key used
to encrypt a message by using the same key which is used to decrypt the
message. There is two cryptographic pair of keys: a public key and a private
key. The private key is kept confidential whereas the public key may be
broadly spread (Stallings (2004)). Primarily and broadly used technology
around the world is public key cryptography. Various cryptographic
algorithms and cryptosystems are used to achieve the desired goals. Various
transport layer security; Pretty Good Privacy (PGP) and Gnu Privacy Guard
(GPG) are used as internet standards in this approach (Stallings, 2004).
It may be further being pointed that the public-key cryptography has a

fundamental problem of the confidence of the public key. In this system a
user has to trust irrespective of the fact that whether it is correct or belongs
to some other person or it is replaced by some other entity or replaced by the
third party which is malicious. The standard approach to rectify this problem
is to use a Public-Key Infrastructure (PKI). The public-key infrastructure
is used in one or more third parties who is known as certificate authorities
and certify ownership of key pairs. The public-key cryptography is divided
into two keys, i.e., Public key and Private Key for which it may be noted
that noted that; i. it is computationally easy for a party B to generate a pair
(public key PUb, private key PRb). - it is computationally easy for a sender
A, knowing the public key and the message to be encrypted, M, to generate
the corresponding cipher text C E PU M (,) b = (4.1)
ii. it is computationally easy for the receiver B to decrypt the resulting cipher
text using the private key to recover the original message: MD PR C D PR
E PU M (,) [, (,)] b b b = (4.2) iii. it is computationally infeasible for an
adversary, knowing the public key, PUb, to determine the private key, PRb.
iv. It is computationally infeasible for an adversary, knowing the public key,
PU and a cipher text, C, to recover the original message, M.
7.8.2 Cryptographic algorithm

Cryptographic algorithms are sequences of processes, or rules, used to
encipher and decipher messages in a cryptographic system. In simple terms,
they’re processes that protect data by making sure that unwanted people
can’t access it. These algorithms have a wide variety of uses, including
ensuring secure and authenticated financial transactions.
Most cryptography algorithms involve the use of encryption, which
allows two parties to communicate while preventing unauthorized third
parties from understanding those communications. Encryption transforms
humanly readable plaintext into something unreadable, also known as
ciphertext. The encrypted data is then decrypted to restore it, making it
understandable to the intended party. Both encryption and decryption
operate based on algorithms.
There are many different types of cryptographic algorithms, though most
of them fit into one of two classifications namely symmetric and asymmetric.
Some systems, however, use a hybrid of both classifications. Symmetric
algorithms, also known as symmetric-key or shared-key algorithms, work
by the use of a key known only to the two authorized parties. While these
can be implemented in the form of block ciphers or stream ciphers, the

same key is used for both encrypting and decrypting the message. The Data
Encryption Standard (DES) and Advanced Encryption Standard (AES) are
the most popular examples of symmetric cryptography algorithms.
Symmetric algorithms are usually much faster than asymmetric
algorithms. This is largely related to the fact that only one key is required.
The disadvantage of shared-key systems, however, is that both parties know
the secret key. Additionally, as the algorithm used is the public domain, it is
actually the key that controls access to the data. For these reasons, the keys
must be safe-guarded and changed relatively frequently to ensure security.
The need to securely distribute and manage large numbers of keys means
most cryptographic processes use a symmetric algorithm to efficiently
encrypt data and use an asymmetric algorithm to securely exchange the
secret key.
While cryptographic algorithms are used to provide security, they
are not completely secure. The suboptimal system can be infiltrated, and
sensitive information can be compromised as a result. Rigorous testing
of the algorithms, therefore, especially against established standards and
identified weaknesses is vital to assuring the utmost security.
Figure 7.7: Symmetric Encryption.

Source: https://blockgeeks.com/guides/cryptocurrencies-cryptography/
Asymmetric algorithms rely on a pair of keys—a public key and a
private key. The public key can be revealed, but, to protect the data, the
private key must be concealed. Additionally, encryption and decryption
of the data must be done by the associated private and public keys. For
example, data encrypted by the private key must be decrypted by the
public key and vice versa. RSA is one of the most common examples of
this algorithm. The public key can be shared with everyone, whereas the
private key must be kept secret. The RSA encryption algorithm is the most
widely used public key algorithm, partly because both the public and the
private keys can encrypt a message; the opposite key from the one used to
encrypt a message is used to decrypt it. This attribute provides a method of
assuring not only confidentiality but also the integrity, authenticity, and non-
repudiation of electronic communications and data at rest through the use of
digital signatures.
Figure 7.8: Asymmetric Encryption.
Source: https://blockgeeks.com/guides/cryptocurrencies-cryptography/
A message is encrypted by the sender applying some rule to transform
the plaintext message (any sequence of bits) to a ciphertext (a different
sequence of bits). The recipient must know the inverse rule to transform
the ciphertext back into the original plaintext. Other principals are unable to
decipher the message unless they also know the inverse rule. The encryption
transformation is defined with two parts: a function E and a key K. The
resulting encrypted message is written as {M} K
E (K, M) = {M} K
The encryption function E defines an algorithm that transforms data
items in plaintext into encrypted data items by combining them with the
key and transposing them in a manner that is heavily dependent on the value
of the key. We can think of an encryption algorithm as the specification of
a large family of functions from which a particular member is selected by
any given key. Decryption is carried out using an inverse function D, which
also takes a key as a parameter. For secret-key encryption, the key used for
decryption is the same as that used for encryption:
D (K, E (K, M)) = M
Because of its symmetrical use of keys, secret-key cryptography is often

referred to as symmetric cryptography, whereas public-key cryptography
is referred to as asymmetric because the keys used for encryption and
decryption are different, as we shall see below. In the next section, we
describe several widely used encryption functions of both types.
Table 7.1: Conventional and Public-key Encryption
Conventional encryption Public key encryption

Needed to work Needed to work
The same algorithm with One algorithm is used for encryption and de-
the same key is used for cryption with a pair of keys, one for encryp-
encryption and decryption. tion and one for decryption
The sender and receiver The sender and receiver must each have one of
must share the algorithm the matched pairs of keys (not the same one)
and the key.
Needed for security Needed for security
The key must be kept se- One of the two keys must be kept secret.
cret.
It must be impossible or at It must be impossible or at least impractical to
least impractical to deci- decipher a message if no other information is
pher a message if no other available.
information is available.
Knowledge of the algo- Knowledge of the algorithm plus one of the
rithm plus samples of ci- keys plus samples of cipher text must be insuf-
pher text must be insuffi- ficient to determine the other key.
cient to determine the key.
Source: http://shodhganga.inflibnet.ac.in/bitstream/10603/72955/10/10_
chapter%204.pdf
7.8.3 Cryptographic Hash Functions

Cryptographic hash functions come in different shape and size. There are
basically two main categories of hash functions. Hash functions that depends
on a key for their computation, usually known as Message Authentication
Code or MAC and hash functions that do not depend on a key for their
computation, generally known as un-keyed hash function or simply hash
function. All well-known hash functions are either based on a block cipher
or on modular arithmetic. The term hash function has been used in computer
science from quite some time and it refers to a function that compresses a
string of arbitrary input to a string of fixed length. However if it satisfies
some additional requirements, then it can be used for cryptographic

applications and then known as Cryptographic Hash functions. These are
one of the most important tool in the field of cryptography and are used
to achieve a number of security goals like authenticity, digital signatures,
pseudo number generation, digital steganography, digital time stamping etc.
[2] A hash function, is a function that takes some message of any length
as input and transforms it into a fixed-length output called a hash value, a
message digest, a checksum, or a digital fingerprint. A hash function is a
function;
f: D -> R, where the domain D = {0,1} which means that the ele-
ments of the domain consist of binary string of variable length; and the
range R = {0,1} n for some n >= 1, which means that the elements of the
range are binary string of fixed-length. So, f is a function which takes as in-
put a message M of any size and produces a fixed-length hash result h of size
n. A hash function f is referred to as compression function when its domain
D is finite, i.e., if the function f takes as input a fixed-length message and
produces a shorter fixed-length output. Two known hash functions are the
MD 5 and SHA algorithms.
1. MD 5 Hash Algorithm
The MD5 (1992) message-digest algorithm was designed as a strengthened
extension of the MD4 (1990) message digest algorithm. MD5 is slightly
slower than MD4. Both algorithms were developed by Ron Rivest. The
algorithm accepts an input message of arbitrary length and produces a 128-
bit “Message digest,” “fingerprint,” or “hash result.” The following figure
shows the way the input message is turned into a 128-bit message digest.
The MD5 Message-Digest Algorithm is a widely used cryptographic hash
function that produces a 128-bit (16-byte) hash value. It is very simple and
straight forward; the basic idea is to map data sets of variable length to
data sets of a fixed length. After using MD5, generated hash is typically
a 32-digit hexadecimal number. To do this, the input message is split into
chunks of 512-bit blocks. Now these blocks are processed by the MD5
algorithm, which operates in a 128-bit state, and the result will be a 128-bit
hash value. Here, the data to be encoded is often called the “message” and
the generated hash value is called the message digest “digest.” MD5 is very
fast, and easy to learn and implement but it generates fairly weak hashes
which is not too much secure. As we know, storing the text password with
hashing is the most risky thing for application security today. MD5 can be
made more secure using salt: Salt is some randomly generated text, which is
appended to password before obtaining hash, Like: Salt + Password + Salt

= Hash.
Figure 7.9: The MD-5 Algorithm. Source: http://www.iosrjournals.org/iosr-

jce/papers/conf.15013/Volume%205/8.%2037-42.pdf? id=7557
2. The Secure Hash Algorithm – SHA

The Secure Hash Algorithm (SHA) was developed by the National Security
Agency (NSA) and published in 1993 by the National Institute of Standard
and Technology (NIST) as the U. S. Federal Information Processing Standard
(FIPS PUB 180). SHA is based on and shares the same building blocks as
the MD4 algorithm. The design of SHA introduced a new procedure which
expands the 16-word message block input to the compression function to
an 80-word block among other things. In 1994, NIST announced that a
technical flaw in SHA was found. And, this flaw makes the algorithm less
safe than supposedly believed. No further details were given to the public,
only that a small modification was made to the algorithm which was now
known as SHA-1 and published in FIBS PUB 180-1. The SHA-2 family of
the hash algorithm consists of five cryptographic hash functions denoted
by SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 [7-9]. The last
four variants are sometimes collectively referred to as SHA-2. In fact, NIST
updated its hash function standard to FIPS PUB 180-2 in 2002. This update
specified three new hash functions, next to SHA-1, known as SHA-256,
SHA-384, and SHA-512. SHA-1 is designed to produce a 160-bit message
digest. The other hash functions have the length of their message digest
indicated by the number following prefix “SHA-”; thus SHA-256 produces
a 256-bit message digest, whereas SHA-384 produces a 384-bit hash value

and so on. SHA-224 which produces a message digest of 224-bit was added
to the standard in 2004. Description of the SHA-1 algorithm The SHA-1
algorithm accepts as input a message with a maximum length of 264 -1 and
produces a 160- bit message digest as output. The message is processed by
the compression function in 512-bit block. Each block is divided further
into sixteen 32-bit words denoted by Mt for t = 0, 1,...., 15. The compression
function consists of four rounds; each round is made up of a sequence of
twenty steps. A complete SHA-1 round consists of eighty steps where a
block length of 512 bits is used together with a 160-bit chaining variable to
finally produce a 160-bit hash value.
REFERENCES
1. Pethe, H. B., & Pande, S. R. An overview of Cryptographic Hash
Functions MD-5 and SHA. National Conference on Recent Trends in
Computer Science and Information Technology 38 NCRTCSIT-2016.
Retrieved January 2018, from.
2. Goldman, J. (2006). Firewall basics. In H. Bidgoli (Ed.), Handbook
of information security (pp. 2-14). Hoboken: John Wiley & Sons, Inc.
3. Hamdi, M., Doudriga, N., & Obaidat, M. (2006).Security policy
guidelines.In H. Bidgoli (Ed.), Handbook of information security (pp.
227-241). Hoboken: John Wiley & Sons, Inc.
4. Kakareka, A. (2009). What is vulnerability assessment? In J. Vacca
(Ed.), Computer and information security handbook (pp. 383-393).
Boston: Morgan Kaufmann Inc.
5. Stallings, W. (1999). Cryptography and network security. Upper Saddle
River, NJ: Prentice Hall.
6. Stallings, W. (2011). Operating Systems Security. In Handbook of
information security (pp 154-163).
CHAPTER 8
MOBILE AND UBIQUITOUS

COMPUTING
“…Next comes ubiquitous computing, or the age of calm technology, when

technology recedes into the background of our lives.”
-Mark Weiser
CONTENTS
8.1 Communication Technology.................................................................................. 164
8.2 Traditional System of Distribution.......................................................................... 164
8.3 Nomadic Distribution System................................................................................ 168
8.4 Mobile Adhoc Network......................................................................................... 169
8.5 Theory in Mobile Computing................................................................................. 171
8.6 Models.................................................................................................................. 172
8.7 Palmtop and Laptop Technology............................................................................ 174
8.8 Mobile Middleware............................................................................................... 175
8.9 Ubiquitous Computing.......................................................................................... 181
References................................................................................................................... 185
The Distributed Systems Group conducts research into distributed software

infrastructures, networks of embedded devices, and novel interaction
paradigms. Mobile computing often forms a vital component of pervasive
systems, the devices that form part of a (distributed) mobile system may
vary widely. Typically, mobile computing is now done with devices such as
smartphones and tablet computers. However, completely different types of
devices are now using the Internet Protocol (IP) to communicate, placing
mobile computing in a different perspective. A characteristic feature of
all these devices is that they use wireless communication. This chapter is
centered on mobile and pervasive computing. Although mobile computing
is still in its infancy, some basic concepts have been identified and several
experimental systems have been developed. Additionally, it discusses the
application and convergence of several current major and future computing
trends.
8.1 COMMUNICATION TECHNOLOGY

Wireless communication technology is utilized by both ground and satellite
based wireless technology, connects the connection of normally unlinked
points in the form of copper or fiber. In conclusion, we are approaching the
time when this calculation is: i. Itinerant, which implies reliable transport,
complete connectivity and power calculator when you are traveling with one
person in the car or on an aircraft or ship. ii. Distributed, that is, integrated
functions that are implemented in different places in a user-friendly way.
iii. Ubiquitous, that is, everywhere that offers the same function, regardless
of the user’s location. As noted, a widely available form of communication
with the computer is provided by the existing technology into the teletype
allows transmission of characters on a line telephone standard by using
ASCII code at speeds of several hundred bits per second rates for the type
and printing that can be achieved in telecommunications, mechanical). This
is the signal that the encoding of the teletype is carried out with mobile
network analog technology using a modem (demodulator) which converts
the flow of bits into acoustic signals. Today, frequencies of more than a
few thousand characters a second are becoming increasingly popular with
mobile phone improvements.
8.2 TRADITIONAL SYSTEM OF DISTRIBUTION

Most computer software traditionally ran in stand-alone systems, where
Mobile and Ubiquitous Computing 165
the user interface, application ‘business’ processing, and persistent data

resided in one computer, with peripherals attached to it by buses or cables.
Few interesting systems, however, are still designed this way. Instead,
most computer software today runs in distributed systems, where the
interactive presentation, application business processing, and data resources
reside in loosely-coupled computing nodes and service tiers connected
together by networks. Typical distributed systems must have the following
characteristics;
1. Fault-Tolerant
Distributed systems consist of a large number of software and hardware
modules over a long period of time are tied to failure. Such composite
damage may be accompanied by a lack of service. So, the system that
has to be removed from the wrong components is the wrong purpose of
doing so, to avoid damaging the system, even if it is a mistake to ensure
continued service. This system is considered tolerable if it can mask the
presence of errors. The goal of any systematic misuse of this system is to
increase reliability or availability. Reliability of a system is defined as the
system’s probability to live up to now. Reliable system prevents loss of
information, even in the event of failure of components. Availability is part
of the time when the system is in use. In general, the patience of the error is
achieved by providing a reservation. Overheads are defined as those parts of
the system that are not essential for its proper functioning. There are three
types - hardware, software, and time. Hardware storage has been achieved
by adding additional hardware to the system, which assumes the role of the
component failing in the event of some error.
2. Scalable
The distribution system works properly even when some aspects of the
system are scaled to a greater scale. Scale consists of three components:
the number of users and other objects that are part of the system, the
distance between the most remote numbers in the system, and the number
of institutions that administer administration over certain parts of the
system. These three elements affect the distribution system in many ways.
Among the components involved are naming, authentication, authorization,
communication, remote access, and mechanisms that users use to track
the system. Three techniques for standardized control are used: copy,
distribution and cache (Clifford N., 1994). Backup creates multiple copies
of the resource. Its use of name services, authentication and help reduce
file uploads on individual servers and improve reliability and availability of
services in general. The two main issues of the copy are the location of the
copy and the mechanism that they were kept.
Another distribution mechanism in the distribution system allows the
information supported by the distribution service to be expanded to multiple
servers. Data distribution between multiple servers reduces the size of the
database that will be maintained by each server, eliminating the time needed
to search the database. The distribution also distributes hosting servers by
reducing the number of questions processed by them. If suggestions can be
distributed on a plane engine in proportion to their power, the burden on the
server can be effectively controlled. Caching is another important technique
for creating a scalable system. Cache reduces server and network load. Cache
data can be logged faster if new requests are created. The difference between
copying and caching is that repository data is short-term data. Instead of
distributing update caches, data stabilization is stored by deleting warehouse
data when it can be secured. Caching is generally performed by customers,
reducing the need for regular network service.
3. Predictive Performance
Multiple indications perform as response times (time elapsed between end
of request or requirement in computer system and start of the answer),
performance (speed of a network, sending and receiving data), network
capabilities, and so on. It is used to evaluate the results. A predictable
performance is the ability to provide the desired reaction on time.
4. Openness
Open Attribute Attribution ensures that the subsystem is always open to
communication with other systems. Network Services is an application
system designed to help machine-to-network interactions on the web.
These protocols allow the distribution system to be expanded and scaled.
A scalable, open system benefits from closed and self-contained systems.
An independent distribution system of exceptional basal factors such as
hardware platforms and software, the properties of openness achieved. Thus,
each service can be accessed equally for each customer (local or remote) in
the system.
5. Security
The system must allow for the sharing of communication between
applications you use and/or other computer resources by implementing
the necessary security measures. Security features are designed primarily
to ensure confidentiality, integrity, and availability. Privacy is protection
against disclosure to unauthorized persons. Private disclaimers can range
from inflexibility to damage. Integrity provides protection against change
and corruption. Presence Save resource that is accessible. Many cases of
hacking compromise the integrity of databases and other resources. Denying
service attacks is an attack against availability. Other key security issues
include access control and non-payment.
6. Transparency
The distribution system is understood by the user and the whole developer
rather than the set of collaborative components. The location of the computer
system that is related to the transaction operation, the copy data, the sourcing
of multi-site sources, and the failure of the system restored has been hidden
by the user. Transparency hides the nature of its users and shows users that
the system appears and works as a centralized system. Transparency can be
used in different ways in distribution systems (Kazi et al, 2000) (Pradeep,
K. 2002).
Table 8.1: Different Forms of Transparency in a Distributed System (ISO, 1995)
Transparency Description
Access Hide differences in data representation and how
a resource is accessed
Location Hide where a resource is located
Migration Hide that a resource may be moved to another
location
Relocation Hide that a resource may be moved to another
location while in use
Replication Hide that a resource is replicated
Concurrency Hide that a resource may be shared by several
competitive users
Failure Hide the failure and recovery of a resource
Source: Andrew S. T., Maarten V. S., 2002. Distributed Systems: Principles
and Paradigms
8.3 NOMADIC DISTRIBUTION SYSTEM

We are interested in these capabilities that need to be created to support
nomadicity. Attributes that are desirable for popularity include site
independence, platform traffic, and the widespread presence of remote
access to files, systems, and services. The idea of independence here does
not relate to the quality of the service we see, but to the perception of a
self-defined computer environment that will process communication and
accessibility. The speed of data transmission between users and remote
servers may vary rapidly from a bit per second (in the wireless environment)
to hundreds of megabytes per second (in a strong electronic environment)
or desktops available to users may differ from low digital Personal digital
assistant (PDA) support on a transit to super-powerful computers in the
science lab. Of course, the current system has dramatically changed the
changes in connection values or voltage, such as exceptions or failures. In
the group atmosphere, they are considered normal. In addition, the ability
to accept incomplete or incomplete results is one of the choices to be made
due to the uncertainty of the information technology (IT) infrastructure.
The ability to adapt all aspects of computer functionality, communication
and user storage in a transparent and integrated way is the content of the
living environment. Some of the key system parameters must be connected:
bandwidth; latency; reliability; delayed error rate; power supplies; user
interfaces; and so on. This is a general concern for a computer-related
environment, but what makes them interested is that the value of these
parameters changes drastically as you move from place to place. In addition,
there are new and important concerns for users who use the size, battery
size and battery life of their mobile devices. And considering the bottom
line in many nomadic applications is worth the price. A key issue is to
develop complete system architecture and define name protocols. They
must provide a transparent view of the user’s computer environment and
changes. Protocols must meet the following requirements: i. Communication
between different infrastructures (e.g., Cable and Wireless). ii. Ability to deal
with abnormalities of: consumer behavior, network capabilities, computer
platform iii. Ensure smooth decomposition. iv. Scale in terms of: Address of
Quality of Service (QoS), inequality, bandwidth, geographic area, number
of users. v. Integrated access to services. vi. Ad-hoc access to services. vii.
Maximum independence between the network and the applications from
both the user’s viewpoint as well as from the development viewpoint.
viii. Ability to match the nature of what is transmitted to the bandwidth
availability (i.e., compression, approximation, partial information and so on.
ix. Cooperation among system elements such as sensors, actuators, devices,

network, operating system, file system, middleware, services, applications,
etc.
8.4 MOBILE ADHOC NETWORK

Mobile Ad Hoc Network (MANET) is connected to the network via
wireless connection. The Adhoc Network is an independent system node
that connects to a wireless connection (Corson et al., 1996). Special nodes
communicate with other nodes without a physical display. The node in this
special organization creates a network immediately when communication is
established. Each node is in contact with another node using radio waves.
The entire network is distributed and nodes communicate with each other
without a fixed terminal (AP) or a base station entry point. The Adhoc
Network is the built-in network (software), the network node connected
(Frodigh et al., 2000). They are different from the system of customizing and
distributing tradition because they do not have fixed infrastructure, mobile
gadgets can be broken up and the team can develop independently. The
connection may be inaccurate or symmetrical, depending on the example
on the transmission frequency used by the machine. The Adhoc Network
has encountered programs that have so far been set up from a small special
promotions group to exchange about a short-term meeting for military
action and the launch of emergency programs or emergencies in disasters.
Benefits of Adhoc Network include: i. Separate from Central Network
Administration. ii. It is also a router itself. iii. Self-healing by installing. iv.
The possibility is related to adding an additional node. v. Mobility allows ad
hoc networks to be built on changes in any situation where there are many
wireless devices. vi. Flexibility can be turned on anytime anywhere. vii.
Capital expenditure is low due to decentralization. viii. The nodes in the
Adhoc network should not rely on hardware or software. Therefore, it can
be connected and communicated quickly. In the end, Adhoc did not have the
power. However, Adhoc Network comes with its challenges, such as Quality
of Service (QoS), Scale, Security.
8.4.1 Quality of Service (QoS)

Dynamic Network creates Adhoc when nodal networks want to communicate
with your neighbor Neighborhood. Due to the changes in the topology in the
dynamic network of Adhoc, QoS provision is a tedious task (Chakrabarti
and Mishra, 2001). QoS is important due to the rapid development of

mobile technology and real-time applications such as multimedia and voice.
Providing QoS in ad hoc network is necessary to maintain best-effort-of
service.
8.4.2 Power control

Power control is one of the main components in ad hoc network as
battery provides limited capacity to the nodes. If the power failure occurs
in the node, it may affect itself and the entire network architecture gets
fragmented. The reason for power control is limited capacity of nodes, non-
static infrastructure, constraints on the battery sources, selection of excellent
transmission power and channel utilization (Lorch and Smith, 1998).
8.4.3 Scalability
The scalability problem occurs in ad hoc networks due to the nature of the
multi-hop (Wattenhofer et al., 2001). The scalability in ad hoc network
depends on the network size and forwarded packet capacity in the network.
The scalability can preserve by dividing the network area according to
their geographical location. The whole network area can be divided into
small virtual grid cells such that every node in each virtual grid cell can
communicate with other nodes in the same cell. The scalability depends on
equal node priority, uniform distribution of destination, spreading the node
reliably, and the shortest path.
8.4.4 Cooperation between nodes

Cooperation between the nodes is essential in the ad hoc network. Each
node in the network cooperates with other node for packet forwarding and
routing. Due to dynamic changing topology, the nodes in the network do
not rely on another node. In ad hoc network, source node transmits the
data to destination via intermediate node. Without cooperation between
the neighboring nodes source, node cannot transfer the data successfully.
Therefore, frequent modification in link may lead for uncertain topology
changes and network disconnections. The non-cooperative nodes may be
described in two ways, first one is the malicious nodes refer that the set
of the node attack the network or break the link. The selfish nodes use the
network for their purpose without pay back for the usage of network. Both
nodes are considered as misbehaving nodes.
8.4.5 Security
Security is a major concern in the ad hoc networking standards. Exchange of
data on the Adhoc network should be done safely. Adhoc network security
issues are dynamic topologies, speed, device size, and limited battery life.
Due to the dynamic nature, it is difficult to maintain cross-network security.
Adhoc networks do not rely on existing infrastructure, so nodes can go
out and join the network in a situation where security can fall. There are
two types of attacks in the Adhoc network. The first is the passive network
which does not change the data for the web. But this can allow unauthorized
users to find messages. The second is the active attack; it is a serious attack
and protects the flow of messages between the nodes on the network. This
can allow unauthorized users to edit messages.
8.5 THEORY IN MOBILE COMPUTING

Mobile computing may be defined as a form of interaction between a human
and a computer implying that a computer device may be easily transported
by the user. The researcher states that the key mobile computing devices are
laptops, palmtops, smartphones and ordinary mobile phones (Mastorakis,
2009). This section of literature review critically discusses the main theories
on the development of mobile computing and its influence on the mobile
telephony.
8.5.1 Radio communication

Radio communication with a mobile computer is highly variable and hard
to control. The phenomenon of fading, signal strength suddenly decreasing,
is a significant problem (and one familiar to anyone who has listened to an
automobile radio). It is quite normal for a mobile radio to experience fades
of 40–50 dB in fraction of a second. A fast-moving automobile in an urban
environment may be subjected to dozens of significant fades (20dB, or more)
per second. For comparison, a representative signal-to-noise ratio (SNR)
objective for an analog wireline link is about 46 dB. Signal fluctuations in
a wireline link are no more than 1–2 dB for a short-haul circuit and short
time-span, and perhaps 10–15 dB for gradual degradation due to wear
and tear of the network. During a fade, the signal may be so weak that an
undesired, interfering signal from a neighboring cell may dominate and,
consequently, the receiver may lock on that undesired signal. There are, in
general, two types of fading namely short term and long-term fading. Short
term multipath fading is caused by similar signal taking different paths and
arriving at the receiver shifted in phase. On the other hand, long-term fading,
or radio shadows is caused by the topography of the terrain (like mountains)
and can lead to signal dropouts. In wireless environments, management of
transmission power is critical. The importance of power arises from two
factors: i. Energy is a scarce resource in mobile units. Therefore, transmission
with power, as low as feasible, is highly desirable. ii. Signals from other
terminals are considered by a given terminal as interference, which has a
negative effect on the signal-to-noise ratio. Thus, it is important that each
terminal use the “right” amount of power to transmit successfully without
unnecessary degradation of others’ transmissions.
8.6 MODELS
It is important to develop a good understanding of the mobile operating
system model and the unique search issues. There are many topology
systems for cellular networks. For example, cellular networks, mobile ad
hoc networks (MANETs), body area networks (BANs) and WLANs. It is
important to understand, capture and describe the features of each of these
models and identify the most common architecture that combines these
basic patterns into sophisticated architectures. The WLANs, LAN, PAN and
MAN are already discussed in the first chapter of this book (see chapter one,
Introduction to the Internet).
8.6.1 Analog cellular systems

The cellular system was pioneered at AT&T Bell Laboratories in early 1970s
and was deployed in U, S. in the early 1980s. The coverage area is subdivided
into cells with sizes varying from a few kilometers in diameter to between
50 and 100 km in earlier cellular systems. The first generation, called AMPS
(Advanced Mobile Phone Service), which is still used for cellular telephony,
uses analog frequency modulation for speech transmission. Individual calls
use different frequencies, using a system referred to as frequency division/
multiple access (FDMA). In the AMPS system, 50 MHz of bandwidth in
the bands of 824–849 MHz and 869–894 MHz are allocated to cellular
mobile radio. In each geographic region, there are two carriers (carrier A
and carrier B), which control 25 MHz each. This spectrum is subdivided
into 832 channels, each of 30 KHz. To avoid interference, neighboring cells
use different channels. Typically, a cell has 6 neighbors and, therefore, the
cell may use 1/7 of the allotted 832 channels. This is called a 7-group re-use
cluster. Analogously, in the 12-group frequency plan each cell uses only 1/12
of the total bandwidth and its bandwidth allocation is disjoint with that of
11 neighboring cells. The Cellular Digital Packet Data (CDPD) is designed
to provide packet data services on the top of the existing AMPS. The CDPD
system provides data services without interfering with the existing analog
and digital telephone services that use the same AMPS channels. In CDPD,
voice transmission has a higher priority than data transmission. Data can be
transmitted on a channel only if a there is no voice call which is using that
channel. Voice transmission can preempt data transmission.
Figure 8.1: First Operational analog 1G mobile system. Source: http://drmoaz-

zam.com/development-of-first-generation-mobile-communication-systems/
8.6.2 Digital cellular systems

Digital cellular systems are sometimes referred to as second-generation
cellular. Due to the development of the digital speech coding techniques,
digital systems are gaining rapidly in significance. Among the advantages
of digital cellular communications are the following (Calhoun, G., 1988):
i. Strength of digital networks and resistance to noise and crosstalk. ii.
Acumen of the digital network. iii. Tractability and incorporation with the
wired digital networks. iv. Reduced RF transmission power (improving
battery life in handsets). v. Encryption for communication confidentiality.
vi. Reduced system intricacy. vii. Advanced user capacity. Two basic
techniques for managing shared access are competing in digital cellular
radio: TDMA (Time Division Multiple Access) and CDMA (Code Division
Multiple Access). With TDMA, only a single user can use a given frequency
at any time. With CDMA (spread spectrum), a frequency-based channel is
used simultaneously by multiple mobile units in a given cell.
8.6.3 Satellite networks

Mobile satellite services allow complete global coverage. In these systems,
satelUtes play the role of mobile base stations. Satellite-based systems may
be categorized according to the orbital altitude: i. Geostationary satellites
(GEOS), at an altitude of 35,786 km ii. Low earth orbit satellites (LEOS),
at the altitudes on the order of 1000 km iii. Medium earth orbit satellites,
with widely varying altitudes between those of GEGS and LEOS The major
advantage of GEOS systems is that contiguous global coverage up to 75
degrees latitude can be provided with just three satellites. On the other hand,
the main drawback is a large 240–270 ms round trip propagation delay and
the higher RF power required. On the other hand, LEOS systems require
less power but require frequent handoffs.
8.6.4 Cordless telephony

There is presently an estimated sixty million cordless telephones in the U.
S. with complete sales attaining fifteen million units per year. Cordless
technology requires only very low power of transmission, but it is limited
to very short ranges. The main digital cordless standards include CT2 and
DECT (Digital European Cordless Telecommunications. The CT2 spectrum
allocation consists of 40 FDMA channels with 100 KHz spacing in the range
of 864 to 868 MHz. The maximum transmitting power is 10 mW, which is
very small. CT2 supports the transmission of data from 2.4 Kb/s to 32 Kb/s.
The functionality of DECT system is closer to that of a cellular system than
it is to that of a classical cordless telephone system. DECT uses TDMA
with 12 slots per carrier in each direction. Furthermore, it can allocate
several slots to a single call to increase the data rate. DECT systems are only
beginning to be shipped and the unit sales reached 100,000 last year. It is a
potential basis for a future, low cost, picocell-based system.
8.7 PALMTOP AND LAPTOP TECHNOLOGY

The palmtop and laptop technology is expanding so rapidly that there is little
point in discussing specific products. In a recent USA Today article, longer
battery life was mentioned as the feature most desired by mobile users.
Unfortunately, expected growth of battery life is very slow. Thus, energy
efficiency is a necessary feature both at the level of hardware, and software.
Hardware providers are offering energy-efficient systems that switch off
the background light of the screen, power down the disk (or eliminate the
disk completely in favor of flash memory) and offer CPUs with an energy-
efficient doze mode. For example, the Hobbit chip consumes 5,000 times less
energy while in doze mode than in the active mode (250 mW in the active
mode as opposed to 50/xW in doze mode). There is a growing pressure on
software vendors to incorporate energy management features.
8.7.1 Storage technology

Flash memories constitute new, more energy efficient, storage alternatives
to disks. Flash memories consume relatively little energy and provide low
latency and high throughput for read accesses. However, their high cost,
$30- 50/Mbyte, is still a limiting factor. Furthermore, flash memories
require additional system support for erasure management as writing to
flash memory requires prior erasing. Additionally, the number of times the
same memory block can be rewritten is usually limited (on the order of
100,000 times).
8.7.2 User interface and display issues

The two key issues in human-computer interaction are the desirability of
replacing the keyboard with a pen-based interface and the challenge of dealing
with a small-sized display. Pen-based interfaces have been introduced in
recent years with mixed acceptance. The mixed results so far are due in large
part to problems with handwriting recognition (shown by early experience
with the Apple Newton MessagePad). As recognition-related technology
improves, it is expected that pen based interfaces will gain in acceptance.
Small display size is a serious problem, especially for users who would
like to access remote information services, such as those provided on the
World-Wide Web. The need to deal with varying display sizes suggests that
applications be structured in a display independent manner.
8.8 MOBILE MIDDLEWARE

Middleware supports mediation between other software components,
fostering interoperability between those components across heterogeneous
platforms and varying resource levels. The rapid growth of wireless
technologies and the development of smaller and smaller devices have
led to the widespread use of mobile computing. Each user, equipped with
a portable device, is able to access miscellaneous services in any way at
anytime and anywhere thanks to the connectivity powered by modern
network technologies. Mobile access to distributed applications and services

raises many new issues. A major problem is the wireless technology itself,
as the bandwidth provided is orders of magnitude lower than in the wired
networks, signal loss is very frequent, and the noise level is influenced by
external conditions. A second aspect is related to the mobile devices, which
are characterized by scarce resources in terms of CPU, RAM, display, and
storage; in particular, they are equipped with smart batteries, which limit
the autonomy of the device (in terms of power consumption) and affect
both wireless transmission and access to services that require a high
computational load. Finally, a third aspect that must be considered is user
mobility, which causes problems related to signal loss during movement to
a new cell (handoff), as well as problems with address management caused
by users traversing through different administrative domains and the need to
adapt services to the position of the user. In this section, we shall discuss the
different types of middleware and how they affect mobility.
8.8.1 Reflective Middleware

The reflection technique was initially used in the field of programming
languages to support the design of more open and extensible languages
(Kiczales, G., et. al, 1991). Reflection is also applied in other fields including
operating systems and more in recent times distributed systems. The principle
of reflection enables a program to access, reason about and change its own
behavior. A reflective system consists of two levels referred to as meta-level
and base-level. The previous performs computation on the objects residing
within the lower levels. The latter performs computation on the application
domain entities. The reflection approach supports the scrutiny and adaptation
of the underlying operation (the base-level) at runtime. A reflective system
provides a meta-object protocol (meta-interface) to delineate the services
available at the meta-level. The meta-level can be accessed through a plan
of reification. Reification means revealing some hidden facet of the inner
representation and hence they can be accessed by the application (the base-
level). The operation of openness offers a direct mechanism to introduce
some behaviors to check or modify the internal behavior of the platform.
This enables the application to be in control of examining and adapting the
middleware behavior based on its own needs. Thus, a lightweight middleware
with an insignificant set of functionality is achieved to operate on mobile
systems. The main inspiration of this approach is to create a more adaptable
middleware that can cope with variations in the environment. Examples of
middleware systems that adopted the concept of reflection are OpenCorba,
Open-ORB, DynamicTAO, FlexiNet, and Globe (Gaddah, A. and Kuns, T.,

2003).
8.8.2 Tuple space-based middleware

The traits of wi-fi communique media desire a decoupled and imaginative
fashion of communication: decoupled within the feel that computation
proceeds even in presence of disconnections, and opportunistic as it
exploits connectivity whenever it becomes whenever it becomes accessible.
Some attempts based on events or queues (Rover or Mobile JMS) have
been devised. Every other asynchronous and decoupled communication
paradigm has also been removed as powerful as it is in cellular settings.
Tuple space systems have been shown to deliver many useful facilities for
communication in wireless settings. In Linda, a tuple space is a universally
shared, associatively addressed memory space used by processes to
communicate. It acts as a warehouse (in particular a multi-set) of data
structures called tuples that can be regarded as vector of typed values. Tuples
represent the basic elements of a tuple space systems; they are generated by
a process and positioned in the tuple space using a write primitive, and they
can be accessed synchronously by a number of processes using read and
take primitives, both of which are blocking (even if non-blocking versions
can be provided). Tuples are unidentified; thus their selection takes place
through matching of configuration on the tuple contents. Communication
is de-coupled in both time and space: senders and receivers do not need to
be accessible simultaneously, because tuples have their own lifetime, are
autonomous and do not rely on the process that created them, and shared
knowledge of their position is not required for data commutation, as the tuple
space resembles a universally shared data space, irrespective of machine or
platform restrictions.
Linda in a Mobile Environment

LIME is a middleware supporting the development of applications that
exhibit physical mobility of hosts, logical mobility of agents, or both. LIME
adopts a coordination perspective inspired by work on the Linda model.
The context is represented in Linda by a globally accessible, persistent
tuple space, is represented in LIME by transient sharing of the tuple spaces
carried by each individual mobile unit. The model fostered by Lime (LIME)
aims at identifying a coordination layer that can be exploited successfully
for developing applications that exhibit either logical or physical mobility,
including those presented above. To achieve this goal, Lime borrows and
adapts the communication model made popular by Linda. In Linda, processes
communicate through a shared tuple space, a repository of elementary
data structures, called tuples that can be accessed concurrently by several
processes. Each tuple is an ordered sequence of typed data. Tuples are
inserted using the out (t) operation on the tuple space, and can be removed
by executing in (p), where p is a template used to identify tuples based on
pattern matching against their content. Tuples can also be read from the
tuple space using the rd operation. Both in and rd are blocking. A typical
extension to this synchronous model is the provision of the asynchronous
primitives inp and rdp, called probes, that allow non-blocking access to
the tuple space. Linda characteristics resonate well with the mobile setting.
Communication in Linda is decoupled in time and space, i.e., senders
and receivers do not need to be available at the same time, and mutual
knowledge of their location is not necessary for data exchange. Decoupling
is of paramount importance in mobility, where the parties involved in
communication change dynamically due to their migration. Nevertheless,
when mobility is fully exploited, as with ad hoc networks, there is no
predefined, static, global context for the computation, as assumed by Linda.
Rather, the current global context is defined by the transient community of
mobile units that are currently present, to which each unit is contributing its
own individual context. As these communities are dynamically changing
according to connectivity and migration, the context changes as well. This
observation alone leads to the model underlying Lime. Although still based
on the Linda notion of a tuple space, Lime exploits it in a radically different
way. Lime is fully implemented in Java, with support for version 1.1 and
higher. Communication is handled entirely at the socket level—no support
for RMI or other additional communication mechanisms is needed or
exploited in Lime. The lime package is about 5,000 non-commented source
statements, for about 100 Kbyte of jar file. The companion lighTS package
provides a lightweight tuple space implementation plus an adapter layer
integrating other tuple space engines, for an additional 20 Kbyte. Thus far,
Lime has been tested successfully on mobile hosts running Windows9x/NT/
CE networked with WaveLAN wireless technology.
8.8.3 Context-aware middleware

Mobile phone systems work in a very good environment. Context of practice
often changes due to user mobility. Mobile devices often travel around
other areas, and services available before breaks may not be available after
connection again. In addition, the frequency of connectivity and connection

quality can change rapidly depending on the mobile engine and their location.
Software developers cannot predict the context of all practices that allow the
program to know how to respond to each scenario. The middleware should
reveal the context of the program to make it aware of the dramatic changes
in the execution environment. The application instructs how to adjust their
behavior to get the best quality of service. Many research groups pay special
attention to a particular understanding of the location. For example, location
information is used to provide guidance for travelers advising to look for
neighboring services and share messages to users in specific areas. The
location-aware system mostly relies on the main network operating system
to obtain location information and create the appropriate form to be used by
the system.
8.8.4 Data sharing-oriented middleware

One of the major issues targeted is the support for disconnected operations
and data-sharing. Systems like Coda, its successor Odyssey, Bayou and
Xmiddle try to maximize availability of data, giving users access to replicas;
they differ in the way they ensure that replicas move towards eventual
consistency, that is, in the mechanisms they provide to detect and resolve
conflicts that naturally arise in mobile systems. Despite a proliferation of
different, proprietary data synchronization protocols for mobile devices, we
still lack a single synchronization standard, as most of these protocols are
implemented only on a subset of devices and are able to access a small set
of networked data. This represents a limitation for end users, application
developers, service providers and device manufacturers.
Bayou
The Bayou storage system provides an infrastructure for collaborative
applications. Bayou manages conflicts introduced by concurrent activity
while relying only on the fluctuating connectivity available in mobile
computing. Replication is seen as a requirement in the mobile scenario as
a single storage site may not be reachable by some mobile clients or within
disconnected work-groups. Bayou allows arbitrary read and write operations
to any replica without explicit coordination with the other replicas: every
computer eventually receives updates from every other, either directly or
indirectly, through a chain of peer interactions. The weak consistency of
the replicated data is not transparent to applications; instead, they are aware
they may be using weakly consistent data and that their write operations may
conflict with those of other users and applications. Moreover, applications
are involved in the detection and resolution of conflicts as these naturally
depend on the semantics of the application. In particular, the system provides
the application with ways of specifying its ownnotion of a conflict, along with
its policy for resolving it. In return, the system implements the mechanisms
for reliable detection of conflicts, as specified by the application, and for
automatic resolution when possible. However, one of the major drawbacks
of Bayou is its client-server architecture. Although in principle client and
server may co-exist on a host in practice, the system requires that each data
collection is replicated in full on a number of servers.
8.8.5 Event-based middleware

An event-based middleware is a middleware for large distribution systems
that provide scalable and effective communication between the components
for printing/subscribing. It refers to traditional middleware requirements
such as usage, interoperability management, and scaling. Middleware Call-
based systems such as CORBA or Java RMI have an intricate system useful
for distribution. The communication model for these operating systems
based on the request/response model: This object remains passive while the
policy is not executing on it. This type of model is suitable for LAN networks
with a small number of clients and servers, but not good for large scale
networks such as the Internet. The main reason is that the request/response
model for communication only supports direct communication and close
interaction between stakeholders because of the synchronization model.
This model is not suitable for undependable and dynamic environments.
The communication model based on event options is possible for working
with large systems.
Hermes
A primary feature of the Hermes event-based middleware is scalability, as
it is targeted at the development of large-scale distributed systems. Hermes
includes two content-based routing algorithms to disseminate events from
event publishers to subscribers. The type-based routing algorithm only
supports subscriptions depending on the event type of event publications.
It is comparable to a topic-based publish/subscribe service but differs by
observing inheritance relationships between event types. The second
algorithm is type- and attribute-based routing, which extends type-based
routing with content-based filtering on event attributes in publications.

Reflecting the layered network structure, Hermes has six architectural
layers. Each layer is made up of the functions provided by the substrate
and provides the interface clearly defined to the upper layer. In addition,
the layers are not dependent on each other. The layer architecture for the
communication system has the advantage that each layer can be replaced by a
different execution if necessary. For example, if the effective implementation
of the distributed hash table is available, Hermes can take advantage of this
without major changes.
8.9 UBIQUITOUS COMPUTING

Mark Weiser is the father of ubiquitous computing. He coined the phrase
“ubiquitous computing” around 1988. He was working as Chief Technologist
at the CS Lab of Xerox Palo Alto Research Center in the late 1980s and was
articulated the current of computing. He wrote some of the earliest papers
on the subject, largely defining it and sketching out its major concerns.
He developed the initial initiatives of ubiquitous computing in the form
of tabs, pads, and boards, built at Xerox PARC, 1988–1994. This vision
of ubiquitous computing is grounded in the belief that microprocessors
and advanced sensors will soon become so small and inexpensive that
they can be embedded into almost anything. It is expected that billions of
such objects will be interspersed and wirelessly interconnected to form an
Internet of Things, a worldwide distributed system several orders of degree
larger than today’s Internet. To enable communication and collaboration
among smart objects, new data infrastructures are essential. They will
have to cope with an extremely vibrant environment and should, among
other things, offer information with regards to location to mobile objects,
epitomize context information, and enable dependable and scalable service
formation. Ubiquitous computing (Ubicomp), also known as pervasive
computing, strives at creating a completely new paradigm of computing
environment in almost all of these respects. Ubicomp systems aim for a
heterogeneous set of devices, including invisible computers embedded in
everyday objects such as cars and furniture, mobile devices such as personal
digital assistants (PDAs) and smart phones, personal devices such as laptops,
and very large devices such as wall-sized displays and tabletop computers
situated in the environments and buildings we inhabit. All these devices
have different operating systems, networking interfaces, input capabilities,
and displays. Some are designed for end user interaction—such as a public
display in a cafeteria area—whereas other devices, such as sensors, are not

used directly by end users. The interaction mode goes beyond the one-to-
one model prevalent for PCs, to a many-to-many model where the same
person uses multiple devices, and several persons may use the same device.
Interaction may be implicit, invisible, or through sensing natural interactions
such as speech, gesture, or presence: a wide range of sensors is required,
both sensors built into the devices as well as sensors embedded in the
environment. Location tracking devices, cameras, and three-dimensional
(3-D) accelerometers can be used to detect who is in a place and deduce
what they are doing. This information may be used to provide the user with
information relevant in a specific location or help them adapt their device to
a local environment or the local environment to them. Networking is often
wireless and ad hoc in the sense that many devices come in contact with
each other spontaneously and communicate to establish services, when they
depart, the network setup changes for both the device and the environment.
Figure 8.2: Waves of computing. Source: https://steemit.com/technology/@

faad/what-is-ubiquitous-computing-technology-easy-introduction-and-com-
plete-guide
Ubiquitous computing technologies will have a strong impact on future
society. In particular, security and privacy will be of prime concern in a world
of highly interconnected, invisible devices that will eventually permeate
our everyday lives. However, there are other topics and challenges existed
before Ubicomp but are significantly aggravated in a ubicomp setting. We
shall discuss a few of these challenges.
8.9.1 Resource-constrained devices

The first—and perhaps most visible—challenge to most ubicomp
applications and systems is that they involve devices with limited resources.
With ubicomp, however, a wide range of new devices are built and
introduced, which are much more resource-constrained. Devices such as
PDAs, mobile phones, and music players have limited CPU, memory, and
network connectivity compared to a standard PC, and embedded platforms
such as sensor networks and smart cards are very limited compared to a PC
or even a smart phone. Hence, when creating systems support in a ubicomp
setting, it is important to recognize the constraints of the target devices,
and to recognize that hardware platforms are highly heterogeneous and
incompatible with respect to hardware specifications, operating system,
input/output capabilities, network, etc.
8.9.2 Volatile execution environment

A core research topic in ubicomp systems research is service discovery, that
is, technologies and standards that enable devices to discover each other, set
up communication links, and start using each other’s services. For example,
when a portable device enters a smart room, it may want to discover and
use nearby resources such as public displays and printers. Several service
discovery technologies have now matured and are in daily use in thousands
of devices. These include Jini, UPnP, Bonjour/multicast DNS (mDNS),
and the Bluetooth discovery protocol. Nevertheless, several challenges to
existing approaches still exist, including the lack of support for multicast
discovery beyond LANs, the lack of support beyond one-to-one device/
service pairing, and rather cumbersome methods for pairing devices, often
involving typing in personal identification numbers or passwords. Research
is ongoing to improve upon service discovery technologies. Ubicomp
systems and applications are often distributed; they entail interaction
between different devices—mobile, embedded, or server-based—and use
different networking capabilities. Looking at Ubicomp from this distributed
computing perspective, a fundamental challenge to Ubicomp systems is their
volatile nature (Coulouris,Dollimore, &Kindberg, 2005). The set of users,
devices, hardware, software, and operating systems in Ubicomp systems is
highly dynamic and changes frequently.
8.9.3 Heterogeneous Execution Environment

Most Ubicomp applications and systems inherently live in a heterogeneous
environment. Ubicomp applications often include a wide range of hardware,
network technology, operating systems, I/0 capabilities, resources, sensors,
etc., and unlike the traditional use of the term application, which usually refers
to software, at most two physical nodes, the Ubicomp application typically
encompasses several devices that need to interact closely and consistently to
make the application. For example, Smart Room is an application that depends
on several devices, services, communications links, software components,
and an end-user application that needs to work in full concert to fulfill the
full functionality of a smart room. Therefore, managing heterogeneity is
not just a matter of the ability to compile, build, and deploy application to
different target platforms - such as building a desktop application that works
on different versions of Windows, Mac OS, and Linux. The challenge of
heterogeneity arises partially because Ubicomp is a new research field and
the new standard technology stack, including hardware, operating system,
etc. has not yet been exhausted. In the above scenario, it can be argued that
the variety of related technologies is too complex and unnecessary. This is
fairly accurate, and existing or new technology platforms may progressively
be able to deal with Ubicomp requirements in a more homogeneous and
regular way.
REFERENCES
1. Adelstein, F., Gupta, S., Richard, G.,&Schwiebert, L. (2005).
Fundamentals of mobile and pervasive computing.New York:McGraw-
Hill.
2. Akyildiz, I.,&Kasimoglu. I. (2004). Wireless sensor and actor networks:
research challenges. Ad Hoc Networks,2,351-367.
3. Akyildiz, I., Su, W.,Sankarasubramaniam, Y., &Cayirci, E.
(2002). A survey on sensor networks.IEEE Communications
Magazines,40(8),102-114.
4. Han, S. et al. Reconfigurable Sensor Networks with SOS, UCLA
Electrical Engineering Department Annual Research Review (ARR).
University of California, Los An , October 2004.
5. Mascolo, C.; Hailes, S. Survey of middleware for networked embedded
systems. Technical Report for Project: Reconfigurable Ubiquitous
Networked Embedded Systems, University College London, 2005.
6. Serain, D. (2002). Middleware and enterprise application integration.
Springer-Verlag London Limited.
CHAPTER 9
DISTRIBUTED PROGRAMMING
SYSTEMS AND ENVIRONMENT
“Programming on a distributed system for high-performance computing

has been recognized as a much more difficult task than programming on a
centralized system.”
-Cao, J. et al. (2002)
CONTENTS
9.1 Distributed Programming Environment.................................................................. 188
9.2 Occam 2............................................................................................................... 188
9.3 Ada 95.................................................................................................................. 189
9.4 Java....................................................................................................................... 194
9.5 Corba.................................................................................................................... 198
References................................................................................................................... 206
Recently due to the advances of the computing facilities and the development
of the network in which the computing resources are connected and
shared, the programming environment migrates from the single and local
environment to the distributed and global environment. Therefore the
programming environment that can smoothly support cooperative works
on the network is necessary. e. Computing using distributed objects
provide a flexible and scalable programming on the distributed and parallel
programming environment. Many systems such as CORBA, DCOM, and
Java support the distributed object computing. This chapter enlightens the
readers on some of the programming environments and they are analyzed in
terms of performance, support, ease of coding, and ease of debugging.
9.1 DISTRIBUTED PROGRAMMING ENVIRON-

MENT
The Distributed Programming Environment (DPE) is designed and
implemented to support an environment for distributed programming
on the parallel and distributed programming systems. In other words, a
Programming Environment is a system that provides computer assistance
during software development and maintenance. The DPE implementation
is currently working on the Internet. The DPE allows several programmers,
project managers, and system managers to work together while they are
residing on the different sites all over the world. Cooperative members
can work anywhere, even while they are on business travel carrying with
notebook computers, by using the DPE with any machine if the machines
are connected to the Internet and supported by CORBA/Java.
9.2 OCCAM 2
The Occam programming language was designed with the philosophy of
eliminating unnecessary complexities, thus keeping the language simple
and elegant. Concurrency and communication are the prime concepts of
the Occam model. Occam captures the hierarchical structure of a system
by allowing an interconnected set of processes to be regarded as a unified,
single process. At any level of detail, the programmer is only concerned with
a small, manageable set of processes. Occam is an ideal introduction to a
number of key methodologies in recent computer science. Occam programs
can provide a degree of security unidentified in conventional programming
languages such as C, FORTRAN or Pascal. Occam semantics simplify
Distributed Programming Systems and Environment 189
the task of program verification, by allowing application of mathematical

proof techniques to prove the correctness of programs. Transformations,
which convert a process from one form to a directly equivalent form, can
be applied to the source of an Occam program to improve its efficiency
in any particular environment. It makes an ideal language for specification
and behavioral description. Occam programs are easily configured into the
hardware of a system or indeed, may specify the hardware of a system.
9.2.1 The Use of Occam

Concurrent programming language is broadly classified into two according
to its usage.
1. They provide for the direct representation of objects which will
execute in parallel on multiprocessor hardware.
2. They provide for the direct programming of applications with
concurrent objects.
9.3 ADA 95
Ada defines a distributed system as an interconnection of one or more
processing nodes (a system resource that possess both operative and storage
capabilities), and zero or more storage nodes (a system resource that has only
storage capabilities, with the storage addressable by more than one processing
nodes). The Ada model for programming distributed systems specifies
a partition as the unit of distribution. Partitions comprised collections of
library units (separately compiled library packages or subprograms) that
may mutually execute in a distributed target execution environment. The
configuration of library units into partitions is not defined by the language;
it is presumed that an implementation will provide this, along with facilities
for allocation and, if necessary, reconfiguration.
Each partition resides at a single execution site where all its library
units occupy the same logical address space. More than one partition may,
however, reside on the same execution site. Partitions may be either active or
passive. The library units comprising an active partition reside and execute
upon the same processing element. In contrast, library units comprising a
passive partition reside at a storage element that is directly accessible to
the nodes of different active partitions that reference them. This model
ensures that active partitions cannot directly access variables in other active
partitions. Variables can only be shared directly between active partitions by
encapsulating them in a passive partition. Communication between active

partitions is defined in the language to be via remote subprogram calls
(however, an implementation may offer other communication mechanisms).
Listing 1 An Ada multitasking program
1 with Ada. Text_IO;
2 procedure Tasking_Example is
3 Finished: Boolean:= False;
4 pragma Atomic (Finished);
5
6 task Outputter; -- task specification
7
8 task body Outputter is -- task body
9 Count: Integer:= 1;
10 begin
11 while not Finished loop
12 Ada. Text_IO. Put_Line (Integer’Image (Count));
13 Count:= Count + 1;
14 delay 1.0; -- one second
15 end loop;
16 Ada. Text_IO. Put_Line (“Terminating”);
17 end Outputter;
18
19 begin
20 delay 20.0; -- twenty seconds
21 Finished:= True;
22 end Tasking_Example;
The Ada. Text_IO phrase on Line 1 makes the contents of the standard
Ada. Text_IO library contained in the Tasking_Example procedure. This
package contains the Put_Line procedure for displaying the phrase. The
“finish” variable is used to communicate the main process and the Outputter
task. The Atomic Commitment by pragma prevents the compiler from
local variable cache in Outputter’s task. Such optimization will affect
program objectives. The atom also checks whether variables can be used—
Contextchangescannot occur in the middle of reading or writing. The
Outputter task is simply an ending cycle when the actual completion shows
the current value of Count increasing the number and then pausing for at
least one second. When the cycle comes out, the control is transferred to
a statement that says “end” message and the task is finished. The task of
the result is activated when starting the shutdown process. The body of the
procedure stops executing for 20 seconds, and then ends with the fact that
the Outputter will end. The Tasking_Example procedure will not return until
the Outputter terminates. Delivery machines in the transport development
environment are usually used as an add-on to existing computers, called
machines. By machine, transport programs can obtain files, screens, and
caching services. This file accepts an IBM PC or Compatible Computers
with some specific MS-DOS features. There are equivalents for other
systems. Transporting contacts with the host on the INMOS connection.
An application called a server is running on the machine at the same time
running applications on the network. All communication between the
applications being implemented by the carrier and the host service (such as
keyboard screen and feed feed) is in the form of a message. The standard C,
Pascal and FORTRAN development systems use servers called the afserver
server. Office equipment D705B occam with INMOS Parallel C and Parallel
FORTRAN development system using servers called servers. The main
network transmission is the transport that connects the bus received through
the connection adapter. All of the other servers on the network are connected
by connecting INMOS to the main cargo. The transport network may have
space and a combination of transport types. Relationships between machines
and engines during application development do not require any restriction
on how materials are used in the target environment.
Figure 9.1: The transputer/host development relationship.

Source: http://www.transputer.net/tn/55/tn55.html
9.3.1 Real-time and parallel programming

For Ada 95, language support for synchronous communication is provided
by a data-oriented synchronization “building block” called a “protected
record,” to complement the synchronous task- to-task communication
capability represented by meetings. A protected record is a combination
of record components plus “protected operations,” which have exclusive
access to the components. A protected record type is specified by a program
unit that defines the components and the protected operations that are
either read-only “protected functions,” read/write “protected procedures,”
or potentially suspending entries (analogous to task entries). Here is an
example of a “mailbox” protected record type, defined in generic package:
generic
type Message_Type is private;
package Mailbox_Pkg is
type Message_Array is array (Positive range <>) of Message_Type;
protected type Mailbox (Size: Natural) is
function Count return Natural;
(Count of messages in the Mailbox.)
procedure Discard_All;
(Discard all messages in the Mailbox.)
entry Put (Message: in Message_Type);
(Put a message into the mailbox;
suspend until there is room.)
entry Get (Message: out Message_Type);
(Get a message from the mailbox;
suspend until there is a message.)
private record
(Define the components of the protected record.)
Contents: Message_Array (1. Size);
(This array holds the messages.)
Current_Count: Natural:= 0;
(Count of messages in the mailbox.)
Put_Index: Positive:= 1;
(Index into array for adding next message.)
Get_Index: Positive:= 1;
(Index into array for moving next message.)
end Mailbox;
end Mailbox_pkg;
This generic package may be implemented as follows:
package body Mailbox_Pkg is
protected body Mailbox is
function Count return Natural is
(Count of messages in the Mailbox.)
begin
return Current_Count
end Count;
procedure Discard_All is
Discard all messages in the mailbox
begin
count:= 0;
(Reset the array indices as well.)
Put_Index:= 1;
Get_Index:= 1;
end Discard_All;
entry Put (Message: in Message_Type) when Count < Size is
(Put a message into the mailbox.
“Count ≶ Size” is the “barrier” for this entry.
Any caller is suspended until this is true.)
begin
(Insert new message, bump index (cyclicly)
and increment counter.)
Contents (Put_Index):= Message;

Put_Index:= Put_Index mod Size + 1;
Count:= Count + 1;
end Put;
entry Get (Message: out Message_Type) when Count > 0 is
(Get next message from the mailbox.
“Count > 0” is the “barrier” for this entry.
Any caller is suspended until this is true.)
begin
(Get next message, bump index (cyclicly)
and decrement counter.)
Message:= Contents (Get_Index);
Get_Index:= Get_Index mod Size + 1;
Count:= Count - 1;
end Get;
end Mailbox;
end mailbox_Pkg;
As illustrated above, each protected operation specified in the protected type

definition must have a body provided in the protected body. Furthermore,
each entry body must have an “entry barrier” specified after the reserved
word when. Any caller of any entry is automatically suspended if the entry
barrier is false, on an entry queue associated with the entry.
9.4 JAVA
The name Java is applied to a variety of technologies created by Sun
Microsystems. While the reader will instantly associate Java with a
programming language (which it most certainly is), in actuality Java is also
much more. There are three main components of Java:
-The Java programming language—a programming language used to
write software for the Java platform -The Java platform—a range of runtime
environments that support execution of software written in Java -The
Java API—a rich, fully featured class library that provides graphical user
interface, data storage, data processing, I/0, and networking support.

While many of the properties of Java are present in other languages, the
sheer popularity and rapid adoption of Java by programmers indicate that
Sun Microsystems found the right mix of functionality and sophistication.
Many of the so-called features of C++, such as multiple inheritance, radically
increased the intricacy of the software. While Java has its origins in C++,
many of the hang-ups of C++ and of the original C language have been
removed, such as multiple inheritance, pointers, and direct memory access.
In addition, Java was designed from the ground up to support the WWW
and the Internet, making it an attractive choice for network programming.
Some of the key properties of Java are object orientation, simplicity,
neutrality architecture, portability, multithreaded programming, security,
and performance.
9.4.1 Object orientation

Java is inherently object-oriented. Although many object-oriented languages
began strictly as procedural languages, Java was designed from the start
to be object-oriented. Object-oriented programming (OOP) is a popular
programming approach that is replacing traditional procedural programming
techniques. Software systems developed using procedural programming
languages are based on the paradigm of procedures. Object oriented
programming is a prototype of the real world in terms of objects. Everything
in the world can be modeled as an object. A circle is an object, a person is
an object, and a Window icon is an object. Even a loan can be apparently
seen as an object. A Java program is object-oriented because programming
in Java is centered on creating objects, manipulating objects, and making
objects work together.
9.4.2 Simplicity
Java Is Simple No language is simple, but Java is a bit easier than the popular
object-oriented programming language C++, which was the dominant
software-development language before Java. Java is partially modeled
on C++, but greatly simplified and improved. For instance, pointers and
multiple inheritance often make programming complicated. Java replaces
the multiple inheritance in C++ with a simple language construct called an
interface, and eliminates pointers. Java uses automatic memory allocation
and garbage collection, whereas C++ requires the programmer to allocate
memory and collect garbage. Also, the number of language constructs is
small for such a powerful language. The clean syntax makes Java programs
easy to write and read. Some people refer to Java as “C++--” because it is
like C++ but with more functionality and fewer negative phases. One of the
central issues in software development is how to reuse code. Object-oriented
programming provides great flexibility, modularity, clarity, and reusability
through encapsulation, inheritance, and polymorphism. For years, object-
oriented technology was perceived as elitist, requiring a sizable investment
in training and infrastructure. Java has helped object-oriented technology
enter the mainstream of computing. Its simple, clean syntax makes programs
easy to write and read. Java programs are quite communicative in terms of
designing and developing applications.
9.4.3 Neutrality of architecture

Java is interpreted. This feature enables Java to be architecture-neutral, or to
use an alternative term, platform-independent. With a Java Virtual Machine
(JVM), you can write one program that will run on any platform. Java’s
initial success stemmed from its Web-programming capability. You can run
Java applets from a Web browser, but Java is for more than just writing
Web applets. You can also run standalone Java applications directly from
operating systems, using a Java interpreter. Today, software vendors usually
develop multiple versions of the same product to run on different platforms
(Windows, OS/2, Macintosh, and various UNIX, IBM AS/400, and IBM
mainframes). Using Java, developers need to write only one version that can
run on every platform.
9.4.4 Portability
Because Java is architecture neutral, Java programs are portable. They can
be run on any platform without being recompiled. Moreover, there are no
platform-specific features in the Java language. In some languages, such as
Ada, the largest integer varies on different platforms. But in Java, the range
of the integer is the same on every platform, as is the behavior of arithmetic.
The fixed range of the numbers makes the program portable. The Java
environment is portable to new hardware and operating systems. In fact, the
Java compiler itself is written in Java. Of course, this portability comes at a
cost. Java source code is compiled into bytecode, which is executed by the
JVM. This means that Java code does not run as fast as native code compiled
to machine language instructions. While some efforts have been made to
boost the performance of Java software, such as just-in-time (JIT) compilers
that convert Java bytecode to native code, developers and users will find
that performance is not as fast when compared to C++ code, and that a
greater amount of memory is used up. There are also, of course, operating-
system-specific differences between Java applications. A Macintosh applet
or application will have a different GUI than that of a Windows or Unix
system. Glitches in initial releases caused problems when running software
on different platforms due to defects in early JVM implementations, but for
the most part, the potential of Java portability remains resilient.
9.4.5 Multithreaded-programming
Multithreading is a program’s capability to perform several tasks
simultaneously. For example, downloading a video file while playing the
video would be considered multithreading. Multithread programming is
smoothly integrated in Java, whereas in other languages you have to call
procedures specific to the operating system to enable multithreading.
Multithreading is particularly useful in graphical user interface (GUI) and
network programming. In GUI programming, there are many things going
on at the same time. A user can listen to an audio recording while surfing
a Web page. In network programming, a server can serve multiple clients
at the same time. Multithreading is a necessity in multimedia and network
programming. A multi-threaded language supports concurrent processing,
but with shared memory for application code and data. This allows threads to
conserve memory and interact with each other to work together if required.
The importance of a multi-threaded language for network programming
cannot be overstated. Though it is possible to write trivial client and server
applications without using multiple threads of execution, even a moderately
complex server will typically use the method of multi-threading. Having
this support within Java is useful, and makes it an attractive choice for
almost any type of programming. Other languages, too, have multi-threaded
support (often in the form of an add-on API or operating system calls), but
Java has been designed from the ground up to support such programming,
and provides language keywords to simplify writing thread-safe code.
9.4.6 Security
In a networked world, security is an extremely important issue for software
developers. After all, systems connected to a public network are far more
vulnerable to attack than a system connected to a closed private network.
When systems contain sensitive data, they are prime targets for attacks, but
even systems with little or no useful data can be compromised and used
to hijack other systems. Because of such risks, developers must take the
issue of security very seriously. Of course, while many developers write
their own security mechanisms, it is often useful if a language administers
some form of security of its own. This can save developers both time and
effort, and it is reassuring to know that users will have an equitable level of
security installed by default. Java is often billed as a “secure” language, and
while it is impossible for a language to guarantee absolute security (much
of this must be the responsibility of individual programmers, and the 24
implementers of the JVM), the Java security model makes it an attractive
choice for network developers. As an Internet programming language, Java
is used in a networked and distributed environment. If you download a Java
applet (a special kind of program) and run it on your computer, it will not
damage your system because Java implements several security mechanisms
to protect your system against harm caused by stray programs. The security
is based on the premise that nothing should be trusted.
9.4.7 Performance
Java’s performance is sometimes criticized. The execution of the bytecode is
never as fast as it would be with a compiled language, such as C++. Because
Java is interpreted, the bytecode is not directly executed by the system, but
is run through the interpreter. However, its speed is more than adequate for
most interactive applications, where the CPU is often idle, waiting for input
or for data from other sources. CPU speed has increased dramatically in the
past few years, and this trend will continue. There are many ways to improve
performance. Users of the earlier Sun Java Virtual Machine certainly noticed
that Java was slow. However, the new JVM is significantly faster. The new
JVM uses the technology known as just-in-time compilation. It compiles
bytecode into native machine code, stores the native code, and reinvokes the
native code when its bytecode is executed. Sun recently developed the Java
HotSpot Performance Engine, which includes a compiler for optimizing the
frequently used code. The HotSpot Performance Engine can be plugged into
a JVM to dramatically boost its performance.
9.5 CORBA
The Common Object Request Broker Architecture (CORBA) is a
standard developed by the Object Management Group (OMG) to provide
interoperability among distributed objects. CORBA is the world’s leading
middleware solution enabling the exchange of information, independent

of hardware platforms, programming languages, and operating systems.
CORBA is essentially a design specification for an Object Request Broker
(ORB), where an ORB provides the mechanism required for distributed
objects to communicate with one another, whether locally or on remote
devices, written in different languages, or at different locations on a network.
The CORBA Interface Definition Language, or IDL, allows the
development of language and location-independent interfaces to distributed
objects. Using CORBA, application components can communicate with
one another no matter where they are located, or who has designed them.
CORBA provides the location transparency to be able to execute these
applications. CORBA is often described as a “software bus” because it is a
software-based communications interface through which objects are located
and accessed.
The CORBA is composed of five major components namely ORB Core,
Interface Definition Language, Dynamic Invocation Interface, Interface
Repository, and Object Adapters. A CORBA ORB integrates Java objects
smoothly in the distributed computing environment while providing
many common object services. CORBA objects are packaged as binary
components and resided anywhere on a network. The remote clients can
access server objects via method invocation, without knowing where the
distributed objects reside or on which operating system it executes on.
The illustration below identifies the primary components seen in a
CORBA implementation.
Figure 9.2: Primary components in a CORBA implementation.Source: http://

www.ois.com/Products/what-is-corba.html
9.5.1 Dynamic Invocation Interface

Invoking operations can be done through either static or dynamic interfaces.
Static invocation interfaces are determined at compile time, and they are
presented to the client using stubs. The Dynamic Invocation Interface (DII),
on the other hand, allows client applications to use server objects without
knowing the type of those objects at compile time. It allows a client to
obtain an example of a CORBA object and make invocations on that object
by dynamically constructing requests. DII uses the interface repository to
validate and retrieve the signature of the operation on which a request is
made. CORBA supports both the dynamic and the static invocation interfaces.
Analogous to the DII is the server-side dynamic skeleton interface (DSI),
which allows servers to be written without having skeletons, or compile-
time knowledge, for the objects being implemented. Unlike DII, which was
part of the initial CORBA specification, DSI was introduced in CORBA
2.0. Its main purpose is to support the implementation of gateways between
ORBs which utilize different communication protocols. However, DSI has
many other applications beside interoperability. These applications include
interactive software tools based on interpreters and distributed debuggers.
9.5.2 Interface repository

The Interface Repository (IR) provides another way to specify the interfaces
to objects. Interfaces can be added to the interface repository service.
Using the IR, a client should be able to locate an object that is unknown at
compile time, find information about its interface, then build a request to
be forwarded through the ORB. n interface repository contains hierarchies
of objects whose methods divulge information about interfaces. Although
interfaces are usually thought of as describing objects, using a collection
of objects to describe interfaces makes sense in a CORBA environment
because it requires no new mechanism such as a database. As an example of
the kinds of objects an IR can contain, consider that IDL files can contain
IDL module definitions, and modules can contain interface definitions, and
interfaces can contain operation (method) definitions. Correspondingly,
an interface repository can contain Module Defobjects which can contain
Interface Defobjects, which can contain Operation Defobjects. Thus, from
an IR Module Def, you can learn what Interface Def sit contains. The
reverse is also true--given an Interface Def you can learn what Module Defat
is contained in. All other IDL constructs including exceptions, attributes,
and valuetypescan be represented in an interface repository. An interface
repository also contains type codes. Type codes are not explicitly listed in
IDL files, but are automatically derived from the types (long, string, struct,
and so on) that are defined or mentioned in IDL files. Type codes are used
to encode and decode instances of the CORBA any type--a generic type that
stands for any type and is used with the dynamic invocation interface.
9.5.3 Object Adapters

An object adapter is the primary way that an object implementation accesses
services provided by the ORB. Such services include object reference
generation and interpretation, method invocation, security of interactions,
object and implementation activation, and deactivation. An object adapter
(OA) provides the means by which various types of object implementations
utilize ORB services, such as: i. Object reference generation ii. Object
method invocation iii. Security iv. Activation and deactivation of objects
and implementations Depending on the underlying ORB, an OA may
choose to provide these services by delegating to the ORB or by performing
the work itself. In either case, object implementations are not aware of the
difference because they interface only to the OA. Each ORB is expected
to provide a general OA, called the Basic Object Adapter (BOA), which
is intended to support objects implemented as separate programs. It is
expected that most object implementations can work with the BOA because
its services are flexible enough to accommodate several different kinds of
object implementations: i. Persistent implementations which are activated
by something other than the BOA. ii. Shared implementations in which
multiple objects coexist in the same program. iii. Unshared implementations
in which only one object implementation exists per program. iv. Server-per-
method implementations in which each operation supported by an object is
a separate program.
9.5.4 Interface Definition Language

The interface definition language (IDL) is used to describe types used by
CORBA, from the basic types of individual arguments to the complex types
of interfaces and objects. The language is similar in syntax to C++.As with
RMI, CORBA objects are to be specified with interfaces, which are the
contract between the client and server. In CORBA’s case, however, interfaces
are specified in the special definition language IDL. The IDL defines the
types of objects by defining their interfaces. An interface consists of a set of
named operations and the parameters to those operations. Note that IDL is
used to describe interfaces only, not implementations. Despite the fact that
IDL syntax is similar to C++ and Java, IDL is not a programming language.
Through IDL, a particular object implementation tells its potential clients
what operations are available and how they should be invoked. From IDL
definitions, the CORBA objects are mapped into different programming
languages. Some of the programming languages with IDL mapping include
C, C++, Java, Smalltalk, Lisp, and Python. Thus, once you define an
interface to objects in IDL, you are free to implement the object using any
suitable programming language that has IDL mapping. And, consequently,
if you want to use that object, you can use any programming language to
make remote requests to the object.
1. Basic Types
The integer types are short, long and long long for signed integer numbers
of 16, 32 and 64 bits and unsigned short, unsigned long and unsigned long
for their unsigned counterparts.
const short aShortConstant = 6 * 7;
Thefloating point typesarefloat, doubleandlong doublefor ANSI/IEEE 754-
1985 single precision, double precision and double extended precision
floating point numbers.
const float aFloatConstant = 3.141593;
Thecharacter typesarecharfor a single character in a single-byte character
set andwcharfor a single character in a multiple-byte character set. The
interface definition language itself uses ISO 8859-1 Latin 1.
const char aTab = ‘\t’;
const wchar aWideTab = L’\t’;
Thelogical typeisbooleanwith values of true and false.
const boolean aTrueValue = TRUE;
const boolean aFalseValue = FALSE;
Thespecial typesareoctetfor 8 bits of raw data andanyfor a container of
another arbitrary type
2. Constructed Data Types

Astructurerepresents a classical compound type with named members that
all contain a value. struct aPerson {string firstName; string lastName; short
age;};
Anexceptionis a structure that can be returned as an exceptional result of an

operation. A number of standard exceptions are defined. Note there is no
inheritance in exception declarations. However, language mappings do add
inheritance to make it easier to catch standard exceptions.
exception anException
{
string reason;
string severity;
};
exception COMM_FAILURE
{
unsigned long minor;
completion_status completed;
}; Aunionrepresents a classical compound type with named members out of
which, one contains a value. A discriminator is used to determine which of
the members contains the value.
union aSillyUnion switch (short)
{
case 1: long aLongValue;
case 2: float aFloatValue;
default: string aStringValue;
};
Anenumrepresents a classical enumerated type with distinct identifiers
stored as 32 bit unsigned integers. enum aBaseColor {red, green, blue} An-
arrayis a container for a fixed number of items of the same type addressed
by integer indices. typedef long aLongArray [10];Asequenceis a container
for a variable number of items of the same type addressed by integer indices.
The maximum number of items in the container can be limited explicitly. ty-
pedef sequence<long,10> aBoundedVector; typedef sequence<long> anUn-
boundedVector; Astringis a sequence of char items. Awstringis a sequence
of wchar items. typedef string<10> aBoundedString;
typedef string anUnboundedString; Afixed pointtype represents a fixed point
number of up to 31 significant digits.
typedef fixed<10,2> aPrice;
3. Constructed Object Types

Aninterface typerepresents an object that is passed by reference and accessed
remotely. The declaration of an interface type can specify multiple interface
inheritance, attributes and operations. Apart from this, the declaration also
creates a lexical scope within which other declarations can appear.
abstract interface aParentInterface

{
attribute string aStringAttribute;
short aMethod (in long aLongArgument, inout float aFloatArgument);
}
interface aChildInterface: aParentInterface
{
readonly attribute short aShortAttribute;
oneway void aOnewayMethod (in long anArgument);
void aTwowayMethod () raises anException;
}
In some situations, it might be useful to have an interface type that can
represent both an object passed by reference and an object passed by value.
This is possible when the interface is denoted as abstract. It is also possible
to use interface types to describe objects that are not invoked through COR-
BA; the interface types are then denoted as local. A value type represents
an object that is passed by value and accessed locally. The declaration of
a value type can specify single value type inheritance, single interface and
multiple abstract interface support, attributes with private or public visibil-
ity, operations, and initializers. Apart from this, the declaration also creates
a lexical scope within which other declarations can appear.
valuetype aChildValue: truncatable aParentValue, supports anInterface
{
private short aShortMember;
public aParentValue aValueMember;
factory aFactory (in string anArgument);
short aLocalMethod (in long aLongArgument, in float aFloatArgument);
}
A value type can support multiple abstract interfaces but only a single inter-
face that is not abstract. When used as an instance of one of the supported
abstract interfaces, the value type is passed by value. When used as an in-
stance of the supported interface that is not abstract, the value type is passed
by reference. When an object is passed by value, it might happen that an
implementation of its type is not available to the receiver, but an implemen-

tation of its parent type is. When a value type is denoted as “truncatable,”
its implementation is considered compatible with the implementation of its
parent to the degree that the state of the type can be truncated to the portion
inherited from its parent and used by its parent. A value type that is declared
custom will rely on user defined marshaling implementation. A custom val-
ue type may not be truncatable.
REFERENCES
1. Coulouris, G., Dollimore, J., & Kindberg, T. (2005).Distributed
systems: Concepts and design (4th ed.). London, England: Addison-
Wesley.
2. Brosgol, B. M. Introduction to Ada 95.Retrieved January 2018,
from https://www.embedded.com/electronics-blogs/beginner-s
corner/4024497/Introduction-to-Ada-95
3. Liang, Y. Introduction to Java programming. Retrieved from http://
www.cs.armstrong.edu/liang/JavaCharacteristics.pdf
CHAPTER 10
WIRELESS SENSOR NETWORK
“Wireless sensor and actuator nets, also known as motes and smart dust, are
an emerging computer class based on a new platform, networking structure,
and interface that enable novel, low cost, high volume, applications.”
-Gordon Bell, Senior Researcher, Microsoft Corporation
CONTENTS
10.1 Sensing and Sensors............................................................................................ 208
10.2 Wireless Sensor Networks.................................................................................... 213
10.3 Medium Access Control (MAC)............................................................................ 217
10.4 Operating Systems............................................................................................... 218
10.5 Middleware......................................................................................................... 223
10.6 Challenges and Constraints.................................................................................. 224
10.7 Applications of Wireless Sensor Networks........................................................... 227
References................................................................................................................... 229
Sensors link the physical with the digital world by capturing and revealing
real-world phenomena and converting these into a form that can be processed,
stored, and acted upon. Integrated into numerous devices, machines, and
environments, sensors provide a tremendous societal benefit. This chapter
describes the major concepts behind wireless sensor networks (WSN). It is
a good reference for anyone interested in learning how wireless sensors and
wireless sensor networks work and what different solutions exist in terms
of operating software, network layouts and routing. It starts by discussing
the sensing and sensors and goes on to explain main components of wireless
sensor networks (WSNs). It also gives an exposition of the fundamental
aspects of wireless sensor networks and communication techniques. An
extensive discussion and revision of information processing and application
of WSNs are given towards the end of this chapter.
10.1 SENSING AND SENSORS

Sensing is a system used to obtain facts about a physical object or process,
including the incidence of events (i.e., changes in states such as a reduction
in temperature or pressure). An object performing such a sensing task is
called a sensor. For example, the human body is equipped with sensors that
are able to capture photosensitive information from the surroundings (eyes),
aural information such as sounds (ears), and perceive (nose). These are
examples of remote sensors, that is, they do not need to touch the monitored
object to obtain information. From a technical angle, a sensor is a device
that interprets events in the real world into signals that can be measured
and evaluated. Another commonly used term is a transducer, which is often
used to describe a device that transforms energy from one form into another.
A sensor, then, is a type of transducer that transforms energy in the real
world into electrical energy that can be passed to a computing system or
controller. Phenomena in the physical world (often referred to as process,
system, or plant) are observed by a sensor device. The resulting electrical
signals are often not ready for immediate processing; therefore they pass
through a signal conditioning stage. Here, a variety of operations can be
applied to the sensor signal to prepare it for further use. For example, signals
often require amplification (or attenuation) to change the signal magnitude
to better match the range of the following analog-to-digital conversion.
Further, signal conditioning often applies filters to the signal to remove
unwanted noise within certain frequency ranges (e.g., highpass filters can
be used to remove 50 or 60 Hz noise picked up by surrounding power lines).
Wireless Sensor Network 209
After conditioning, the analog signal is transformed into a digital signal

using an analog-to-digital converter (ADC). The signal is now available in
a digital form and ready for further processing, storing, or visualization.
Many wireless sensor networks also include actuators which allow them
to directly control the physical world. For example, an actuator can be
a valve controlling the flow of hot water, a motor that opens or closes a
door or window, or a pump that controls the amount of fuel injected into
an engine (Dargie, W. and Poellabauer, 2010). According to Sohraby et al.
as described in the book “Wireless Sensor Networks,” the capabilities of
sensors are explained as a functionality of the environment.
Sensors can be simple point elements or can be multipoint detection
arrays. Typically, nodes are equipped with one or more application-specific
sensors and with on-node signal processing capabilities for extraction
and manipulation (preprocessing) of physical environment information.
Embedded network sensing refers to the synergistic incorporation of
microsensors in structures or environments; embedded sensing enables
spatially and temporally dense monitoring of the system under consideration
(e.g., an environment, a building, a battlefield). Sensors may be passive
and/or be self-powered; farther down the power-consumption chain, some
sensors may require relatively low power from a battery or line feed. At the
high end of the power-consumption chain, some sensors may require very
high power feeds (e.g., for radars). Sensors facilitate the instrumenting and
controlling of factories, offices, homes, vehicles, cities, and the ambiance,
especially as commercial off-the-shelf technology becomes available. With
sensor network technology (specifically, with embedded networked sensing),
ships, aircraft, and buildings can ‘‘self-detect’’ structural faults (e.g., fatigue-
induced cracks). Places of the public assembly can be instrumented to detect
airborne agents such as toxins and to trace the source of the contamination
should any be present (this can also be done for ground and underground
situations) (Sohraby,Daniel Minoli, &Znati, 2007).
Many wireless sensor networks also include actuators which allow them
to directly control the physical world. For example, an actuator can be a
valve controlling the flow of hot water, a motor that opens or closes a door or
window, or a pump that controls the amount of fuel injected into an engine.
Such a wireless sensor and actuator network (WSAN) takes commands from
the processing device (controller) and transforms these commands into input
signals for the actuator, which then interacts with a physical process, thereby
forming a closed control loop.
Table 10.1: Classification and Examples of Sensors
Type Examples
Temperature Thermistors, thermocouples
Pressure Pressure gauges, barometers, ionization gauges
Optical Photodiodes, phototransistors, infrared sensors, CCD
sensors
Acoustic Piezoelectric resonators, microphones
Mechanical Strain gauges, tactile sensors, capacitive diaphragms,
piezoresistive cells
Motion, vibration Accelerometers, gyroscopes, photo sensors
Flow Anemometers, mass air flow sensors
Position GPS, ultrasound-based sensors, infra-red sensors, in-
clinometers
Electromagnetic Hall-effect sensors, magnetometers
Chemical pH sensors, electrochemical sensors, infrared gas sen-
sors
Humidity Capacitive and resistive sensors, hygrometers, MEMS-
based humidity sensors
Radiation Ionization detectors, Geiger-Mueller counters
Source: http://bayanbox.ir/view/4489134451971294360/Fundamentals-of-
Wireless-Sensor-Networks-Waltenegus-Dargie.pdf
10.1.1 Sensor nodes technology

A sensor node is made up of four basic components such as sensing unit,
processing unit, transceiver unit, and a power unit as shown in the figure
below. It also has application dependent additional components such as a
location finding system, a power generator, and a mobilizer. Sensing units
are usually composed of two subunits: sensors and analogue to digital
converters (ADCs) (Akyildiz,Su, Sankarasubramaniam, &Cayirci, 2002).
The analogue signals produced by the sensors are converted to digital
signals by the ADC and then fed into the processing unit. The processing
unit is generally associated with a small storage unit,and it can manage the
procedures that make the sensor node collaborate with the other nodes to
carry out the assigned sensing tasks. A transceiver unit connects the node to
the network. One of the most important components of a sensor node is the
power unit. Power units can be supported by a power scavenging unit such
as solar cells. The other subunits of the node are application dependent. A
functional block diagram of a versatile wireless sensing node is provided

as shown. Modular design approach provides a flexible and versatile
platform to address the needs of a wide variety of applications. For example,
depending on the sensors to be deployed, the signal conditioning block can
be re-programmed or replaced. This allows for a wide variety of different
sensors to be used with the wireless sensing node. Similarly, the radio link
may be swapped out as required for a given applications’ wireless range
requirement and the need for bidirectional communications.
Figure 10.1: A sensor node. Source: http://rsta.royalsocietypublishing.org/con-

tent/370/1958/68
10.1.2 Sensor classifications

The type of sensors should be selected for an application depends on the
physical property to be checked, for example, such properties include
temperature, pressure, light, or humidity. Apart from physical properties,
the classification of sensors can be based on a range of other methods, for
example, whether they require an external power supply. If the sensors
require external power, they are referred to as active sensors. That is, they
must emit some kind of energy (e.g.,microwaves, light, sound) to trigger
a response or to detect a change in the energy of the transmitted signal.
On the other hand, passive sensors detect energy in the environment and
derive their power from this energy input—for example, passive infrared
(PIR) sensors measure infrared light radiating from objects in the proximity.
The classification of sensors can also be based on the methods they apply
and the electrical phenomena they utilize to convert physical properties
into electrical signals. Resistive sensors rely on changes to a conductor’s
electrical resistivity, ρ, based on physical properties such as temperature.
The resistance, R, of a conductor can be determined as:
´r
R=
A (10.1)
where ℓ is the length of the conductor and A is the area of the cross-section.
For example, the well-known Wheatstone bridge as indicated in the figure
below is a simple circuit that can be used to convert a physical property
into an apparent electric effect. In this bridge, R1, R2, and R3 are resistors
of known resistance (where the resistance of R2 is adjustable) and Rx is a
resistor of unknown value. If the ratio R2/R1 is identical to the ratio Rx/R3, the
measured voltage VG will be zero. However, if the resistance of Rx changes
(e.g., due to changes in temperature), there will be an imbalance, which will
be reflected by a change in voltage VB. If all four resistor values and the
supply voltage (VS) are known, and the resistance of the galvanometer is high
enough thatIGis negligible, the voltage across the bridge (VG) can be found
by working out the voltage from eachpotential dividerand subtracting one
from the other. The equation for the relationship between these parameters
is:
æç
VG = VS ´ ççç
R2 - RX ö÷÷÷÷
÷
ççè R1+R 2 RX + R 3 ÷ø
(10.2)
{\displaystyle V_{G}=\left ({R_{2}\over {R_{1}+R_{2}}}-{R_{x}\over
{R_{x}+R_{3}}}\right) V_{s}} where VG is the voltage of node D relative
to node B.
Figure 10.2: A schematic of a wheatstone bridge circuit. Source: https://

en.wikipedia.org/wiki/Wheatstone_bridge
A similar principle can be applied to capacitive sensors, which can be
used to measure motion, proximity, acceleration, pressure, electric fields,
chemical compositions, and liquid depth. For example, in the parallel plate
model, that is, a capacitor consisting of two parallel conductive plates
separated by a dielectric with a certain permittivity ε, the capacitance is
determined as:
e´A
C = (10.3)
d
where A is the plate area and d is the distance between the two plates.
Similar to the resistive model, changes in any of these parameters will
change the capacitance. For example, if pressure is applied to one of the two
plates, the separation d can be reduced, thereby increasing the capacitance.
Similarly, a change in the permittivity of the dielectric can be caused by
an increase in temperature or humidity, thereby resulting in a change in
capacitance. Existing and potential applications of sensor networks include,
among others, military sensing, physical security, air traffic control, traffic
surveillance, video surveillance, industrial and manufacturing automation,
process control, inventory management, distributed robotics, weather
sensing, environment monitoring, national border monitoring, and building
and structures monitoring.
10.2 WIRELESS SENSOR NETWORKS

Wireless Sensor Networks (WSNs) can be defined as a self-configured,
structureless and wireless networks capable of monitoring physical or
environmental conditions, such as temperature, sound, vibration, pressure,
motion or pollutants and compliantly transfer their data through the network
to a main location or sink where the data can be observed and analyzed. A
sink or base station acts like an interface between users and the network.
One can retrieve required information from the network by injecting queries
and gathering results from the sink. Typically a wireless sensor network
contains hundreds of thousands of sensor nodes. The sensor nodes can
communicate among themselves using radio signals. A wireless sensor
node is equipped with sensing and computing devices, radio transceivers
and power components. The individual nodes in a wireless sensor network
(WSN) are inherently resource constrained: they have limited processing
speed, storage capacity, and communication bandwidth. After the sensor
nodes are deployed, they are responsible for self-organizing an appropriate
network infrastructure often with multi-hop communication with them.
Then the onboard sensors start collecting information of interest. Wireless
sensor devices also respond to queries sent from a “control site” to perform
specific instructions or provide sensing samples. The working mode of the
sensor nodes may be either continuous or event driven. Global Positioning
System (GPS) and local positioning algorithms can be used to obtain

location and positioning information. Wireless sensor devices can be
equipped with actuators to “act” upon certain conditions. These networks
are sometimes more specifically referred as Wireless Sensor and Actuator
Networks as described in (Akkaya et al., 2005). Wireless sensor networks
(WSNs) enable new applications and require non-conventional paradigms
for protocol design due to several constraints. Owing to the requirement for
low device complexity together with low energy consumption (i.e., long
network lifetime), a proper balance between communication and signal/
data processing capabilities must be found. This motivates a huge effort
in research activities, standardization process, and industrial investments
on this field as the last decade (Chiara et. al. 2009). At present time, most
of the research on WSNs has concentrated on the design of energy- and
computationally efficient algorithms and protocols, and the application
domain has been restricted to simple data-oriented monitoring and reporting
applications (Labrador et. al. 2009). From the discussion so far, it becomes
clear that many design choices in a WSN differ from the design choices of
other systems and networks.
Figure 10.3: A Wireless Sensor Network Model. Source: https://www.re-

searchgate.net/publication/269629454_A_novel_differential_evolution_
based_clustering_algorithm_for_wireless_sensor_networks/figures? lo=1
The table below summarizes some of the key differences between traditional
networks and wireless sensor networks.
Table 10.2: Comparison of Traditional Networks and Wireless Sensor Networks
Traditional Networks Wireless Sensor Networks

General-purpose design; serving many Single-purpose design; serving one spe-
applications cific application
Typical primary design concerns are Energy is the main constraint in the
network performance and latencies; en- design of all node and network compo-
ergy is not a primary concern nents
Networks are designed and engineered Deployment, network structure, and
according to plans resource use are often ad hoc (without
planning)
Devices and networks operate in con- Sensor networks often operate in envi-
trolled and mild environments ronments with harsh conditions
Maintenance and repair are common, Physical access to sensor nodes is often
and networks are typically easy to ac- difficult or even impossible
cess
Component failure is addressed through Component failure is expected and ad-
maintenance and repair dressed in the design of the network
Obtaining global network knowledge is Most decisions are made localized with-
typically feasible, and centralized man- out the support of a central manager
agement is possible
Structure of a Wireless Sensor Network includes different topologies for
radio communications networks. A succinct discussion of the network
topologies that apply to wireless sensor networks are outlined below:
10.2.1 Star topology

A star network is a communications topology where a single base station
can send and/or receive a message to a number of remote nodes. The remote
nodes are not permitted to send messages to each other. The advantage of
this type of network for wireless sensor networks includes simplicity, ability
to keep the remote node’s power consumption to a minimum. It also allows
low latency communications between the remote node and the base station.
The disadvantage of such a network is that the base station must be within
radio transmission range of all the individual nodes and is not as robust as
other networks due to its dependency on a single node to manage the net-
work. The gateway can be a computer or a dedicated embedded device, and
it acts both to communicate data and commands among nodes and to trans-
fer data to an application or other network, such as the Internet. Nodes do
not transmit data or commands to each other, directly. They use the gateway
as a coordination point where all data flow is concentrated.
10.2.2 Tree topology

In the tree topology, there are leaf nodes, relay nodes and parent nodes. This
topology consists of a central node called the root node, and it is the main
communications router and interface with the application or other parts of

a larger network. One level down from the root node in the hierarchy is a
relay node that may have several offspring nodes connected to it and so on.
This network configuration is designed to optimize power consumption and
to extend the network communication range. However, data transmission
and operations are scheduled, which requires time synchronization between
all nodes.
10.2.3 Mesh topology

This kind of network topology connects each node to all the nodes within
its radio range. It has the potential for reduced power consumption when
compared to other topologies using long distances, as each node can
establish a radio link with the closest neighbors. However, it is required that
nodes are always waked up, because they can be part of the path between
any other node and the gateway. A mesh network allows transmitting data
to one node to other node in the network that is within its radio transmission
range. This allows for what is known as multi-hop communications, that
is, if a node wants to send a message to another node that is out of radio
communications range, it can use an intermediate node to forward the
message to the desired node. This network topology has the advantage of
redundancy and scalability. If an individual node fails, a remote node still
can communicate to any other node in its range, which in turn, can forward
the message to the desired location. In addition, the range of the network is
not necessarily limited by the range in between single nodes; it can simply
be extended by adding more nodes to the system. The disadvantage of this
type of network is in power consumption for the nodes that implement the
multi-hop communications are generally higher than for the nodes that don’t
have this capability, often limiting the battery life.
10.2.4 Hybrid topology

Some network topologies used for wireless sensor network applications use
a hybrid combination of the previous topologies, to create larger networks
consisting of hundreds, even thousands of nodes. A hybrid network consists
of a combination of star and mesh topologies. This combination results
on a star-mesh network that seeks to take advantage of the low power and
simplicity of the star topology, as well as the extended range and self-
healing nature of a mesh network topology. In this case, nodes serve to
sense, extend the range of the network and provide fault tolerance. As nodes
can communicate with multiple other nodes, if a node fails or if a radio link
goes down (e.g., due to interferences or lack of battery), the network will
reconfigure itself around the remaining nodes.
Figure 10.4: Wireless Sensor Network Topologies. Source: https://www.elpro-

cus.comintroduction-to-wireless-sensor-networks-types-and-applications/
10.3 MEDIUM ACCESS CONTROL (MAC)

One major difficulty in designing effective MAC protocols for shared access
media arises from the spatial distribution of the communicating nodes. To
reach agreement as to which node can access the communication channel
at any given time, the nodes must exchange some amount of coordinating
information. The exchange of this information, however, typically requires
use of the communication channel itself. This recursive aspect of the multi-
access medium problem increases the complexity of the access control
protocol and consequently, the overhead required to regulate access among
the competing nodes. Furthermore, spatial distribution does not allow a
given node on the network to know the instantaneous status of other nodes
on the network. Any information explicitly or implicitly gathered by any
node is at least as old as the time required for its propagation through
the communication channel. The medium access control (MAC) layer is
responsible for providing sensor nodes with access to the wireless channel.
Some MAC strategies for communication networks are contention-based,
that is, nodes may attempt to access the medium at any time, potentially
leading to collisions among multiple nodes, which must be addressed by the
MAC layer to ensure that transmissions will eventually succeed. Downsides
of these approaches include the energy overheads and delays incurred by the
collisions and recovery mechanisms and that sensor nodes may have to listen
to the medium at all times to ensure that no transmissions will be missed.
Therefore, some MAC protocols for sensor networks are contention-free,

that is, access to the medium is strictly regulated, eliminating collisions and
allowing sensor nodes to shut down their radios when no communications are
expected. The network layer is responsible for finding routes from a sensor
node to the base station and route characteristics such as length (e.g., in terms
of number of hops), required transmission power, and available energy on
relay nodes determine the energy overheads of multi-hop communication.
Determining the nature and extent of information used by a distributed
multiple access protocol is a difficult task, but potentially a valuable one.
An understanding of exactly what information is needed could lead to an
appreciation of its value. Most of the proposed distributed multiple access
protocols for WSNs operate somewhere along a spectrum of information
ranging from a minimum amount of information to perfect information.
Furthermore, the information can be predetermined, dynamic global, or
local. Predetermined information is known to all communicating nodes.
Dynamic global information is acquired by different nodes during protocol
operation. Local information is known to individual nodes. Predetermined
and dynamic global information may result in efficient, potentially perfect
coordination among the nodes. However, there usually is a high price to
pay in terms of wasted channel capacity. The use of local information has
potential to reduce the overhead required to coordinate the competing nodes,
but may result in poor overall performance of the protocol.
10.4 OPERATING SYSTEMS

The design of operating system for Wireless Sensor Network (WSN) deviates
from traditional operating system design due to significant and specific
characteristics like constrained resources, high dynamics and inaccessible
deployment.
10.4.1 TinyOS
TinyOSis an open source, flexible, component based, and application-
specific operating system designed for sensor networks. TinyOS can support
concurrent programs with very low memory requirements. The OS has a
footprint that fits in 400 bytes. The TinyOS component library includes
network protocols, distributed services, sensor drivers, and data acquisition
tools. TinyOS falls under the monolithic architecture class. TinyOS uses
the component model and, according to the requirements of an application,
different components are glued together with the scheduler to compose
a static image that runs on the mote. A component is an independent

computational entity that exposes one or more interfaces. Components have
three computational abstractions: commands, events, and tasks. Mechanisms
for inter-component communication are commands and events. Tasks are
used to express intra-component concurrency. A command is a request to
perform some service, while the event signals the completion of the service.
TinyOS provides a single shared stack,and there is no separation between
kernel space and user space. The figure below shows the TinyOS architecture.
Figure 10.5: TinyOS architecture. Source: https://www.slideshare.net/snecute/

tinyos
10.4.2 Sensor operating system

Han et al. described Sensor Operating system (SOS) as an operating
system that attempts to establish a balance between flexibility and resource
efficiency. Unlike TinyOS, it supports runtime reconfiguration and
reprogramming of program code. The OS consists of a kernel and a set
of modules that can be loaded and unloaded. In functionality, a module is
similar to a TinyOS component—it implements a specific task or function.
Moreover, in the same way that TinyOS components can be “wired” to build
an application, a SOS application is composed of one or more interacting
modules. Unlike a TinyOS component, which has a static place in memory, a
module in SOS is a position-independent binary. This typical feature enables
SOS to dynamically link modules with each other. The SOS kernel provides
interfaces to the underlying hardware. Additionally, it provides a priority-
based scheduling mechanism and supports dynamic memory allocation.
Interaction with a module takes place through messages (asynchronous
communication) and direct calls to registered functions (synchronous
communication). A message that originates from module A to module B

should first go through the scheduler which places it in a priority queue. Then
the kernel calls the appropriate message handler in module B and passes the
message to it. Modules implement message handlers that are specific to their
purpose of existence. A module can also interact with another module by
directly calling one of its registered functions. Interaction through a function
call is faster than the message-based communication. This approach requires
modules to explicitly register their public functions at the kernel. All modules
that are interested in these functions have to subscribe to them. A function
registration takes place by calling a system function called ker_register_fn
at the time of module initialization. The call enables the module to inform
the kernel where in its binary image the function is implemented. The kernel
completes the registration by creating a function control block (FCB),
which stores key information about the function. This information is used to
handle function subscription and to support dynamic memory management
and runtime module update (replacement). Modules subscribe to a named
function by calling the ker_get_handle system function. In doing so, they
provide the kernel with the module’s and function’s IDs, which will be used
to locate the FCB of interest. If the lookup is successful, the kernel returns
a pointer to the function pointer of the subscribed function. The subscriber
accesses the subscribed function by dereferencing the pointer. This enables
the kernel to replace the function with a newer version by changing the
function pointer in the FCB. The process is transparent to the subscribers.
10.4.3 Contiki
Contiki (Dunkels et al. 2004) is a hybrid operating system. By default, its
kernel functions as an event-driven kernel but multithreading support is
implemented as an application library. There is a dynamic linking strategy
to couple the multithreading library with applications that explicitly require
it. Like SOS, Contiki realizes the separation of the basic system support
(by the kernel) from the rest of dynamically loadable and reprogrammable
services, which are called processes. The services communicate with each
other through the kernel by posting events. The kernel itself does not provide
any hardware abstraction; instead it allows device drivers and applications
to communicate directly with the hardware. This restricted scope of the
kernel makes it easy to reprogram and replace services. Each Contiki
service manages its own state in a private memory and the kernel keeps a
pointer to the process state. However, a service shares with other services
the same address space. It also implements an event handler and an optional
poll handler. All OS facilities, e.g., senor data handling, communication,

and device drivers are provided in the form of services. Each service has
its interface and implementation. Applications using a particular service
need to know the service interface. An application is not concerned about
the implementation of a service. In terms of threading, Contiki supports
preemptive multithreading. Multi-threading is implemented as a library on
top of the event-driven kernel. The library can be linked with applications
that require multithreading. The Contiki multithreading library is divided
in two parts: a platform independent part and a platform specific part. The
platform independent part interfaces to the event kernel and the platform
specific part of the library implements stack switching and preemption
primitives. As preemption is supported, preemption is implemented using
the timer interrupt and the thread state is stored on a stack. The figure below
shows the block diagram of Contiki architecture.
Figure 10.6: Block diagram of Contiki Architecture. Source: http://www.mdpi.

com/1424-8220/11/6/5900/htm
10.4.4 LiteOS
LiteOS is a Unix-like operating system designed for WSNs at the University
of Illinois at Urbana-Champaign. The motivations behind the design
of a new OS for WSN are to provide a Unix-like OS for WSN, provide
system programmers with a familiar programming paradigm (thread-based
programming mode, although it provides support to register event handlers
using callbacks), a hierarchical file system, support for object-oriented
programming in the form of LiteC++, and a Unix-like shell. The footprint
of LiteOS is small enough to run on MicaZ nodes having an 8 MHz CPU,
128 bytes of program flash, and 4 Kbytes of RAM. LiteOS is primarily
composed of three components: LiteShell, LiteFS, and the Kernel.
LiteOS follows a modular architecture design. LiteOS is partitioned into

three subsystems: LiteShell, LiteFS, and the Kernel. LiteShell is a Unix-like
shell that provides support for shell commands for file management, process
management, debugging, and devices. An interesting aspect of the LiteOS is
its LiteShell that resides on a base station or a PC. This leverages to support
more complex commands as the base station has abundant resources. The
LiteShell can only be used when there is a user present on a base station.
Some local processing is done on the user command (parsing a command)
by the shell,and then it is transmitted wirelessly to the intended sensor node.
The sensor node does the required processing on the command and sends
a response back, which is then displayed to the user. When a mote does
not carry out the commands, an error code is returned. It is worth noting
that Contiki and Mantis also provide a shell to interact with the motes but
the implementation code resides on the mote, limiting the capabilities of
the shell due to resource constraints. The second architectural component
of LiteOS is its file system LiteFS. LiteFS mounts all neighboring sensor
nodes as a file. LiteFS mounts a sensor network as a directory and then
list all one hop sensor nodes as a file. A user on the base station can use
this directory structure just like the normal Unix directory structure,and a
user can also use legitimate commands on these directories. The third major
component of LiteOS is the Kernel that resides on the sensor node. The
LiteOS kernel provides concurrency in the form of multithreading, provides
support for dynamic loading, uses round robin and priority scheduling,
allows programmers to register event handlers through callback functions,
and provides synchronization support. Figure 10.7shows the architecture of
LiteOS.
Figure 10.7: LiteOS Architecture. Source: https://www.researchgate.net/fig-

ure/LiteOS-Architecture_307545793
Table 10.3: Comparative Analysis of Functional Aspects of Existing Operating

Systems
OS Programming Building blocks Scheduling Memory System

paradigm allocation calls
TinyOS Event-based Components, FIFO Static None
(split-phase interfaces an d
execution, active tasks
messages)
SOS Event-based Modules and FIFO Dynamic None
messages
Contiki Predominantly Services, ser- FIFO, poll Dynamic Runtime
event-based vice interface handlers libraries
but it provides stubs,and service with priority
optional support layer scheduling
for multithread-
ing
LiteOS Thread-based Applications Priority- Dynamic A host of
(based on thread are independent based sched- system
pools) entities uling with calls avail-
an optional able to the
Round-robin user
support
Adapted from: Dargie, W. and Puellabauer, C. (2010). Fundamentals of

Wireless Sensor Networks: Theory and Practice.
10.5 MIDDLEWARE
Middleware derives from the gap between the high-level requirements from
pervasive computing applications and the complexity of the operations in
the underlying WSNs. The application requirements include high flexibility,
re-usability, and reliability. The complexity of the operations with a WSN is
characterized by constrained resources, dynamic network topology, and low
level embedded OS APIs. WSN middleware provides a probable solution to
bridging the gap and eliminating the inhibitions. In the initial stage of the
research on WSN, people did not pay much attention to middleware because
the simplicity of the early applications did not show much request for the
support from the middleware. Along with the rapid evolution in this area, the
gap becomes increasingly obvious and hinders the popularity of WSN-based
applications. WSN middleware helps the programmer develop applications
in several ways. First, it provides appropriate system abstractions, so that the
application programmer can focus on the application logic without caring
too much about the lower level implementation details. Second, it provides
reusable code services, such as code update, and data services, such as data
filtering, so that the application programmer can deploy and execute the
application without being troubled with complex and tedious functions.
Third, it helps the programmer in network infrastructure management and
adaptation by providing efficient resource services, e.g., power management.
It also supports system integration, monitoring, as well as system security in
distributed computing systems, WSN poses new challenges to middleware
research. The traditional middleware techniques cannot be applied directly
to WSNs. First, most distributed system middleware techniques aim at
providing transparency abstractions by hiding the context information, but
WSN-based applications should usually be context aware. Second, although
many mobile computing middleware supports context awareness, their major
concern is how to continuously satisfy the interests of individual mobile
nodes in the presence of mobility. In contrast, WSN-based systems are data
centric, reflecting the whole application’s interests. Thus, the locations and
mobility of the sensor nodes should be handled by WSN middleware in a
different way. For example, a node moving away from a phenomenon may
choose to hand off the monitoring responsibility to a nearby node. Also,
WSNs mostly use attribute based addressing rather than relying on network
wide unique node addresses. Third, data aggregation in intermediate nodes
of the forwarding path is desirable in a WSN, but no such kind of support is
provided in traditional distributed system middleware because of the end-to-
end paradigm used. Finally, WSN requires the middleware to be light weight
for implementation in sensor nodes with limited processing and energy
resources. WSNs also have new requirements on hardware (e.g., various
sensors and computing nodes), operating systems and routing protocols, as
well as the applications.
10.6 CHALLENGES AND CONSTRAINTS

While sensor networks share many similarities with other distributed
systems, they are subject to a variety of unique challenges and constraints.
These constraints impact the design of a WSN, leading to protocols and
algorithms that differ from their counterparts in other distributed systems.
This section describes the most crucial limitations associated with WSN.
10.6.1 Battery—powered sensor nodes

Sensor nodes are usually powered by battery. In most situations, they are
deployed in a harsh or hostile environment, where it is very difficult or even

impossible to change or recharge the batteries. The main source of power
consumption is communication when compared to computation and sensing
(Hill et al., 2000). The energy cost of transmitting a bit of data over RF
channel is equivalent to executing thousands of instructions by the processor
on the node. Reading and writing to flash storage also consumes significant
amount of energy. Hence, run time environment should also consider the
flash energy consumption overhead while loading and unloading of modules
into program memory. It is the responsibility of the operating system to
provide necessary mechanisms to consume the power in optimized way to
prolong the life of the WSN. Periodic snoozing of sensor nodes is one of the
techniques to conserve power. Sensor nodes operate in three sleep modes,
idle, power down and power save, to conserve the energy. In idle mode the
processor alone shuts off, power down mode shuts off everything except the
watch dog timer and interrupt logic necessary to wake up the node, power
save mode is similar to power down mode except that it keeps the timer
running.
10.6.2 Storage constraints

Sensor nodes are highly limited in energy, computation, and storage
capacities. In sensor networks, secondary storage takes the form of on-board
flash ROM or secure digital cards. Storage systems for flash-based storage
must deal with the physical storage semantics of flash memory. In flash
memory, unlike RAM memory and magnetic disks, bits cannot be freely
written: individual bits can only be flipped from 1 to 0. To reset bits from
0 to 1, an entire sector of bits must be erased. A sector typically contains
many kilobytes of data. The storage system must be able to efficiently map
data onto the sectors to make writing and erasing efficient. To make matters
worse, individual sectors have a fixed number of erase cycles before they
wear out. The storage system therefore must perform wearleveling to spread
the erasure load evenly across the memory to avoid wearing the memory
out. The traditional approach secondary storage overlays a file system over
the storage. With the file system, named files can be created, written to, read
from and deleted. The file system approach is general enough to underpin
many mechanisms running on top of a file system and the approach has
therefore been widely used. Other approaches to storage have also been
proposed. Amnesiac storage is a technique in which sensor data stored in
secondary storage are compressed over time (Nath, 2009). Recent data are
compressed with low loss and, as data get older, the compression ratio is
increased at the cost of loss of detail. The intuition behind the system is that,
as data get older, the importance of detail decreases. Another model is the
sensor-as-database model, which turns the on-board storage into a database,
from which records can be retrieved with SQL-like queries.
10.6.3 Sensor Network Node Hardware

A sensor node consists of sensors and actuators, which interact with the
physical world around the sensor node; a microcontroller, which interacts
with the components and executes the software; a communication device,
which typically is a radio; and a power source, which often is a battery
but which also can be an energy-scavenging device such as a solar cell.
Furthermore, the sensor node may also contain secondary storage, such
as on-board flash memory. Unlike all-purpose computers, sensor network
nodes do not have support for memory hierarchies, multiple protection
domains or multi-level caches.
10.6.4 Deployment
Node deployment is a fundamental issue to be solved in Wireless Sensor
Networks. A proper node deployment scheme can lessen the complexity of
difficulties. Deploying and managing a high number of nodes in a relatively
bounded environment requires exceptional techniques. Hundreds to several
thousands of sensors may be deployed in a sensor region. They are deployed
within tens of feet of each other. The node densities may be as high as 20
nodes/m3. Deploying high number of nodes densely requires careful handling
of topology maintenance. There are two deployment models at present and
these are static- and dynamic deployment. The static deployment chooses
the best location according to the optimization strategy, and the location of
the sensor nodes has no change in the lifetime of the WSN. The dynamic
deployment throws the nodes randomly for optimization.
10.6.5 Production cost

As the sensor networks consist of a large number of sensor nodes, the cost
of a single node is very important to substantiate the overall cost of the
networks. If the cost of the network is more expensive than deploying
traditional sensors, then the sensor network is not justified in terms of cost.
As a result, the cost of each sensor node has to be kept low. The state-of-the-
art technology allows a Bluetooth radio system to be less than 10 $. Also, the
price of a PicoNode is targeted to be less than 1 $. The cost of a sensor node
should be much less than 1 $ in order for the sensor network to be feasible.
The cost of a Bluetooth radio, which is known to be a low-cost device, is
even 10 times more expensive than the targeted price for a sensor node.
10.7 APPLICATIONS OF WIRELESS SENSOR NET-

WORKS
Traditionally, sensor networks have been used in the framework of high-end
applications such as radiation and nuclear-threat detection systems, ‘‘over-
the-horizon’’ weapon sensors for ships, biomedical applications, habitat
sensing, and seismic monitoring. More recently, interest has focusing on
networked biological and chemical sensors for national security applications;
furthermore, evolving interest extends to direct consumer applications.Some
applications of WSNs are discussed below.
10.7.1 Agricultural monitoring

Precision agriculture is of the most promising application domains where
Wireless Sensor Networks can offer a feasible or even optimal solution to
monitor moisture, humidity, temperature etc. In precision agriculture, more
number of the parameters is to be controlled. They are accumulating every day
because of the development in agriculture technology. In this situation, the
Wireless Sensor Network with added hardware and software is an effective
solution. Another important area of benefit is forestry management. Forests
are important sources for biodiversity and ecological balance. They provide
many benefits and it is the main functions for water and soil conservation,
genetic resources for plant and animal, and also source of wood supply
and other forest goods. However, recently the green forest environment
has been disturbed by non-ethical activities such as unlawful logging and
also country development activities that diminish the benefits of the forest
contribution. Thus, to ensure long term forest autonomy, it is important to
implement a monitoring system that can take charge of monitoring the forest
environment effectively.
10.7.2 Industrial monitoring

Wireless Sensor Network technology has proven to be invaluable especially
in the industrial sector, specifically in monitoring data such as pressure,
humidity, temperature, flow, level, viscosity, density and vibration.
Measurements can be recorded by the sensing units and transferred
wirelessly to a main system for operation and management. Adopting WSNs

for process monitoring provides great benefits over traditional wired system.
10.7.3 Military application

As the WSNs can be installed rapidly and are self-controlled therefore they
are very beneficial in military operations for sensing and observing friendly
or hostile motions. The battlefield surveillance can be done through the
sensor nodes to keep a check on everything in case more equipment, forces
or ammunitions are required in the battlefield. The chemical, nuclear and
biological attacks can also be detected through the sensor nodes.
10.7.4 Healthcare sector

The incorporated monitoring of a patient can be carried out by using WSNs.
The internal processes and movements of animals can be monitored.
Diagnostics can be done. They also help in examining drug administration
in hospitals and in monitoring patients as well as doctors. An example of this
is ‘artificial retina’ which aids the patient in sensing the presence of light and
the movement of objects. They can also trace objects and count individual
items.
REFERENCES
1. Akyildiz, I., Su, W., Sankarasubramaniam, Y, &Cayirci, E. (2002).
Wireless sensor networks: A survey. Computer Networks,38,393-422.
2. Chiara, B., Andrea, C.,Davide, D.,&Roberto, V. (2009). An overview
on wireless sensor networks technology and evolution. Sensors,9,
6869-6896.
3. Dunkels, A., Schmidt, O., Voigt, T., & Ali, M. (2006, October 31–
November 2).Protothreads: Simplifying event-driven programming
of memory-constrained embedded systems.Proceedings of the
International Conference on Embedded Networked Sensor Systems
(ACM SenSys). Boulder, CO: ACM.
4. Nath, S. (2009).Energy efficient sensor data logging with amnesic flash
storage.Proceedings of the International Conference on Information
Processing in Sensor Networks (ACM/IEEE IPSN)April 13-16, 2009.
San Francisco, CA: IEEE Computer Society.
5. Sohraby, K.,Minoli, D.,& Znati, T. (2007).Wireless sensor
networks: technology, protocols, and applications.USA: John
Wiley & Sons.Retrieved January 30, 2018, from http://dx.doi.
org/10.1002/047011276X
6. Wilson, J. (2005). Sensor technology handbook.Burlington, MA, USA:
Elsevier/Newnes.
BIBLIOGRAPHY
1. Agrawal, D.&Abbadi, A.An efficient solution to the distributed mutual

exclusion problem.Proceedings of (PODC’89) ACM Symposiumon
Principlesof Distributed Computing.
2. Baldauf, M.,Dustdar, S.,&Rosenberg, F. (2007). A survey on context-
aware systems. International Journal of Ad Hoc and Ubiquitous
Computing,2,263-277.
3. Ben-Ari M. (2006). Principles of concurrent and distributed
programming (2nded.). Englewood Cliffs:Prentice Hall.
4. Bernabeu-Auban, J. M., &Mustaque, A.( 1989 September).Applying
a path-compression technique to obtain an effective distributed mutual
exclusion algorithm.Proceedings of 3rd International Workshop on
Distributed Algorithms.
5. Berners-Lee T. (2000). Weaving the web, 23 Harper Collins.Retrieved
fromhttp://www-sld.slac.stanford.edu/sldwww/beamline/spinweb.pdf
6. Bernstein P (1996). Middleware: a model for distributed system
services. Communications of the ACM,39(2), 87-98.
7. Bernstein, P., &Newcomer, E. (2009). Principles of transaction
processing (2nd ed.). San Mateo:Morgan Kaufman.
8. Bernstein, P.,Hadzilacos, V.,&Goodman, N. (1986).Distributed

recovery.In Concurrency control and recovery in database systems.
Addison-Wesley. Available at: http://research.microsoft.com/en-us/
people/philbe/chapter7.pdf
9. Bertino, E.,&Crampton, J. (2008).Information assurance:Dependability
and security in networked systems(pp. 39-79).
10. Blair, G., &Stefani, J.B. (1998).Open distributed processing and
multimedia. Addison-Wesley.
11. Bonnet, P.,Gehrke, J.,&Seshadri, P. (2002). Towards sensor database
systems. InProccedings of Second International Conference Mobile
Data Management.Berlin: Springer (Lecture notes in computer science,
Vol.1987, pp. 3–14).
12. Buckley, G., &Silberschatz, A. (May 1984).A failure tolerant centralized
mutual exclusion algorithm.Proceedings of the 4th International
Conference on Distributed Computing Systems.
13. Cao, G.,&Singhal, M. (December 2001)A delay-optimal quorum-based
mutual exclusion algorithm for distributed systems.IEEE Transactions
on Parallel and Distributed Systems,12(12), 1256-1268.
14. Chakrabarti, S.,& Mishra, A. (2001). QoS issues in ad hoc wireless
networks. IEEE Communications Magazine,39(2), 142-148.
15. Carvalho, O. S. F., & Roucairol, G.( 1983 February).On mutual
exclusion in real-time distributed computing systems, technical
correspondence.Communications of the ACM.
16. Chang, Y., Singhal, M., & Liu, M. A. (1991 March).Dynamic token-
based distributed mutual exclusion algorithm.In Proceedings of
the 10th IEEE International Phoenix Conference on Computer and
Communications (pp. 240-246).
17. Dew, P. (2003).Virtual working environment, lecture slides 3,
Introduction to distributed computing and information sharing.
18. Easley, D., & Kleinberg, J. (2010).Networks, crowds, and markets:
reasoning about a highly connected world. Cambridge:Cambridge
University Press.
19. Frodigh, M., Jhansson, P., & Larsson, P. (2000). Wireless ad hoc
networking: The art of networking without a network. Ericsson
Review,4, 248-263.
20. Frodigh, M., Parkvall, S., Roobol, C., Johansson, P., & Larsson, P.
(2001 October).Future-generation wireless networks.IEEE Personal
Bibliography 233
Communications,8(5), 10-17.
21. Garcia-Molina, H., & Barbara, D. (1985).How to assign votes in a
distributed system.Journal of the ACM.
22. Gaddah, A., & Kuns, T. (2003 July).A survey of middleware paradigms
for mobile computing.Systems and Computer Engineering,Carleton
University, (Technical Report SCE-03-16).
23. Goscinski, A. (1990).Two algorithms for mutual exclusion in real-time
distributed computing systems.Journal of Parallel and Distributed
Computing,9.
24. Gulli, A., & Signorini, A. (2005).The indexable Web is more than 11.5
billion pages.Proceedings of the 14th International Conference on
WWW (Chiba, Japan),(pp. 902-903). [An estimate of the Web size at
that time].
25. Helary, M., Plouzeau, N., & Raynal, M. (1988).A distributed
algorithm for mutual exclusion in an arbitrary network.The Computer
Journal,31(4), 289-295.
26. Kumar, P., & Selvakumar, S.( 2011, July 15).Distributed denial
of service attack detection using an ensemble of neural classifier.
Computer Communications,34(11), 1328-1341.
27. Liu, H., Luo, P.,& Wang, D. (2008 November ). A scalable
authentication model based on public keys.Journal of Network and
Computer Applications,31(4), 375-386.
28. Lorch, J., & Smith, A. J. R. (1998). Software strategies for portable
computer energy management. IEEE Personal Communications,60-73.
29. Malacaria, P., & Smeraldi, F.( 2013 May). Thermodynamic aspects
of confidentiality.Information and Computation Special Issue:
Information Security as a Resource,226, 76-93.
30. Peterson, I., & Silberschatz, A. (1985) Operating Systems Concepts.
Addison–Wesley Publishing Co.
31. Smart Card Alliance. (2003).Using smart cards for secure physical
access.Princeton Junction: Smart Card Alliance. Retrieved from http://
www.smartcardalliance.org/resources/lib/Physical_Access_Report.
pdf
32. Prakasha, V.,&Darbarib, M. (2013). A new proposal for distributed
system security framework. AASRI Procedia2013 AASRI Conference
on Parallel and Distribute Computing and Systems (pp. 183-188).
33. Reza, S. (2015).Security techniques in distributed systems.Computer

Science and Information Technology,3(2), 49-53.
34. Shenbagavadivu, N., &Savithri, S. U. (2012).Enhanced information
security in distributed mobile system based on delegate object model.
International Conference on Communication Technology and System
Design 2011. Procedia Engineering,30, 774-781.
35. Sherman, R. (1992).Distributed systems security.Computer &
Security,11, 24-28.
36. Nagananda, K. G.(June 2013). Secure communications over
opportunistic-relay channels.Physical Communication,7, 105-121.
37. Newcombe, C., Rath, T., Zhang, F., Munteanu, B., Brooker, M., &
Deardeuff, M.(2015). How Amazon web services uses formal methods.
Communications of the ACM,58(4), 66-73; Retrieved from http://cacm.
acm.org/magazines/2015/4/184701-howamazon-web-services-uses-
formal-methods/fulltext
38. UMUC. (2011). Prevention and protection strategies in cybersecurity.
Adelphi, MD, USA.
39. Veríssimo, P., & Rodrigues, L. (2012).Distributed systems for
architectsSystem.US: Springer.
40. Wang, F., & Zhang, Y. (June 25, 2008). A new provably secure
authentication and key agreement mechanism for SIP using certificateless
public-key cryptography.Computer Communications,31(10), 2142-
2149.
41. Yang, J.,Chen, T., Wu, M., Xu, Z., Liu, X.,Lin, H., Yang, M., Long,
F., Zhang, L. &Zhou, L. (2009). MoDist: transparent model checking
of unmodified distributed systems. Proceedings of the Sixth Usenix
Symposium on Networked Systems Design and Implementation(pp
213-228).Retrieved from https://www.usenix.org/legacy/event/nsdi09/
tech/full_papers/yang/yang_html/
42. Zeltzer, L. (2005).Auditing UNIX systems: A case study.Retrieved
fromhttp://zeltser.com/auditing-unix-systems/#prioritizing
INDEX
A Computer networking 85
Concurrent programming language
Advanced Encryption Standard
189
(AES) 155
Cyclic redundancy check (CRC) 39
Analog-to-digital converter (ADC)
209 D
Asynchronous Transfer Mode
Data Encryption Standard (DES)
(ATM) 85
155
B Data processing system 101
Decentralized object location and
Body area networks (BANs) 172
routing (DOLR) 131
C Digital Signature Algorithm (DSA)
150, 151
Client-server communication 44
Distributed file systems (DFS) 108
Commercial-off-the-shelf (COTS)
Distributed hash table (DHT) 132
96
Distributed object middleware
Common Object Request Broker
(DOM) 32
Architecture (CORBA) 198
Distributed operating system 141
Communication channel 217
Distributed Programming Environ-
Communications topology 215
ment (DPE) 188
Computer communication 45
Distributed system 26, 27, 28, 29, I

44, 45, 76, 82, 87, 90
Information technology (IT) 168
Domain name Addressing 21
Interface definition languages (IDL)
Dynamic Invocation Interface (DII)
44
200
Interface Repository (IR) 200
Dynamic membership 87
Internet Message Access Protocol
Dynamic skeleton interface (DSI)
(IMAP) 7
200
Internet Protocol (IP) 164
E Internet Relay Chat (IRC) 11
Internet service provider (ISP) 13
Election protocol 91, 92
Inter-process communication (IPC)
F 106
File Allocation Table (FAT) 107 J
File Transfer Protocol (FTP) 2
Java Virtual Machine (JVM) 196
First-in, First-Out (FIFO) 78
Forwards the actual protocol (FTP) L
8
Local area network (LAN) 6
Frequency division/multiple access
Logical Link Control (LLC) 36
(FDMA) 172
Low earth orbit satellites (LEOS)
Function control block (FCB) 220
174
G
M
Global Positioning System (GPS)
Maximum transmission unit (MTU)
214
34
Graphical user interfaces (GUI) 97
Media Access Control (MAC) 38
Group communication 85, 86
Medium access control (MAC) 217
H Message authentication code
(MAC) 140
Hardware elements 28
Message-oriented middleware
Hardware resources 96
(MOM) 32
Hypertext Markup Language
Messaging Application Program-
(HTML) 19
ming Interface (MAPI) 7
Hypertext Transfer Protocol
Metropolitan area network (MAN)
(HTTP) 22
15
Index 237
Mobile Ad Hoc Network (MANET) R

169
Radio communication 171
Mutual exclusion algorithm 76, 77,
79, 80, 82 S
N Secure Sockets Layer (SSL) 145
Security mechanism 138, 139
National Science Foundation (NSF)
Semantic Routing 118
3
Sensor network 208, 209, 213, 214,
Network File System (NFS) 109
215, 218, 224, 225, 226, 227,
Network operating system (NOS)
229
102
Sensor Operating system (SOS)
Network Operating Systems (NOS)
219
103
Service-oriented middleware
Network terminal protocol 11
(SOM) 45
O Signal-to-noise ratio (SNR) 171
Simple Mail Transfer Protocol
Object adapter (OA) 201
(SMTP) 5
Object Management Group (OMG)
Simple Object Access
198
Protocol(SOAP) 17
Object-oriented programming
Synchronous communication 192
(OOP) 195
Object Request Broker (ORB) 199 T
Occam programming language 188
Thread control block (TCB) 111
Open System Interconnection (OSI)
Time-to-live (TTL) 127
15
Transmission Control Protocol
P (TCP) 11
Transport Control Protocol (TCP)
Peer-to-peer (P2P) 116
47
Personal digital assistant (PDA)
Transport layer control 41
168
Point-to-multipoint virtual circuits U
(P2MP) 85
Uniform Resource Identifier (URI)
Pretty Good Privacy (PGP) 153
22
Process control block (PCB) 110
User Datagram Protocol (UDP) 47
W Wireless sensor and actuator net-

work (WSAN) 209
Wireless communication technol-
Wireless sensor networks (WSN)
ogy 164
208

Internet and Distributed Systems PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet and Distributed Systems PDF

Uploaded by

Copyright:

Available Formats

INTERNET & DISTRIBUTED

e-book Edition 2019

ISBN: 978-1-77361-587-5 (e-book)

© 2019 Arcler Press

ISBN: 978-1-77361-390-1 (Hardcover)

Jocelyn O. Padallan is currently pursuing her Master of Science in

Chapter 1 Introduction to Internet............................................................................. 1

Chapter 2 Fundamental Concepts of Distributed Systems........................................ 25

Chapter 3 Time and Global States............................................................................ 53

Chapter 5 Distribution and Operating Systems......................................................... 95

Chapter 6 Peer To Peer Systems............................................................................. 115

Chapter 8 Mobile and Ubiquitous Computing........................................................ 163

Chapter 9 Distributed Programming Systems and Environment.............................. 187

Chapter 10 Wireless Sensor Network....................................................................... 207

Figure 1.1: An illustration of the Internet

Table 1.7: Generic Domains

The US Department of Defense established the basis of the Internet by

1.1 HISTORY OF THE INTERNET

Figure 1.1: An illustration of the Internet. Source: https://www.businessday-

1.1.1 World Wide Web

1.1.3 E-Mail Server

regularly deleted from the server. POP supports simple download-

Figure 1.2: Free enterprise e-mail server. Source: https://www.citynethost.com/

1.1.4 File Transfer Protocol

Figure 1.3: Modes of operation of types of FTP. Source: http://searchenter-

Typically, telnet offers access to a command-line interface on a remote host

1.1.6 Internet Relay Chat

1.2 LOCAL AREA NETWORK

Figure 1.4: Local area network. Source: https://www.tutorialspoint.com/com-

1.3 WIDE AREA NETWORK

those using satellites) have store-and-forward subnets. When the packets

1.4 WIRELESS LOCAL AREA NETWORK

a network connection to all users in a building or campus. The backbone

1.5 METROPOLITAN AREA NETWORK

1.6 CONNECTING TO THE INTERNET

1.6.1 Connecting to the Internet with a modem

Figure 1.5: A modem. Source: https://www.computerhope.com/issues/

1.6.2 Broadband Connection

1.6.3 Smartphone Connection

1.6.4 Leased Connection

1.7 WEB SERVICES

Figure 1.6: Overview of Web services. Source: https://www.javatpoint.com/

1.7.1 Searching the World Wide Web

the system structure of a typical search engine. Search engines traditionally

1.7.2 Hypertext Markup Language

style=’mso-fareast-font-family: “Times New Roman”’>As important as

Figure 1.7: Coding a Website in Notepad. Source: https://www.howcast.com/

use port 17. Outgoing information is channeled through a different or

1.7.4 Domain name Addressing

Table 1.7: Generic Domains

Aero Airlines and aerospace companies

Biz Businesses or firms

Com Commercial organizations

Coop Cooperative business organizations

Edu Educational institutions

Gov Government institutions

Info Information service providers

Int International organizations

Mil Military groups

Museum Museums and other nonprofit organiza-

Net Network support centers

Org Nonprofit organizations

Pro Professional individual organizations