The document discusses the history and concepts of distributed systems. It defines a distributed system as a collection of independent computers that appears as a single system to users. Distributed systems provide benefits like resource sharing, availability, scalability, and performance. However, they also introduce challenges around concurrency, security, partial failures, and heterogeneity. The document outlines common goals for distributed systems like transparency, openness, and scalability. It describes different approaches to scaling distributed systems through techniques like hiding latencies, distribution, and replication. Finally, it discusses key hardware concepts like multiprocessors and multicomputers as well as software approaches like distributed operating systems, network operating systems, and middleware.
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT JaipurDrNilam Choudhary
Distributed System is a collection of autonomous computer systems that are physically separated but are connected by a centralized computer network that is equipped with distributed system software. The autonomous computers will communicate among each system by sharing resources and files and performing the tasks assigned to them.
Introduction to distributed systems
Architecture for Distributed System, Goals of Distributed system, Hardware and Software
concepts, Distributed Computing Model, Advantages & Disadvantage distributed system, Issues
in designing Distributed System,
Distributed System Unit 1 Notes by Dr. Nilam Choudhary, SKIT JaipurDrNilam Choudhary
Distributed System is a collection of autonomous computer systems that are physically separated but are connected by a centralized computer network that is equipped with distributed system software. The autonomous computers will communicate among each system by sharing resources and files and performing the tasks assigned to them.
Introduction to distributed systems
Architecture for Distributed System, Goals of Distributed system, Hardware and Software
concepts, Distributed Computing Model, Advantages & Disadvantage distributed system, Issues
in designing Distributed System,
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
2. 2
1.1 Introduction and Definition
before the mid-80s, computers were
Very expensive (hundred of thousands or even millions
of dollars)
Very slow
Not connected among themselves
after the mid-80s: two major developments
cheap and powerful microprocessor-based computers
appeared
computer networks
LANs at speeds ranging from 10 to 1000 Mbps
WANs at speed ranging from 64 Kbps to gigabits/sec
3. 3
Definition of a Distributed System
a distributed system is:
a collection of independent computers that appears to its
users as a single coherent system - computer (Tanenbaum
& Van Steen)
this definition has two aspects:
1. hardware: autonomous(independent) machines
2. software: a single system view for the users
4. 4
Why Distributed?
Resource and Data Sharing
printers, databases, multimedia servers, ...
Availability, Reliability
the loss of some instances can be hidden
Scalability, Extensibility
the system grows with demand (e.g., extra servers)
Performance
huge power (CPU, memory, ...) available
Inherent distribution, communication
organizational distribution, e-mail, video
5. 5
Problems of Distribution
Concurrency, Security
clients must not disturb each other
Privacy
e.g., when building a preference profile
unwanted communication such as spam
Partial failure
we often do not know where the error is (e.g., RPC)
Location, Migration, Replication
clients must be able to find their servers
Heterogeneity
hardware, platforms, languages, management
6. 6
1.2 Organization and Goals of a Distributed System
to support heterogeneous computers and networks and
to provide a single-system view, a distributed system is
often organized by means of a layer of software called
middleware that extends over multiple machines
a distributed system organized as middleware; note that the middleware
layer extends over multiple machines
7. 7
Goals of a distributed system: a distributed system should
easily connect users with resources (printers, computers,
storage facilities, data, files, Web pages, ...)
reasons: economics, to collaborate and exchange
information
be transparent: hide the fact that the resources and
processes are distributed across multiple computers
be open
be scalable
Transparency in a Distributed System
a distributed system that is able to present itself to users
and applications as if it were only a single computer
system is said to be transparent
8. 8
different forms of transparency in a distributed system
Transparency Description
Access Hide differences in data representation
(file naming, ...) and how a resource
is accessed
Location Hide where a resource is physically located; where
is http://www.google.com? (naming)
Migration Hide that a resource may move to another location
Relocation Hide that a resource may be moved to another
location while in use; e.g., mobile users using their
wireless laptops
Replication Hide that a resource is replicated
Concurrency Hide that a resource may be shared by several
competitive users; a resource must be left in a
consistent state
Failure Hide the failure and recovery of a resource
Persistence Hide whether a (software) resource is in memory
or on disk
9. 9
Openness in a Distributed System
A distributed system should be open
we need well-defined interfaces
Interoperability
components of different origin can communicate
Portability
components work on different platforms
Another goal of an open distributed system is that it
should be flexible and extensible;
easy to configure the system out of different components;
easy to add new components,
easy to replace existing ones
an Open Distributed System is a system that offers
services according to standard rules that describe the
syntax and semantics of those services; e.g., protocols in
networks
10. 10
Scalability in Distributed Systems
a distributed system should be scalable
Size: adding more users and resources to the system
Geographically: users and resources may be far apart
Administratively: should be easy to manage even if it
spans many administrative organizations
11. 11
Concept Example
Centralized services
Single server for all users-mostly for security
reasons
Centralized data A single on-line telephone book
Centralized algorithms Doing routing based on complete information
examples of scalability limitations
Scalability problems: performance problems caused by
limited capacity of servers and networks
Scaling Techniques
how to solve scaling problems
For geographical scalability: the problem is mainly
performance, due to the limitations in the capacity of
servers and networks
three possible solutions: hiding communication latencies,
distribution, and replication
12. 12
a. Hide Communication Latencies
Try to avoid waiting for responses to remote service
requests
let the requester do other useful job
i.e., construct requesting applications that use only
asynchronous communication instead of synchronous
communication; when a reply arrives the application is
interrupted
Good for batch processing and parallel applications but
not for interactive applications
for interactive applications, move part of the job to the
client to reduce communication; e.g. filling a form and
checking the entries
13. 13
(a) a server checking the correctness of field entries
(b) a client doing the job
14. 14
b. Distribution
e.g., DNS - Domain Name System
divide the name space into zones
for details, see later in Chapter 4 - Naming
an example of dividing the DNS name space into zones
15. 15
c. Replication
Replicate components across a distributed system to
increase availability and for load balancing, leading to
better performance
decided by the owner of a resource
caching (a special form of replication) also reduces
communication latency; decided by the user
but, caching and replication may lead to consistency
problems (see Chapter 6 - Consistency and Replication)
16. 16
1.3 Hardware and Software Concepts
Hardware Concepts
different classification schemes exist
multiprocessors - with shared memory
multicomputers - that do not share memory
can be homogeneous or heterogeneous
18. 18
a bus-based multiprocessor
Multiprocessors - Shared Memory
the shared memory has to be coherent –
the same value written by one processor must be read by another
processor
Performance problem for bus-based organization since the
bus will be overloaded as the number of processors
increases
The solution is to add a high-speed cache memory
between the processors and the bus to hold the most
recently accessed words; may result in incoherent memory
Bus-based multiprocessors are difficult to scale even with
caches
Two possible solutions: crossbar switch and omega
network
19. 19
Crossbar switch
divide memory into modules and connect them to the
processors with a crossbar switch
at every intersection, a crosspoint switch is opened and
closed to establish connection
problem: expensive; with n CPUs and n memories, n2
switches are required
20. 20
Omega network
use switches with multiple input and output lines
drawback: high latency because of several switching
stages between the CPU and memory
21. 21
Homogeneous Multicomputer Systems
also referred to as System Area Networks (SANs)
the nodes are mounted on a big rack and connected
through a high-performance network
could be bus-based or switch-based
bus-based
shared multiaccess network such as Fast Ethernet can be
used and messages are broadcasted
Performance drops highly with more than 25-100 nodes
(contention)
23. 23
Heterogeneous Multi-Computer Systems (HMCS)
most distributed systems are built on heterogeneous
multicomputer systems
the computers could be different in processor type,
memory size, architecture, power, operating system, etc.
and
I/O bandwidth and the interconnection network may be
highly are different
the distributed system provides a software layer to hide
the heterogeneity at the hardware level; i.e., provides
transparency
25. 25
Operating systems for distributed computers can be
roughly divided into two categories:
Tightly-coupled systems:
The OS tries to maintain a single, global view of the resources
Generally, referred to as distributed OSs (DOS)
Used for multiprocessors and homogeneous multi-computers
Each component dependent on the others
Manages all the resources in a distributed system,
Provides transparency (location, migration, concurrency,
replication)
Loosely-coupled systems, referred to as network OSs
(NOS)
In which, there are a collection of computers each running their
own operating system;
However, these OS work together to make their services and
resources available to others
Used for heterogeneous multi-computers
Software Concepts…….
26. Middleware:
To enhance the services of network operating
system (NOS)
To provide distribution transparency
To actually come to a distributed system
26
Software Concepts……
27. 27
System Description Main Goal
DOS
Tightly-coupled operating system for multi-
processors and homogeneous
multicomputers
Hide and manage
hardware
resources
NOS
Loosely-coupled operating system for
heterogeneous multicomputers (LAN and
WAN)
Offer local
services to remote
clients
Middleware
Additional layer atop of NOS implementing
general-purpose services
Provide
distribution
transparency
Summary of main issues
an overview of DOSs, NOSs, and middleware
28. 28
Distributed Operating Systems
Two types of Distributed systems
Multiprocessor operating system:
Manages the resources of a multiprocessor
Multicomputer operating system:
An operating system that is developed for
homogeneous multi-computers
29. 29
Uniprocessor Operating Systems:
One large kernel that handles everything (e.g., MS-
DOS, early UNIX).
Microkernel architecture: The OS kernel is
decomposed into micro kernels,
Separating applications from operating system code
through a microkernel
30. 30
More on Multiprocessor Operating Systems
Extended from uniprocessor operating systems to support
multiple processors having access to a shared memory
Problem: Consistency
Solution: using a protection mechanism (or two
synchronization mechanisms): semaphores and monitors
Semaphore: an integer with two atomic operations down
and up
Monitor: a programming language construct consisting
of procedures and variables that can be accessed only
by the procedures of the monitor;
only a single process at a time is allowed to execute
a procedure
31. 31
Multicomputer Operating Systems
general structure of a multicomputer operating system
Processors can not share memory; instead communication
is through message passing
Each node has its own
kernel for managing local resources
separate module for handling interprocessor
communication
32. 32
Distributed Shared Memory Systems
how to emulate shared memories on distributed systems to
provide a virtual shared memory
page-based distributed shared memory (DSM) - use the
virtual memory capabilities of each individual node
pages of address space distributed among four machines
33. 33
situation if page 10 is read only and replication is used
situation after CPU 1 references page 10
read-only pages can be easily replicated
34. 34
Network Operating Systems
possibly heterogeneous underlying hardware
constructed from a collection of uniprocessor systems, each
with its own operating system and connected to each other
in a computer network
general structure of a network operating system
35. 35
Services offered by network operating systems
remote login (rlogin)
remote file copy (rcp)
shared file systems through file servers
two clients and a server in a network operating system
36. 36
Middleware
A distributed operating system is not intended to handle a
collection of independent computers but provides
transparency and ease of use
A network operating system does not provide a view of a
single coherent system but is scalable and open
Combine the scalability and openness of network operating
systems and the transparency and ease of use of distributed
operating systems
this is achieved through a middleware, another layer of
software
38. 38
Item
Distributed OS Network
OS
Middleware
-based OS
Multiproc Multicomp
Degree of
transparency
Very High High Low High
Same OS on all nodes Yes Yes No No
Number of copies of
OS
1 N N N
Basis for
communication
Shared
memory
Messages Files
Model
specific
Resource management
Global,
central
Global,
distributed
Per node Per node
Scalability No Moderately Yes Varies
Openness Closed Closed Open Open
a comparison between multiprocessor operating systems,
multicomputer operating systems, network operating
systems, and middleware-based distributed systems
39. Networks
Started in 1070s
Ethernet and LAN were evented
The internet continue to be the biggest examples of distributed
systems.
Distributed systems have evolved from “LAN” based to
“Internet” based.
Telecommunication networks
Real-time systems
Flight control systems
Uber and Ride
Manufacturing automation control systems
Parallel Processing
Distributed artificial intelligence
Distributed Database Systems 39
Examples of Distributed Systems