distributed computing peer to peer computing chapter 10: peer to peer systems
TRANSCRIPT
Distributed ComputingPeer to Peer Computing
Chapter 10: PEER TO PEER SYSTEMS
What is peer-to-peer (P2P) computing? Webster definition
Peer: one that is of equal standing with another Computing between equals
Intro to P2P Systems The scope of expanding popular services by
adding to number of the computers hosting then is limited when all the host must be owned & managed by the service provider
Administration and fault recovery costs
Bandwidth that can be provided to a single server Major service provider all face this problem with
varying severity
Intro to P2P Systems P2P application that exploit resources available at
the edges of the internet Storage, content, cycles, human presence
Traditional client-server provide access to these but only on single machine or tightly coupled servers This centralized design required few decisions about
placement & management of resources
In P2P -- algorithm for the placement and subsequent retrieval of information objects are a key aspect of the system design. It’s a system which is Fully decentralized & self organizing Can dynamically balance the storage and processing
loads between all the participating computers as they join and leave
P2P Design Characteristics Their design ensures that each user contributes
resources to the systems Although they may differ in the resources that
contribute, all the nodes in a peer to peer system have the same functionality capabilities and responsibilities
Their correct operation dose not depend on the existence of any centrally administered systems
They can be designed to offer a limited degree of anonymity to the providers and users of resources
Key issues for the their efficient operation is the choice of algorithm for placing and retrieving data on many hosts Balance of load Availability without much overhead
Participants availability to system is unpredictable
Evolution of P2P Can be grouped in three generations
First generation – Napster music exchange service [OpneNap 2001]
Second generation – file sharing applications with greater Scalability, anonymity & fault tolerance Guentella, Kaza, Freenet
Developed with help of middleware layers Application independent management of distributed
resources on a global scale E.g. pastry, Tapestry, CAN, CHORD, JAXTA
Provide of delivery of request of delivery of request in a bounded number of network hops
Place replicas of resources, by keeping mind volatile availability & trustworthiness, locality
Cluster, Grid, P2P: CharacteristicsCharacteristic Cluster Grid P2P
Population Commodity Computers
High-end computers Edge of network (desktop PC)
Ownership Single Multiple Multiple
Discovery Membership Services
Centralised Index & Decentralised Info
Decentralized
User Management Centralised Decentralised Decentralised
Resource management Centralized Distributed Distributed
Allocation/Scheduling Centralised Decentralised Decentralised
Inter-Operability VIA based? No standards yet No standards
Single System Image Yes No No
Scalability 100s 1000? Millions? [@Home]
Capacity Guaranteed Varies, but high Varies
Throughput Medium High Very High
Speed(Lat. Bandwidth) Low, high High, Low High, Low
Example P2P Applications SETI@home Napster Gnutella FastTrack
SETI@home
SETI@home uses the National Astronomy and Ionospheric Center's 305 meter telescope at Arecibo, Puerto Rico.
A screenshot of the SETI@home client program. •2.4 mil volunteers as of Oct. 2000
Distributed computation Usage & Exploitation best example
SETi@home (Search for Extra-Terrestrial Intelligence) Portions a steam of digitized radio telescope data
into 107 second work unit, each about 350KB, distribute them on clients computer
Work unit is redundantly distributed to 3-4 users, to guard against errors & bad nodes
Coordination work is handled by a single server T3.91 million PCs participated in this by 2002 In one year they processed 221 million work units,
data worth 27.36 teraflops on average
Napster Centralized MP3 file sharing Clients/Peers hold the files Servers holds catalog and broker relationships
Clients upload IP address, music file shared, and requests
Clients request locations where requests can be met
File transfer is P2P – proprietary protocol
Napster & its Legacy
Napster serverIndex1. File location
2. List of peers
request
offering the file
peers
3. File request
4. File delivered5. Index update
Napster serverIndex
Napster: peer-to-peer file sharing with a centralized, replicated index
Napster & its Legacy Architecture included centralized index
servers, main reason for defeat in lawsuit Anonymity of receiver & provider Lessons learned from napster
Feasible to develop a large scale P2P service It can scale the resource to meet the need, based
on locality Limitations
Consistency between replicas was not strong, but for music this requirement is not much strong
Index server for accessing the resource was a bottleneck
Gnutella Completely decentralized – no servers with
catalogs Shares any files Gnutella node ---- SERVENT
Issue the query and view search result Accept the query from other SERVENTs and check
the match against its database and response with corresponding result
Gnutella (cont) Joining the network:-
The new node connects to a well-known SERVENT Then sends a PING message to discover other
nodes PONG message are sent in reply from hosts
offering connections with the new node Direct connection are then made
Gnutella (cont) Searching a file:-
A node broadcasts its QUERY to all its peers who in turn broadcasts to their peers
Nodes route back QUERYHITS along the QUERY path back to the sender containing the location detail
To download the files a direct connection is made using details of the host in the QUERYHIT message
Gnutella (cont) Gnutella broadcasts its messages. To prevent flooding -TTL is introduced. To prevent forwarding same mesg. twice -
each servent maintains a list of recently seen mesg.
Gnutella (cont)
GnuCache
A
User A connects to the GnuCache to get the list of available servents already connected in the network GnuCache sends back the list to the user A User A sends the request message GNUTELLA CONNECT to the user BUser B replies with the GNUTELLA OK message granting user A to join the network
User A connects to the GnuCache to get the list of available servents already connected in the network GnuCache sends back the list to the user A User A sends the request message GNUTELLA CONNECT to the user BUser B replies with the GNUTELLA OK message granting user A to join the network
B
D
C
F
G
E
H
J
I
(1) (2)
(3)
(4)(1)
(1)
(1)
(2)
(2)
(2)
(3)
(3)
(3) (3)
(2)
Gnutella (cont) Typical query scenario:-
A sends a query message to its neighbor, B B first checks that the message is not an old one Then checks for a match with its local data If there is a match, it sends the queryHit message
back to user A Else B decrements TTL by 1 and forwards the
query message to users C, D, and E C, D, and E performs the same steps as user B and
forwards the query message further to users F, G, H, and I
Gnutella (cont) Problems
Broadcast mesg. congests the network Lost of reply packets (dynamic environment)
FastTrack Hybrid between centralized and decentralized Has 2 tiers of control:-
Ordinary nodes that connect to super nodes in a centralized fashion
Super nodes that connect to each other in a decentralized manner
FastTrack (cont)
FastTrack (cont) Joining the network? - Bootstrapping node Querying?
Problems (Like Gnutella) Broadcast mesg. between Super Nodes Lost of reply packets
Some key issues Scalability
Networks can grow to millions of nodes Challenge in achieving efficient peer and resource
discovery High amount of query/response traffic
Availability Potential for commercial content provision Such services require high availability and
accessibility Anonymity
What is the right level of anonymity?
Some key issues (cont) Security
Due to open nature, have to assume environment is hostile
Concerns include: Privacy and anonymity File authenticity Threats like worms and virus
Fault Resilience The system must still be able to function even
though several important nodes goes off-line.
Some key issues (cont) Standards and Interoperability
Lack of standards lead to poor interoperability between applications
Can be improved by using common protocols Copyright / Access Control
Classic case of Napster being shut down Other applications have learned to get around the
law Possibility of paid access in future
Some key issues (cont) Quality of Service (QoS)
Metrics to be used is not clearly defined Tradeoff between achieving QoS and costs
Complexity of Queries Must be able to support query languages of
varying degree of expressiveness Simple keywords to SQL-like searches
Search Mechanism Different search algorithms are used to reduced
search time and maximize search space
Some key issues (cont) Load Balancing
existence of hot-spots (overloaded nodes) due to: uneven node distribution throughout logical space uneven object distribution among nodes uneven demand distribution among objects
query and routing hot-spots Self-organization
Ability to adapt itself to the dynamic nature of the Internet
Depends on the architecture of the system
P2P Middleware - GUID Resources are identified by Global Unique Identifier
GUID Derived from secure hash HASH makes a resource self certifying Client receiving the resource can check the hash This requires that states of resources are immutable P2P systems are inherently best suited for the
storage of immutable objects – music file, images Mutable objects sharing can be managed by set of
trusted servers to manage the sequence of versions e.g Oceanstore, Ivy – more in section 10.6
Overlay routing vs IP routing
IP Application-level routing overlay
Scale IPv4 is limited to 232 addressable nodes. The IPv6 name space is much more generous (2128), but addresses in both versions are hierarchically structured and much of the space is pre-allocated according to administrative requirements.
Peer-to-peer systems can address more objects. The GUID name space is very large and flat (>2128), allowing it to be much more fully occupied.
Load balancing Loads on routers are determined by network topology and associated traffic patterns.
Object locations can be randomized and hence traffic patterns are divorced from the network topology.
Network dynamics (addition/deletion of objects/nodes)
IP routing tables are updated asynchronously on a best-efforts basis with time constants on the order of 1 hour.
Routing tables can be updated synchronously or asynchronously with fractions of a second delays.
Fault tolerance Redundancy is designed into the IP network by its managers, ensuring tolerance of a single router or network connectivity failure. n-fold replication is costly.
Routes and object references can be replicated n-fold, ensuring tolerance of n failures of nodes or connections.
Target identification Each IP address maps to exactly one target node.
Messages can be routed to the nearest replica of a target object.
Security and anonymity Addressing is only secure when all nodes are trusted. Anonymity for the owners of addresses is not achievable.
Security can be achieved even in environments with limited trust. A limited degree of anonymity can be provided.
Peer to Peer to Middleware Key problem in p2p application design:
“Provide mechanism to enable clients to access data resources quickly & dependably whenever they are located throughout the network” Napster used a unified index 2nd generation p2p file systems like Gnutella &
Freenet employ portioned & distributed indexes, but the algorithm used are specific to each system
P2P Middleware P2P Middleware are designed specifically for placement &
subsequent location of the distributed objects managed by different p2p systems
Functional Requirements Simplified construction of distributed services
Locate resources and communicate with resource provider & consumer
Add & remove resources at will anytime API for the p2p programmers
Non Functional Requirements Global Scalability Load Balancing Optimization for local interaction between neighboring
peers Accommodating to highly dynamic host availability Security of data in an environment with heterogeneous
trust Anonymity, deniability and resistance to censorship
Routing Overlay In P2P we cannot maintain the database at all the
client nodes, giving the location of all the resources
Resource location knowledge must be partitioned and distributed
Each node is made responsible for maintaining detailed knowledge of the locations of nodes and
objects in a portion of the namespace As well as general knowledge of the topology of the
entire name space High degree of replication of this knowledge is
necessary to ensure dependability in the face of the volatile availability of hosts and intermittent network connectivity.
Distribution of information in a routing overlay
Object:
Node:
D
CÕs routing knowledge
DÕs routing knowledgeAÕs routing knowledge
BÕs routing knowledge
C
A
B
Routing overlay takes the responsibility for locating nodes and objects
Routing Overlay Ensures that any node can access any object
by routing each request through a sequence of nodes, exploiting knowledge at each of them to locate the destination object
It also maintains the knowledge of location of all the replicas of the object and deliver request to nearest live node
GUID used to identify nodes and objects are an example of pure name “opaque identifier” It dose not reveal identity of the location of the
object
Tasks of Routing Overlay Main task of Routing Overlay
Client wishing to invoke an operation on an object submits a request including the object’s GUID to the routing overlay, which routes the request to a node at which a replica of the object resides
Other task of Routing Overlay Node wishing to make new object available to a P2P
service computes a GUID for the object and announces it to the routing overlay, which then ensures that the object is reachable by all other clients.
When clients request the removal of the object from the service the routing overlay must make them unavailable.
Nodes may join or leave the service, when a node joins the service, the routing overlay arranges for it to assume some of the responsibilities of other nodes. When a node leaves its responsibilities are distributed amongst the other nodes.
Basic programming interface for a distributed hash table (DHT) as implemented by the PAST API over Pastry
put(GUID, data) The data is stored in replicas at all nodes responsible for the object identified by GUID.
remove(GUID)Deletes all references to GUID and the associated data.
value = get(GUID)The data associated with GUID is retrieved from one of the nodes responsible for it.
Basic programming interface for distributed object location and routing (DOLR) as implemented by Tapestry
publish(GUID ) GUID can be computed from the object (or some part of it, e.g. its name). This function makes the node performing a publish operation the host for the object corresponding to GUID.
unpublish(GUID)Makes the object corresponding to GUID inaccessible.
sendToObj(msg, GUID, [n])Following the object-oriented paradigm, an invocation message is sent to an object in order to access it. This might be a request to open a TCP connection for data transfer or to return a message containing all or part of the object’s state. The final optional parameter [n], if present, requests the delivery of the same message to n replicas of the object.
Overlay Case Study: Pastry All the nodes & objects are assigned 128-bit GUIDs
For nodes: For nodes: computed by applying a secure hash function to public key of the node
For objects: For objects: computed by applying a secure hash function to the objects name or some part of its stored state
Resulting GUIDs are randomly distributed in the range 0 to 2128 -1
Provide no clue how these values are computed and clashes between GUIDs for different nodes or objects are extremely unlikely, still pastry can detect & mange this unlikely event
In a network with N participating nodes the Pastry algo will correctly route a message addressed to any GUID in O(log N) steps
If GUID identifies a node which is active, message is delivered to that node otherwise delivered to a active node with closet numeric GUID
Pastry Routing steps involve the use of an underlying transport
protocol (normally UDP) to transfer the message to a Pastry node that is closer to its destination
Closeness in pastry refers to an entirely artificial space – the space of GUIDs Real transport of message across internet between two
pastry nodes may require lots of IP hops. For better path option, pastry uses locality metric on
network distance in the underlying network (hop count, two way latency) to select appropriate neighbors when setting up the routing tables used at each node
Pastry id fully self organizing New nodes get info form neighbors to construct the table Nodes can detect the absence of the node and can update
the table
Pastry: Routing Algo Explanation in two stages
Stage 01: simplified form of the algo which routes messages correctly but inefficiently without a routing table
Stage 02: full routing algo which routes request to any node in O(log N) messges
Figure 10.6: Circular routing alone is correct but inefficient Based on Rowstron and Druschel [2001]
The dots depict live nodes. The space is considered as circular: node 0 is adjacent to node (2128-1). The diagram illustrates the routing of a message from node 65A1FC to D46A1C using leaf set information alone, assuming leaf sets of size 8 (l = 4). This is a degenerate type of routing that would scale very poorly; it is not used in practice.
0 FFFFF....F (2128-1)
65A1FC
D13DA3
D471F1
D467C4D46A1C
Pastry: Routing Algo Each pastry nodes maintain a tree structured
routing table giving GUIDs and IP addresses for a set of nodes spread through out the entire range of 2128 possible values, with increased density of coverage for GUID numerically close to its own
Fig 10.7 shows the structure of the routing table Fig 10.8 illustrate the actions of the routing
algorithm
Routing tables are structured as
GUIDs are viewed as hexadecimal values & tables classifies GUIDs based on their hexadecimal prefixes
Tables has as many rows as there are hexadecimal digits in a GUID, so for our prototype there are 128/4 = 32 rows
Each row contains 15 entries
Figure 10.7: First four rows of a Pastry routing table
Figure 10.8: Pastry routing example Based on Rowstron and Druschel [2001]
0 FFFFF....F (2128-1)
65A1FC
D13DA3
D4213F
D462BA
D471F1
D467C4D46A1C
Routing a message from node 65A1FC to D46A1C.With the aid of a well-populated routing table themessage can be delivered in ~ log 16(N ) hops.
Figure 10.9: Pastry’s routing algorithm
To handle a message M addressed to a node D (where R[p,i] is the element at column i,row p of the routing table):
1. If (L-l < D < Ll) { // the destination is within the leaf set or is the current node.2. Forward M to the element Li of the leaf set with GUID closest to D or the current
node A.3. } else { // use the routing table to despatch M to a node with a closer GUID4. find p, the length of the longest common prefix of D and A. and i, the (p+1)th
hexadecimal digit of D .5. If (R[p,i] ° null) forward M to R[p,i] // route M to a node with a longer common
prefix.6. else { // there is no entry in the routing table7. Forward M to any node in L or R with a common prefix of length i, but a
GUID that is numerically closer.}
}
Pastry’s routing algorithm Algo will succeed in delivering the message
M to its destination cuase lines 1,2 & 7 They perform action as described in stage 01
The remaining steps are designed to improve the alogrithm’s performance by reducing the numbers of hops required
Host Integration Node compute GUID Contact near by node – address of nearby node ??
X is the new node sends join request to A A will dispatch the join as normal message to numerically
nearest node of X, using Pastry algo. Let that node is Z A, Z and all the nodes (B, C …) through which the
message was routed to Z Add relevant part of their RT and leaf sets to X X examines these leaf sets and construct its own routing table
& leaf sets Can request some other nodes for additional info X’s leaf set node should be very much similar to Z leaf set
Once X RT is constructed it send its leaf set and RT entries, info to other nodes are other nodes to update their RT
RT updates Node failure or departure
Node is considered failed when its immediate neighbors are unable to contact
Node which discovers the failure of the node, looks for the next nearest live node, and request for its leaf set
This leaf set will contain the overlapping info of failed node leaf set. Discovering node will choose the best node from this leaf set to replace the failed node.
Self study Locality Fault tolerance Dependability – MS Pastry Evaluation of MS Pastry
ThanksThanks
Dr. Raihan! remember & keepup ur promise Dr. Raihan! remember & keepup ur promise