The document discusses synchronization in distributed systems. It covers clock synchronization algorithms to ensure processes agree on time ordering of events. Logical clocks like Lamport timestamps are used when exact time is not needed, only causal ordering. Distributed mutual exclusion algorithms are discussed to allow only one process access to shared resources at a time, including token-based and permission-based approaches. The latter includes both a centralized and distributed algorithm.
This ppt covers different aspects about timing issues and various algorithms involved in having better sync between different systems in a distributed environment
Synchronization in distributed computingSVijaylakshmi
Synchronization in distributed systems is achieved via clocks. The physical clocks are used to adjust the time of nodes. Each node in the system can share its local time with other nodes in the system. The time is set based on UTC (Universal Time Coordination).
A distributed system is a network that consists of autonomous computers that are connected using a distribution middleware. They help in sharing different resources and capabilities to provide users with a single and integrated coherent network.
This ppt covers different aspects about timing issues and various algorithms involved in having better sync between different systems in a distributed environment
Synchronization in distributed computingSVijaylakshmi
Synchronization in distributed systems is achieved via clocks. The physical clocks are used to adjust the time of nodes. Each node in the system can share its local time with other nodes in the system. The time is set based on UTC (Universal Time Coordination).
A distributed system is a network that consists of autonomous computers that are connected using a distribution middleware. They help in sharing different resources and capabilities to provide users with a single and integrated coherent network.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
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
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
2. 2
Introduction
apart from communication, how do processes cooperate and
synchronize
cooperation is partly supported by naming; it allows
processes to at least share resources (entities)
synchronization deals on how to ensure that processes do not
simultaneously access a shared resource; how events can be
ordered such as two processes sending messages to each
other
3. 3
we discuss
the issue of synchronization based on time (actual time and
relative ordering)
distributed mutual exclusion to protect shared resources
from simultaneous access by multiple processes
how a group of processes can appoint a process as a
coordinator; can be done by means of election algorithms
Objectives of the Chapter
4. 4
6.1 Clock Synchronization
in centralized systems, time can be unambiguously decided
by a system call
e.g., process A at time t1 gets the time, say tA, and process b
at time t2, where t1 < t2, gets the time, say tB
then tA is always less than (possibly equal to but never
greater than) tB
achieving agreement on time in distributed systems is
difficult
e.g., consider the make program on a UNIX machine; it
compiles only source files for which the time of their last
update was later than the existing object file
5. 5
when each machine has its own clock, an event that occurred after
another event may nevertheless be assigned an earlier time
6. 6
Physical Clocks
is it possible to synchronize all clocks in a distributed
system?
no; even if all computers initially start at the same time,
they will get out of synch after some time due to crystals in
different computers running at different frequencies, a
phenomenon called clock skew
how is time actually measured?
earlier astronomically; based on the amount of time it
takes the earth to rotate the sun; 1 solar second =
1/86400th of a solar day (24*3600 = 86400)
it was later discovered that the period of the earth’s
rotation is not constant; the earth is slowing down due to
tidal friction and atmospheric drag; geologists believe
that 300 million years ago there were about 400 days per
year; the length of the year is not affected, only the days
have become longer
astronomical timekeeping was later replaced by counting
the transitions of the cesium 133 atom and led to what is
known as TAI - International Atomic Time
7. 7
TAI was also found to have a problem; 86,400 TAI seconds
are behind a solar day by 3 msec, as a result of the day
getting longer everyday
UTC (Universal Coordinated Time) was introduced by
having leap seconds whenever the discrepancy between
TAI and solar time grows to 800 msec
UTC replaced the astronomical GMT
in some countries, UTC is broadcasted on shortwave radio
and satellites (as a short pulse at the start of each UTC
second) for those who need precise time; but one has to
compensate for the propagation delay
Clock Synchronization Algorithms
two situations:
one machine has a receiver of UTC time, then how do we
synchronize all other machines to it
no machine has a receiver, each machine keeps track of
its own time, then how to synchronize them
many algorithms have been proposed
8. 8
a model for all algorithms
each machine has a timer that ticks H times per second or
causes an interrupt; the interrupt handler adds 1 to the clock
let the value of the clock that is obtained so be C
when the UTC time is t, the value of the clock on machine p is
Cp(t); if everything is perfect, Cp(t) = t or dC/dt = 1
but in practice there will be errors; either it ticks faster or
slower
if is a constant such that 1- dC/dt 1+ , then the timer is
said to be working within its specification
is set by the manufacturer and is called the maximum drift
rate
the relation between clock time and UTC when clocks tick at different rates
9. 9
if two clocks are drifting in the opposite direction, at a time
t after they were synchronized, they may be as much as
2t apart
if no two clocks should ever differ by more than , then
clocks must be synchronized at least every /2 seconds
how is it done?
Network Time Protocol (originally by Cristian)
suitable when one machine has a UTC receiver or a correct
clock; let us call this machine a time server
then let clients (A) contact the time server (B)
problem: message delays; how to estimate these delays
getting the current time from a time server
10. 10
assume that the propagation delays from A to B is the same
as from B to A, i.e., T2 - T1 ≈ T4 - T3
then A can estimate its offset relative to B as
problem: time must never run backward or should not be
less than 0, i.e., A’s clock is faster than B’s
solution: introduce change gradually; if a timer is set to
generate 100 interrupts per second, it means 10 msec
must be added to the time; then make it say 9 (to slow it
down, < 0) or 11 msec (to advance it gradually, > 0)
2
)
(
)
(
2
)
(
)
( 4
3
1
2
4
3
4
1
2
3
T
T
T
T
T
T
T
T
T
T
11. 11
The Berkley Algorithm
in the previous algorithm, the time server is passive; only
other machines ask it periodically
in Berkley UNIX, a time daemon asks every machine from
time to time to ask the time
it then calculates the average and sends messages to all
machines so that they will adjust their clocks accordingly
suitable when no machine has a UTC receiver
the time daemon’s time must be set periodically manually
12. 12
a) the time daemon asks all the other machines for their clock values
b) the machines answer how far ahead or behind the time daemon they are
c) the time daemon tells everyone how to adjust their clock
there are also other algorithms
read about clock synchronization in wireless networks;
pages 242 - 243
13. 13
for some applications, it is sufficient if all machines agree
on the same time, rather than with the real time; we need
internal consistency of the clocks rather than being close
to the real time
hence the concept of logical clocks
what matters is the order in which events occur
Lamport Timestamps
Lamport defined a relation called happens before
a b read as “a happens before b”; means all processes
agree that first event a occurs, then event b occurs
this relation can be observed in two situations
if a and b are events in the same process, and a occurs
before b, then a b is true
if a is the event of a message being sent by one
process, and b is the event of the message being
received by another process, then a b is also true
6.2 Logical Clocks
14. 14
happens before is a transitive relation
if a b and b c, then a c
if two events, x and y, happen in different processes that do
not exchange messages, then both x y and y x are not
true; these events are said to be concurrent; it means that
nothing can be said about the order of these events
for every event a, we can assign a time value C(a) on which
all processes agree; if a b, then C(a) < C(b)
15. 15
Lamport’s proposed algorithm for assigning times for
processes
consider three processes each running on a different
machine, each with its own clock
the solution follows the happens before relation; each
message carries the sending time; if the receiver’s clock
shows a value prior to the time the message was sent, the
receiver fast forwards its clock to be one more than the
sending time
16. 16
a) three processes, each with its own clock; the clocks run at different
rates
b) Lamport's algorithm corrects the clocks
17. 17
Implementation: Each process maintains a local
counter Ci. These counters are updated as follows:
Before executing an event Pi executes
Ci ← Ci + 1.
When process Pi sends a message m to Pj, it sets
m’s timestamp ts (m) equal to Ci after having
executed the previous step
Upon the receipt of a message m, process Pj adjusts
its own local counter as
Cj ← max{Cj , ts (m)}, after which it then executes the
first step and delivers the message to the
application
18. 18
additional requirements
between two events, the clock must tick at least once,
i.e., a process that sends or receives two messages in
succession must advance its clock by one tick
no two events must occur at exactly the same time; if so
attach the number of the process; e,g., if events happen
in processes 1 and 2 at time 40, then we have 40.1 and
40.2
with these requirements, assigning time to all events in a
distributed system is subject to the following conditions
1. if a b in the same process, then C(a) < C(b)
2. if a and b represent the sending and receiving of a
message, respectively, then C(a) < C(b)
3. for all distinctive events a and b, C(a) C(b)
19. 19
example: Totally-Ordered Multicasting
assume a bank database replicated across several cities for
performance; a query is always forwarded to the nearest copy
let us have a customer with $1000 in her account
she is in city A and wants to add $100 to her account (update
1)
a bank employee in city B initiates an update of increasing
accounts by 1 percent interest (update 2)
both must be carried out at both copies of the database
due to communication delays, if the updates are done in
different order, the database will be inconsistent (city A =
$1111, city B = $1110)
updating a replicated database and leaving it in an inconsistent state
20. 20
situations like these require a Totally-Ordered Multicast, i.e.,
all messages are delivered in the same order to each receiver
Lamport timestamps can be used to implement totally-
ordered multicasts
timestamp each message
during multicasting, send a message also to the sender
assume messages from the same sender are received in
the order they are sent and no message is lost
all messages are put in a local queue ordered by
timestamp
each receiver multicasts an acknowledgement
then all processes will have the same copy of the local
queue
a process can deliver a queued message to the application
it is running only when that message is at the top of the
queue and has been acknowledged by each other process
21. 21
Vector Clocks
with Lamport timestamps a b does not necessarily
mean a happens before b; only that all processes agree;
but they ensure total ordering
it also doesn’t tell us causality of events
vector timestamps are designed for this purpose
read pages 248-252
22. 22
when a process has to read or update shared data (quite
often to use a shared resource such as a printer, a file, etc.), it
first enters a critical region to achieve mutual exclusion
in single processor systems, critical regions are protected
using semaphores, monitors, and similar constructs
how are critical regions and mutual exclusion implemented in
distributed systems?
distributed mutual exclusion algorithms can be classified into
two:
a. Token-based solutions
a token is passed between processes; if a process
wants to transmit, it waits for the token, transmits its
message and releases the token
assume a bus network (e.g., Ethernet); no physical
ordering of processes required but a logical ring is
constructed by software
6.3 Mutual Exclusion
23. 23
an unordered group of processes on a network
a logical ring constructed in software
24. 24
when the ring is initialized, process 0 is given a token
the token circulates around the ring
a process can enter into a critical region only when it has
access to the token
it releases it when it leaves the critical region
it should not enter into a second critical region with the
same token
mutual exclusion is guaranteed
no starvation
problems
if the token is lost, it has to be generated, but detecting
that it is lost is difficult
if a process crashes
can be modified to include acknowledging a token so
that the token can bypass a crashed process
in this case every process has to maintain the current
ring configuration
25. 25
b. Permission-based approach: based on getting permission
from other processes
two algorithms: centralized and distributed
A Centralized Algorithm
a coordinator is appointed and is in charge of granting
permissions
three messages are required: request, grant, release
a) process 1 asks the coordinator for permission to enter
a critical region (through a request message);
permission is granted (through a grant message)
b) process 2 then asks permission to enter the same
critical region; the coordinator does not reply (could
also send a no message; is implementation dependent),
but queues process 2; process 2 is blocked
c) when process 1 exits the critical region, it tells the
coordinator (through a release message), which then
replies to process 2
26. 26
the algorithm
guarantees mutual exclusion
is fair - first come first served
no starvation
easy to implement; requires only three messages:
request, grant, release
shortcoming: a failure of the coordinator crashes the
system (specially if processes block after sending a
request); it also becomes a performance bottleneck; the
solution is a decentralized algorithm (pages 254 - 255)
27. 27
A Distributed Algorithm
assume that there is a total ordering of all events in the
system, such as using Lamport timestamps
when a process wants to enter a critical region it builds a
message (containing name of the critical region, its
process number, current time) and sends it to everyone
including itself
the sending of a message is assumed to be reliable; i.e.,
every message is acknowledged
when a process receives a request message
1. if the receiver is not in a critical region and does not
want to enter it, it sends back an OK message to the
sender
2. if the receiver is already in the critical region, it does not
reply; instead it queues the request
28. 28
3. if the receiver wants to enter the critical region but has
not yet done so, it compares the timestamp of the
message it sent with the incoming one; the lowest wins;
if the incoming message is lower, it sends an OK
message; otherwise it queues the incoming message
and does not do anything
when the sender gets a reply from all processes, it may
enter into the critical region
when it finishes it sends an OK message to all processes
in its queue
is it possible that two processes can enter into the critical
region at the same time if they initiate a message at the
same time? NO
a) two processes (0 and 2) want to enter the same critical
region at the same moment
b) process 0 has the lowest timestamp, so it wins
c) when process 0 is done, it sends an OK message, so
process 2 can now enter into its critical region
29. 29
mutual exclusion is guaranteed
the total number of messages to enter a critical region is
increased to 2(n-1), where n is the number of processes
no single point of failure; unfortunately n points of failure
we also have n bottlenecks
hence, it is slower, more complicated, more expensive, and
less robust than the previous one; but shows that a
distributed algorithm is possible
30. 30
A comparison of the three algorithms (assumes only point-
to-point communication channels are used)
Algorithm
Messages per
entry/exit
Delay before entry
(in message times)
Problems
Centralized 3 - efficient 2
Coordinator
crash
Distributed 2 ( n – 1 ) 2 ( n – 1 )
Crash of any
process
Token ring 1 to 0 to n – 1
Lost token,
process crash
31. 31
there are situations where one process must act as a
coordinator, initiator, or perform some special task
assume that
each process has a unique number (say its network
address provided there is one process per machine)
every process knows the process number of every other
process, but not the state of each process (which ones are
currently running and which ones are down)
election algorithms attempt to locate the process with the
highest process number
two traditional algorithms: the Bully algorithm and the Ring
algorithm
for elections in wireless environments and large-scale
systems, read pages 267 - 270
6.4 Election Algorithms
32. 32
The Bully Algorithm (the biggest person wins)
when a process (say P4) notices that the coordinator is no
longer responding to requests, it initiates an election as
follows
1. P4 sends an ELECTION message to all processes with
higher numbers (P5, P6, P7)
if a process gets an ELECTION message from one of
its lower-numbered colleagues, it sends an OK
message to the sender and holds an election
2. if no one responds, P4 wins the election and becomes a
coordinator
3. if one of the higher-ups answers, this new process takes
over
33. 33
a) Process 4 holds an election
b) Process 5 and 6 respond, telling 4 to stop
c) Now 5 and 6 each hold an election
34. 34
d) Process 6 tells 5 to stop
e) Process 6 wins and tells everyone
the last one will send a message to all processes telling
them that it is a boss
if a process that was previously down comes back, it holds
an election
35. 35
The Ring Algorithm
based on the use of a ring
assume that processes are physically or logically ordered,
so that each process knows who its successor is
when a process notices that the coordinator is not
functioning,
it builds an ELECTION message containing its own
process number and sends it to its successor
if the successor is down, the sender goes to the next
number, or the next until a running process is found
at each step, the sender adds its own process number to
the list in the message making itself a candidate
eventually the message gets back to the originating
process; the process with the highest number is elected
as coordinator, the message type is changed to
COORDINATOR and circulated once again to announce
the coordinator and who the members of the ring are
36. 36
election algorithm using a ring
e.g., processes 2 and 5 simultaneously discover that the
previous coordinator has crashed
they build an ELECTION message and a coordinator is
chosen
although the process is done twice, there is no problem,
only a little bandwidth is consumed