[V ECTOR C LOCKS & P2P S YSTEMS ] Shrideep Pallickara Computer - - PDF document

v ector c locks p2p s ystems
SMART_READER_LITE
LIVE PREVIEW

[V ECTOR C LOCKS & P2P S YSTEMS ] Shrideep Pallickara Computer - - PDF document

CS555: Distributed Systems [Fall 2019] Dept. Of Computer Science , Colorado State University CS 555: D ISTRIBUTED S YSTEMS [V ECTOR C LOCKS & P2P S YSTEMS ] Shrideep Pallickara Computer Science Colorado State University CS555: Distributed


slide-1
SLIDE 1

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.1

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS 555: DISTRIBUTED SYSTEMS

[VECTOR CLOCKS & P2P SYSTEMS]

Shrideep Pallickara Computer Science Colorado State University

September 5, 2019

L4.1 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.2 Professor: SHRIDEEP PALLICKARA

Frequently asked questions from the previous class survey

September 5, 2019

slide-2
SLIDE 2

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.2

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.3 Professor: SHRIDEEP PALLICKARA

Topics covered in this lecture

¨ Vector Clocks ¨ Peer to Peer (P2P) Systems ¤ Characteristics ¤ Generations ¤ P2P middleware and requirements

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

VECTOR CLOCKS

September 5, 2019

L4.4

slide-3
SLIDE 3

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.3

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.5 Professor: SHRIDEEP PALLICKARA

Lamport’s Clocks order events based on the happened-before relationship

¨ If a happened before b, then C(a) < C(b) ¨ But nothing can be said about two events a and b by merely

comparing their values

¨ C(a) < C(b)? ¤ Does not mean a happened before b

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.6 Professor: SHRIDEEP PALLICKARA

Let’s look a little closer

¨ Tsnd(mi) : Time mi was sent ¨ Trcv(mi) : Time mi was received ¨ Tsnd(mi) < Trcv(mi) ¨ BUT ¤ Tsnd(mi) < Trcv(mj) ? n NO

September 5, 2019

slide-4
SLIDE 4

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.4

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.7 Professor: SHRIDEEP PALLICKARA

Concurrent message transmissions

6 12 18 24 30 36 42 48 70 76 8 16 24 32 40 48 61 69 77 85 10 20 30 40 50 60 70 80 90

100

m1 m3 m4 m5 m2

Sending m3 MAY HAVE depended on m1

Trcv(m1) < Tsnd(m2)

But sending of m2 has nothing to do with receipt of m1

Lamport clocks do not capture causality

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.8 Professor: SHRIDEEP PALLICKARA

Vector clocks

September 5, 2019

¨ Developed by Mattern [1989] and Fidge [1991] to overcome

shortcomings of Lamport’s clocks

¤ i.e. if C(a) < C(b) then we cannot conclude a à b ¨ A vector clock for a system of N processes is an array of N integers ¨ Each process keeps its own vector clock VCi ¤ Process uses it vector clock to timestamp messages

slide-5
SLIDE 5

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.5

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.9 Professor: SHRIDEEP PALLICKARA

Causality can be captured by Vector clocks

September 5, 2019

¨ Event a is known to causally precede event b iff

  • VC(a) < VC(b)

¨ Each process Pi maintains a vector VCi ¨ VCi[i] is number of events so far at Pi ¨ If VCi[j] = k ¤ Pi knows k events occurred at Pj ¤ Pi’s knowledge of local time at Pj

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.10 Professor: SHRIDEEP PALLICKARA

Causal precedence can be captured by Vector clocks

September 5, 2019

¨ Event a is known to causally precede event b iff VC(a) < VC(b) ¤ VC(a)<VC(b) iff VC(a)[k] ≤ VC(b)[k] for all k and at least one of those

relationships is strictly smaller

¨ Each process Pi maintains a vector VCi ¨ VCi[i] is number of events so far at Pi ¨ If VCi[j] = k ¤ Pi knows k events occurred at Pj ¤ Pi’s knowledge of local time at Pj

slide-6
SLIDE 6

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.6

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.11 Professor: SHRIDEEP PALLICKARA

Vectors are piggybacked along with any messages that are sent

September 5, 2019

① Before executing an event (sending, delivering, or internal) Pi

executes

¤

VCi[i] = VCi[i] + 1 ② When Pi sends a message m to Pj

¤

Set m’s timestamp ts(m) to VCi after doing (1) ③ After receiving m, process Pj adjusts its vector

¤

VCj[k] = max{VCj[k], ts(m)[k]} for each k

¤

Execute step (1) and deliver

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.12 Professor: SHRIDEEP PALLICKARA

Vector clocks example 1

A B C [1,0,0] [2,1,0] [0,0,1] [2,2,2] [2,2,0] [2,0,0]

September 5, 2019

slide-7
SLIDE 7

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.7

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.13 Professor: SHRIDEEP PALLICKARA

Vector clocks example 2

A B C [1,0,0] [1,2,0] [1,3,3] [1,3,4] [1,3,0] [1,4,0] [5,4,0] [7,4,4]

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.14 Professor: SHRIDEEP PALLICKARA

Vector timestamps allow us to determine causality and concurrency

¨ Event a happened before event b iff

  • ts(a) ≤ ts (b) for each process i
  • And one of those relationships is strictly smaller

¨ If this is not true ¤ Events a and b are concurrent

September 5, 2019

slide-8
SLIDE 8

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.8

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.15 Professor: SHRIDEEP PALLICKARA

Vector Clocks: Other aspects

September 5, 2019

¨ If event a has timestamp, ts(a): ¤ ts(a)[i]–1 n Denotes number of events at Pi that precede a ¨ When Pj receives message m from Pi with timestamp ts(m)=VCi ¤ Pj knows about number of events at Pi that causally preceded m ¤ Also, Pj knows about how many events at other processes have preceded the

sending of m, and on which m may causally depend

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.16 Professor: SHRIDEEP PALLICKARA

Vector clocks: Disadvantages

¨ Storage and message payload is proportional to N, the number of

processes

¨ It’s been shown ([Charron-Bost 1991]) that if we are to tell if two

events are concurrent by inspecting timestamps?

¤ The dimension of N is unavoidable

September 5, 2019

slide-9
SLIDE 9

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.9

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

USING VECTOR CLOCKS FOR CAUSALLY ORDERED MULTICASTING

September 5, 2019

L4.17 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.18 Professor: SHRIDEEP PALLICKARA

Contrasting totally-ordered and causally-ordered multicasting

¨ Causally-ordered multicasting is weaker than totally-ordered

multicasting

¨ If two messages are not in any way related to each other? ¤ We do not care about the order in which they are delivered to applications ¤ Could be delivered in different order at different applications

September 5, 2019

slide-10
SLIDE 10

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.10

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.19 Professor: SHRIDEEP PALLICKARA

Using Vector Clocks for causally-ordered multicasting

September 5, 2019

¨ Clocks are ONLY adjusted when sending and receiving messages ¨ Upon sending a message, process Pi will only increment VCi[i] by 1 ¨ When Pi delivers a message m with timestamp ts(m) it adjusts VCi[k] ¤ To max(VCi[k], ts(m)[k]) for each k

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.20 Professor: SHRIDEEP PALLICKARA

When process Pj receives a message m from Pi

September 5, 2019

¨ Delivery of the message m to the application layer is delayed until 2

conditions are met:

① ts(m)[i] = VCj[i] + 1

n This means m is the next message that Pj was expecting from Pi

② ts(m)[k] ≤ VCj[k] for all k ≠ i

n This means that Pj has seen all messages that have been seen by Pi when it

receives m

slide-11
SLIDE 11

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.11

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.21 Professor: SHRIDEEP PALLICKARA

An example showing enforcement of causal communications

A B C VC0 = [1,0,0] VC2 = [0,0,0] VC2=[1,0,0] VC1 = [1,1,0] VC0 = [1,1,0]

m

VC2=[1,1,0]

m*

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.22 Professor: SHRIDEEP PALLICKARA

Matrix clocks

¨ Generalizes the notion of vector clocks ¨ Processes keep estimates of other processes’ vector time [Raynal &

Singhal, 1996]

¨ Essentially, a vector of vector clocks for each of the communicating

processes

September 5, 2019

slide-12
SLIDE 12

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.12

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

PEER-TO-PEER (P2P) SYSTEMS

September 5, 2019

L4.23 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.24 Professor: SHRIDEEP PALLICKARA

P2P systems

¨ Supports the construction of distributed systems ¨ Data and computational resources are contributed by many hosts ¤ All participate in the provisioning of a uniform service

September 5, 2019

slide-13
SLIDE 13

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.13

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.25 Professor: SHRIDEEP PALLICKARA

P2P systems

September 5, 2019

¨ Ability to share computing resources, storage, and data ¤ Present in computers at the “edges of the internet” ¨ Have been used in several applications such as ¤ File sharing, web caching, information distribution ¤ 10s of thousands of machines harnessed by these applications

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.26 Professor: SHRIDEEP PALLICKARA

Goals

September 5, 2019

¨ Demand for Internet Services continues to grow ¤ Scope for expanding popular services is limited when all hosts must be

  • wned and managed by provider

¨ P2P systems aim to enable sharing of data and resources at a very

large scale

¤ They do so by eliminating requirements for separately managed servers and

their associated infrastructure

slide-14
SLIDE 14

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.14

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.27 Professor: SHRIDEEP PALLICKARA

P2P systems provide access to information resources

¨ Information located on computers throughout a network ¨ Algorithms for placement and retrieval of objects are a key aspect of

system design

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.28 Professor: SHRIDEEP PALLICKARA

Traditional client-server systems

¨ Single computer or a cluster of tightly-coupled servers ¨ Simple decisions relating to the placement of resources ¨ Scale of service is limited by: ¤ Server hardware capacity ¤ Network connectivity

September 5, 2019

slide-15
SLIDE 15

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.15

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.29 Professor: SHRIDEEP PALLICKARA

The delivered service must be

¨ Fully decentralized ¨ Self-organizing ¨ Dynamically balance storage and processing loads between all

participating computers

¤ Even as computers join and leave the service

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CHARACTERISTICS OF P2P SYSTEMS

September 5, 2019

L4.30

slide-16
SLIDE 16

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.16

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.31 Professor: SHRIDEEP PALLICKARA

P2P characteristics

September 5, 2019

¨ Each node contributes resources to the system ¨ Each node may differ in the quality of the resource that they

contribute

¤ But every node has the same functional capabilities and responsibilities ¨ Correct operation does not depend on the existence of any centrally

administered systems

¨ Can be designed to provide a limited degree of anonymity to

providers and users of resources

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.32 Professor: SHRIDEEP PALLICKARA

Key issue for the efficient operation of P2P systems

September 5, 2019

¨ Choice of algorithm for the placement of data across many hosts ¨ Subsequent access to the data in a manner that balances workload ¤ Ensure availability without adding undue overheads

slide-17
SLIDE 17

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.17

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.33 Professor: SHRIDEEP PALLICKARA

Coping with volatile resources in P2P systems

September 5, 2019

¨ Computers and network connections in P2P systems are owned by

different entities

¤ A single node can become unavailable at any time ¨ P2P systems do not rely on guaranteed access to individual resources ¨ They are designed to make probability of failure to access a copy of a

replicated object arbitrarily small

¤ Degree of resistance to tampering by malicious nodes

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.34 Professor: SHRIDEEP PALLICKARA

Realizing the potential of P2P systems

September 5, 2019

¨ Emerged when significant number of users had acquired always-on,

broadband connections

¤ Made their desktops suitable for resource sharing ¨ TIMELINES ¤ In the US, this occurred around 1999 ¤ By mid-2004, worldwide number of broadband connections exceeded 100

million

slide-18
SLIDE 18

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.18

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

P2P GENERATIONS

September 5, 2019

L4.35 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.36 Professor: SHRIDEEP PALLICKARA

P2P Generations

¨ 1st Generation ¤ Napster music exchange service ¨ 2nd Generation ¤ Offered greater scalability, anonymity, and fault tolerance n Freenet, Gnutella, and BitTorrent

September 5, 2019

slide-19
SLIDE 19

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.19

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.37 Professor: SHRIDEEP PALLICKARA

The 3rd Generation of P2P systems

September 5, 2019

¨ Emergence of middleware layers for application independent

management of distributed resources

¨ Examples ¤ Chord [Stoica et al. 2001] ¤ Pastry [Rowstron and Druschel 2001] ¤ Tapestry [Zhao et al. 2004] ¤ Khademlia [Maymounkov and Mazieres 2002]

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.38 Professor: SHRIDEEP PALLICKARA

The 3rd Generation of P2P systems

¨ Designed to place resources (data objects or files) on a set of widely

distributed computers

¨ Routes messages to these resources on behalf of clients ¨ Clients do not ¤ Make decisions about placement of resources ¤ Hold information about resource whereabouts

September 5, 2019

slide-20
SLIDE 20

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.20

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.39 Professor: SHRIDEEP PALLICKARA

Unlike 2nd generation systems, 3rd generation P2P systems

¨ Provide guarantees of delivery for requests in a bounded number of

network hops

¨ Place replicas of resources on hosts in a structured manner taking

account of their:

¤ Volatile availability ¤ Variable trust worthiness ¤ Requirements for load balancing ¤ Locality of information storage and use

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.40 Professor: SHRIDEEP PALLICKARA

3rd Generation P2P systems: Resources are identified by globally unique identifiers(GUIDs)

September 5, 2019

¨ Derived as a secure hash from some or all of the resource’s state ¨ Make a resource self-certifying ¤ Clients receiving a resource can check the validity of the hash ¤ Protects it against tampering by untrusted nodes on which it might be stored ¤ Requires that states of the resource are immutable n Change to the state will result in a different hash value

slide-21
SLIDE 21

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.21

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.41 Professor: SHRIDEEP PALLICKARA

Use of objects with changing values

¨ Is much more challenging ¨ Requires addition of trusted servers to manage sequence of versions ¤ Use this to identify the most current version

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.42 Professor: SHRIDEEP PALLICKARA

Availability

September 5, 2019

¨ Must avoid situations in which all replicas of an object are

simultaneously unavailable

¨ Use of randomly generated GUIDs assists by distributing object

replicas

¤ To randomly located nodes ¤ If the underlying network spans multiple domains? n Risk of simultaneous unavailability is reduced significantly

slide-22
SLIDE 22

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.22

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

P2P MIDDLEWARE

September 5, 2019

L4.43 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.44 Professor: SHRIDEEP PALLICKARA

P2P middleware is designed to orchestrate

September 5, 2019

¨ Automatic placement of resources (data items, objects, files, etc. ) ¨ Subsequent location (discovery) of distributed resources

slide-23
SLIDE 23

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.23

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.45 Professor: SHRIDEEP PALLICKARA

How different P2P generations cope with this issue

¨ 1st Generation ¤ Maintain a centralized index of available files ¤ Files are stored at the peers ¨ 2nd Generation ¤ Systems such a Gnutella & Freenet employ partitioned distributed indexes ¨ 3rd Generation ¤ Rely on Overlays

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.46 Professor: SHRIDEEP PALLICKARA

Requirements for P2P systems

¨ Functional ¤ Specific behaviors or functions that must be supported ¨ Non-functional (or evaluation metrics) ¤ Criteria that can be used to judge the operation of a system

September 5, 2019

slide-24
SLIDE 24

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.24

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.47 Professor: SHRIDEEP PALLICKARA

Functional requirements for P2P middleware

¨ Locate and communicate with any resource made available to the

system

¤ Even though resources are dispersed over a large number of nodes ¨ The ability to add and remove both resources and nodes at will

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.48 Professor: SHRIDEEP PALLICKARA

Non-functional requirements for P2P systems

¨ Scalability ¨ Load balancing ¨ Dynamic host availability

September 5, 2019

slide-25
SLIDE 25

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.25

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.49 Professor: SHRIDEEP PALLICKARA

Non-functional requirements: Load balancing

¨ Achieved via random placement of resources ¨ Replicas of heavily used resources are created

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.50 Professor: SHRIDEEP PALLICKARA

Accommodate highly dynamic host availability

September 5, 2019

¨ Host computers are free to join or leave at any time ¨ Provide a dependable service, from unreliable nodes ¨ As nodes join the system ¤ Must be integrated into the system ¤ Load must be redistributed to exploit their capabilities ¨ As nodes leave the system (voluntarily or involuntarily)? ¤ Redistribute their load and resources n Replication levels for some resources must be preserved

slide-26
SLIDE 26

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.26

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

SYSTEMS THAT WE WILL LOOK AT

September 5, 2019

L4.51 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.52 Professor: SHRIDEEP PALLICKARA

Systems that we will observe closely

¨ 1st Generation ¤ Napster ¨ 3rd Generation ¤ Chord ¤ Pastry ¤ Tapestry ¨ Unstructured P2P or 2nd Generation ¤ Gnutella and BitTorrent

September 5, 2019

slide-27
SLIDE 27

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.27

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

NAPSTER

September 5, 2019

L4.53 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.54 Professor: SHRIDEEP PALLICKARA

Napster

¨ First application in which demand for massively scalable storage and

retrieval arose

¤ Downloading of digital music files ¨ Became very popular soon after its launch ¨ At its peak ¤ Several million users ¤ Thousands swapped music files simultaneously

September 5, 2019

slide-28
SLIDE 28

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.28

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.55 Professor: SHRIDEEP PALLICKARA

Key features of the architecture

¨ Centralized indexes ¨ Users supplied the files ¤ Stored and accessed on their personal computers ¨ Clients add their own music files to the pool of shared resources ¤ Transmit a link to Napster’s indexing service for each available file ¤ Shared resources at the “edge of the internet”

September 5, 2019 CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.56 Professor: SHRIDEEP PALLICKARA

Napster Architecture

Napster Server

Peer

User’s Computer

Peer

User’s Computer

Peer

User’s Computer

Peer

User’s Computer (1) File location request (2) List of peers

  • ffering the file

Peer

User’s Computer (3) File Request (4) File Delivered (5) Index Update Index

September 5, 2019

slide-29
SLIDE 29

SLIDES CREATED BY: SHRIDEEP PALLICKARA L6.29

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

CS555: Distributed Systems [Fall 2019]

  • Dept. Of Computer Science, Colorado State University

L4.57 Professor: SHRIDEEP PALLICKARA

The contents of this slide-set are based on the following references

September 5, 2019 ¨ Distributed Systems: Principles and Paradigms. Andrew S. Tanenbaum and Maarten Van

der Steen. 2nd Edition. Prentice Hall. ISBN: 0132392275/978-0132392273. [Chapter 5]

¨ Distributed Systems: Concepts and Design. George Coulouris, Jean Dollimore, Tim

Kindberg, Gordon Blair. 5th Edition. Addison Wesley. ISBN: 978-0132143011. [Chapter 10]

¨ http://en.wikipedia.org/wiki/Non-functional_requirement