P2P Architectures Klaus Marius Hansen University of Aarhus 2003/09/09 Introduction to software architecture. Reference architectures for P2P systems. Communication paradigms for P2P computing P2P Architectures Material Software Architecture Introduction P2P Reference Architectures P2P Communication Paradigms Summary Material Material (Taylor & Dashofy 2001) o Taylor, R.N. and Dashofy, E.M. (2001) Function Follows Form: Architecture and 21st Century Software Engineering. In Proceedings of the Vanderbilt Workshop on New Visions for Software Design & Productivity: Research & Applications o A general discussion of architectures for novel application areas, focussing on publish/subscribe and P2P architectures (Melville, Walkerdine & Sommerville 2003) o Melville, L., Walkerdine, J. & Sommerville, I. (2003), P2P Reference Architectures, Technical Report IST-2001- 32708, Lancaster University. o Chapter 1 cursory, chapter 2 o Gives "reference architectures" for P2P computing. Discusses existing systems in relation to these reference architectures (Baehni, Eugster & Guerraoui 2002) o Baehni, S., Eugster, P. & Guerraoui, R. (2002), OS support for P2P programming: A case for TPS. Technical Report 200204, Computer and Communication Sciences, LEcole Polytechnique Federale de Lausanne (EPFL).
Transcript
P2P ArchitecturesKlaus Marius HansenUniversity of Aarhus2003/09/09Introduction to software architecture. Reference architectures for P2P systems. Communication paradigms for P2P computing
P2P Architectures Material Software Architecture Introduction P2P Reference Architectures P2P Communication Paradigms Summary
Material
Material
(Taylor & Dashofy 2001)o Taylor, R.N. and Dashofy, E.M. (2001) Function Follows Form: Architecture
and 21st Century Software Engineering. In Proceedings of the Vanderbilt Workshop on New Visions for Software Design & Productivity: Research & Applications
o A general discussion of architectures for novel application areas, focussing on publish/subscribe and P2P architectures
(Melville, Walkerdine & Sommerville 2003)o Melville, L., Walkerdine, J. & Sommerville, I. (2003), P2P Reference
Architectures, Technical Report IST-2001-32708, Lancaster University. o Chapter 1 cursory, chapter 2o Gives "reference architectures" for P2P computing. Discusses existing systems
in relation to these reference architectures (Baehni, Eugster & Guerraoui 2002)o Baehni, S., Eugster, P. & Guerraoui, R. (2002), OS support for P2P
programming: A case for TPS. Technical Report 200204, Computer and Communication Sciences, LEcole Polytechnique Federale de Lausanne (EPFL).
o Mixes the two communication paradigms presented in (Taylor & Dashofy 2001): P2P and publish/subscribe. Discusses a prototype built on top of JXTA
Software Architecture Introduction
What is "Software Architecture"?
The software architecture of a program or computing system is the structure of the system, which comprise software components, the externally visible properties of those components, and the relationship among them
Implicationso Every software system has a software architecture
Architectures exist independently of their representationo Architecture defines components
Architecture balances between abstracting away detail and still allowing for meaningful analysis of systems
o Software systems can comprise more than one structure No structure is the architecture
Canonical reference on software architecture:o (Bass, Clements & Kazman, 2003) Bass, L., Clements, P. & Kazman, R.
(2003) Software Architecture in Practice, 2nd edition, Addison Wesley, 2003 o Definitions stolen from there
Why is Software Architecture Important?
Enables communication among stakeholderso Software architecture represents a common high-level abstraction - learning
what a system is all abouto Basis for mutual understanding, forming consensus, communication among
customers, developers, users Allows early design decisionso Design and build software systemso Amenable to analyses
Creates transferable abstractions of a systemo Relatively small, intellectually graspable model of a systemo Can be applied to other systems - effective level for addressing reuse issues
A Bad Architecture Description - Why?
Architectural Structures (1)
Conceptual/logical structureo Components: Abstractions of the systems functional requirementso Connectors: Shares-data-with relationso Useful for: Understanding interactions between entities in problem space
Process/coordination structureo Components: Processes or threadso Connectors: Synchronizes-with, can't-run-without, preempts, ...o Useful for: Dealing with process synchronization and concurrency
Uses structureo Components: Procedures or moduleso Connectors: Assumes-the-correct-presence-of relationo Useful for: Engineering easily extensible systems (e.g., using incremental
build)
Architectural Structures (1) - Example
...
Architectural Structures (2)
Module structureo Components: Work assignments with associated products (interface, code, ...)o Connectors: Is-a-submodule relationso Useful for: Allocating work during maintenance and development
Calls structureo Components: (Sub)procedureso Connectors: Calls or invokes relationso Useful for: Tracing flow of execution
Data flowo Components: Programs or moduleso Connectors: May-send-data to relationso Useful for: Requirements traceability
Control flowo Components: Programs, modules or system stateso Connectors: Becomes-active-after relationso Useful for: Verifying functional behaviour as well as timing properties
Class structureo Components: Objects
o Connectors: Inherits-from or is-an-instance-ofo Useful for: Reasoning about collections of similar behaviour
...
Architectural Structures (3) - Example
...
Architectural Description Languages (ADLs) (1)
Used to describe architectural structureso Precise (and more or less formal)o Provide overviewo Useable for analysis and design
A plethora of variantso We just saw the Unified Modeling Language (UML) used as an ADL
Stereotyped class diagrams with objects for logical structure Class diagrams with packages for module structure Combined deployment and component diagrams for physical/process
structureo Another example: The WRIGHT Language
Architectural Description Languages (ADLs) (2)
Configuration SimpleSimulation
Component TerrainModel(map : Function)
Port ProvideMap = [Interaction Protocol]
Computation = [provide terrain data]
Component = VehicleModel
Port Environment = [Interaction Protocol]
Computation = [compute vehicle movement]
Connector UpdateValues(nsims : 1..)
Role Model1::nsims = [Interaction Protocol]
Glue = [Data travels from one Model to another]
Instances
Pittsburgh : TerrainModel([map of Pittsburgh])
PAT Bus : VehicleModel
C : UpdateValues(2)
Attachments
Pittsburgh.ProvideMap, PAT Bus.Environment as C.Model
End SimpleSimulation.
An ... Architecture Description
Quality Attributes
Two broad categories of quality attributeso Observable via execution
How well does the system satisfy its behavioural requirements? Does the system act in a timely enough manner? Does the system function as expected when connected to other
systems?o Not observable via execution
How easy is the system to integrate? How expensive was the system to develop? What was the time-to-market of the system?
Architecture is critical to realizing many quality attributes in systems Some qualities are not architecture-sensitive
Qualities Discernible at Runtime
Scalabilityo The ability of a system to support an increasing use
Performanceo The time it takes for a system to react to a stimulus
Securityo The degree to which a system can withstand attacks
Availabilityo The part of the deployment period during which a system can deliver the
services it implements
Qualities Not Discernible at Runtime
Modifiabilityo The ability to make changes to the system effectively
Portabilityo The ability of a system to run in different execution environments
Reusabilityo The degree to which a system's components are usable in future systems
Integrabilityo The ability of a system to get separately developed ocmponents to work
together Testabilityo How well a system supports effective and efficient testing
Software Architecture Introduction - Summary
Software architecture is concerned with components and connectors of a system A number of architectural structures exist - each are useful for certain aspects of
architecture design/work Many quality attributes of software systems are tightly connected to (software)
architecture
P2P Reference Architectures
Reference Architectures et al. (1)
Architectural styleo A description of component types and a pattern of their runtime control and/or
Reference modelo A division of functionality together with data flow, typically in mature
application domainso Examples: model for compiler, database management system, microkernel
operating system Reference architectureo A reference model mapped onto software components (that will cooperatively
implement the functionality defined in the reference model) and the data flows between the components
o Examples: J2EE, OSGi, ISO OSI
Reference Architectures et al. (2)
Architectural styles, reference models, and reference architectures are not architectures
(Melville, Walkerdine & Sommerville 2003)
Reference architectures seen from a conceptual view (and in a layered style) Also induced physical/logical network structureo Most P2P systems builds a logical overlay network
On top of TCP, UDP, HTTP, Bluetooth, ... More on routing and location later...
o Different Types
Network structures
Layers
Looks at layers for server, client, and decentralized peerso Cf. different network structures
Common layerso Network Interface Layer
Represents a physical connection to a networko P2P Network Layer
o Awareness Monitor Layer Monitor and support peers', users', and resources' awareness and
availabilityo Data Search/Filtering Layer
Searching the index of the Data Repository Client-specific layerso Awareness Controller Layer
Using Awareness Monitor and caching awareness information Peer-specific layers ("decentralised-specific layers")o P2P Network Layer
Publishing and discovery of data since there is not central server
Shared Workspace
Requirementso Allowing peers and users to discover, be aware of, communicate with, identify
each other of eacho Ensuring a high quality of service for communicationso Providing security within the systemo Allowing data to be stored and managed on the peerso Allowing for the creation of a shared workspace user interface for the peerso Allowing for the creation of de-centralised and semi-centralised systems
Exampleo Groove
Shared Workspace - Server
Shared Workspace - Client
Shared Workspace - Peer
Search System
Requirementso Allowing peers to discover and be aware of each othero Allowing peers to discover and be aware of resources (for example, data) that
may exist on the network
o Allowing peers to communicate with each other, including allowing the transference of data
o Allowing peers to search the network for resources, potentially using a variety of filtering techniques
o Allowing peers and resources to be uniquely identified on the networko Providing security within the systemo Allowing data to be stored and managed on the peerso Allowing for the creation of a search system user interface for the peerso Allowing for the creation of de-centralised and semi-centralised systems
Hybrid of search and shared workspace reference architectures
Mapping of Reference Architectures - JXTA
"The P2P Network" comparable to Network Interface layer (representing peers on network)
"JXTA Core" comparable to P2P Network Layer "JXTA Services" map to various layers (and application capabilities) "JXTA Applications" is not specifically represented in reference architectures
P2P Reference Architectures - Summary
Reference architectures embody a reference model and architectural styles P2P reference architectures are useful for designing software architectures for P2P
systems Melville et al.'s list is a starting point, but not exhaustive
P2P Communication Paradigms
"Architectures for the 21st Century"
(Taylor & Dashofy): Two architectural styles essential for current and future software systems
P2P architectureso Independent agents capable of performing useful worko No central authority
Event-based notification architectureso Loosely coupled, highly dynamico Listens for notifications, take action based on these
Why not combine these?o (Baehni, Eugster & Guerraoui 2002)
Publish/subscribe
Publish/subscribe: event buso publish eventso subscribe to events by giving criteria
Traditional publish/subscribe
o subject-based or content-based publish/subscribeo an event = a list of simple name/value pairs
Type-Based Publish/Subscribe (TPS) is an object-oriented varianto events are instances of application-defined types, i.e., objectso generalisation of subject- and content-based pub/sub
TPS "Architecture"
TPS Example (1)
TPS Example (2)
class StatusChangedEvent extends PublishSubscribe.Event {
private String user;
private String status;
public String getUser() {return user;}
...
}
StatusChangedEvent event = new StatusChangedEvent("damm", "active");
publish event;
Subscription s = subscribe (StatusChangedEvent event) {
Publish/subscribe mechanisms decouple publishers and subscribers ino Space: publishers and subscribers need not know the location of each othero Time: publishers and subscribers need not be available at the same timeo Flow: sending and receiving messages is non-blockingo Data: subscribers only receives events they are interested in
TPS integrates this into object-oriented software architectureso Stays native (compare RMI vs. socket communication)o Integrated data and computation in eventso Modelling with event hierarchies
Suitable for P2P applications
Idea: Combine TPS & JXTA
TPS Over JXTA
Main characteristicso Uses the August 2001 JXTA implementation (old)o Uses propagation pipes and algorithms
Unreliable, unsecure One-to-many (one output, may input pipes) + propagation
o One type is represented by one advertisemento Uses Generic Java (GJ)
"List<Integer>" Allows to create templates in Java (similar to virtual classes)
Avcids casts when using collections Integrated in Java 1.5
o Part of the JXTA application layer
Architecture (1)
(Which structure(s)?)
Architecture (2)
Programming
Initialization
TPSEngine<SkiRental> tpse = new TPSEngine<SkiRental>();
TPSInterface tpsInt = tpse.newInterface("JXTA", null, new SkiRental(), argv);
Callback interface
public class MyCBInterface implements TPSCallBackInterface<SkiRental> {
public void handle(SkiRental skiR) {
...
}
}
Exception handler
public class MyExHandler implements TPSExceptionHandler<SkiRental> {
Better abstractions for (some) P2P applicationso High-levelo Easy to useo Type safety
o Decoupling Performance compared to same application in JXTAo Same invocation timeo Same publisher throughputo Same subscriber throughput
Summary
Summary
Working with software architecture is essential for any complex software system - including P2P system
Reference architectures may help in constructing software architectures - and thus systems
Publish/subscribe and P2P communication paradigms may be beneficially combined
Created by JackSVG
Quality AttributesKlaus Marius HansenUniversity of Aarhus2003/09/16Quality attributes of P2P systems. Dependability. Performance. Measurements. Scalability.
Quality Attributes Material Dependability and P2P Performance and P2P Measurements of P2P Systems Scalability of P2P Systems Summary
Material
Material
(Walkerdine, Melville & Sommerville 2002)o Walkerdine, J., Melville, L. & Sommerville, I. (2002), Dependability
properties of P2P architectures, Technical Report, http://polo.lancs.ac.uk/p2p/, Lancaster University.
o General discussion of dependability-related quality attributes in P2P computing.
(Oram 2001) chapter 14o Hong, T. (2001), Performance. In Oram, A. (Ed.), Peer-to-Peer. Harnessing
the Power of Disruptive Technologies, O'Reilly, pp 203-242.
o Introduction to the "small worlds" model of P2P systems. Discusses performance of Gnutella- and Freenet-like P2P systems.
(Saroiu, Gummadi & Gribble 2002)o Saroiu, S., Gummadi, P. K. & Gribble, S. D. (2002), A measurement study of
peer-to-peer file sharing systems, in Proceedings of Multimedia Computing and Networking (MMCN) 2002, pp. 407-418.
o Measurements of the nature of peers in Napster and Gnutella (Chawathe, Ratnasamy, Breslau, Lanham & Shenker 2003)o (Chawathe, Y., Ratnasamy, S., Breslau, L., Lanham, N. & Shenker, S. (2003),
Making Gnutella-like P2P systems scalable, in Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM'03), pp. 407-418.
o Presents algorithms based on the observations of (Saroiu, Gummadi & Gribble 2002)
Dependability and P2P
Dependability
The thrustworthiness of a system - captures a number of desirable characteristic of a system
Context sensitiveo Gnutella may be fine for sharing of personal files, but not for sharing of
corporate files...o Freenet may be fine for anonymous publishing, but not for backup
applications... Affected by other architectural properties such as reliability and security Further complication: A large number of different software architectures exist - e.g.,
not one single reference architecture
What Influences Dependability?
Reliability Scalabilityo Today
Securityo Later lectures
Survivability/Robustness/Fault Toleranceo Today
Safetyo Not in this course, but intriguing...
Maintainability Responsiveness/Performanceo Today
Responsibility, Accountability, Reputationo Later lectures
Availabilityo Today
Performance and P2P
"Performance"
The responsiveness of a system - the time required to respond to stimuli (events) or the number of events processed in some interval of timeo Communication between components often take longer than computation
within components - particularly for distributed systemso Thus performance is related to the communication and interaction patterns
between components, which is architectural in natureo Historically a driving quality attribute, but not necessarily any longer in
general Hong (2001) presents an analysis of this for a class of P2P systems, but really
simulates more than that
Why is performance important for P2P systems?
P2P are distributed, often with frequent communication and coordination Moore's law doesn't apply to Internet connection speed... Decentralised systems use messages forwarded over many hops (bandwidth and
connection time)
The Small-World Effect
1967: Stanley Milgram gave 160 people in Omaha, Nebraska a letter eacho Task: Pass this letter to a particular stockbroker in Boston, Massachusettso Use only intermediaries known on a first-name basiso (Widely criticized as a scientific experiment)
Resultso 42 letters made it througho Median number of 5,5 intermediaries (compare 200 million people in US in
1967)!o Example: an Engineer in Omaha passed it to a transplanted New Englander
living in Bellevue, Nebraska, who passed it to a math teacher in Littleton, Massachusetts, who gave it to a local shopkeeper, who gave it to the stockbroker...
Consider the situtation as a grapho Nodes as people, edges as relationships between peopleo Why such a small characteristic pathlength (= average of distances between all
pairs of nodes in a connected graph)?
A Small-World Model (1)
Social networks are highly cliquish/clustered? However, "bridges" between social clusters existo A quarter of all chains reaching the target person, passed through the same
local shopkeeper o Half the chains were mediated by three people
Small number of bridges dramatically reduces the characteristic pathlength...
A Small-World Model (2) - Regular Graphs
Consider a regular grapho Connectedo n nodes, all of degree k
o Long characteristic pathlength ~ n/2k for n >> ko High clustering coefficient
(= proportion of possible links between neighbours that are present)
A Small-World Model (3) - Random Graphs
Consider a random grapho n nodes, random (probability p) edge to on average k (= (n-1)p) neighbours
o Short characteristic pathlength ~ log n/log k for n >> ko Low clustering coefficient (p ~ k/n)
A Small-World Model (4) - Hybrid graphs
"Rewire" edges in regular graph with probability po p = 0: regular grapho p = 1: random graph
With higher p, clustering remains high, but pathlength drops
Case: Freenet
Freenet forwards queries for a GUID based on "closeness" of known GUIDso GUID and data location is cached on way backo Creates a directed graph of Freenet nodes and references to other nodes
Claim: Freenet exhibits small-world characteristicso Requires connectedness - induction and insert/request implementationo Requires short characteristic pathlengths + high clustering - anonymity, need
to do simulation...
Freenet Simulation
Step 1: Evolving a reqular network topologyo Create 1000 initial nodes, empty data store, space for 50 data items, and 200
o Simulate network usage. At each time step Pick random node Perform a request or insert from that node using random key
Measure network state each 100 time steps
Evolving a Regular Network - Evolution of Pathlength and Clustering Over Time
Pathlength decreases rapidly, clustering coefficient less so - small-world effect How does this relate to performance...?
Probing Static Network - Median Request Pathlength Over Time
Performance ~ number of hops per request For every 100 time steps, simulate 300 request on static network, TTL = 500 Not optimal, based on local routing rather than global optimisation
Probing Static Network - Random Routing - Median Request Pathlength Over Time
Worse than Freenet's local routing... Corresponds to random walks (more later)
Simulating Growth - Median Request Pathlength in a Growing Network
Start with 20 nodes, add new nodes incrementally Inserts, requests, probes as before
Fault Tolerance - Change in Request Pathlength Under Random Failure
Freenet holds up until 30% of nodes removed
Fault Tolerance - Change in Request Pathlength Under Targeted Attack
Freenet now only holds up until 18% of nodes removed
Fault Tolerance - Proportion of Nodes vs. Number of Links
Highly skewed Well-connected nodes see more requests, and thus tend to get even better connected
over time
Scalability - Median Request Pathlength vs. Network Size
Characteristic pathlength grows logarithmically with number of nodes Well-connected nodes see more requests, and thus tend to get even better connected
over time Bandwidth requirements also scales logarithmically (since messages transmitted per
request is proportional to request pathlength)
Case: Gnutella
Queries in Gnutella are forwarded to connected peers, if file is found, an answer is sent backo Query continues within a TTL boundo Breadth-first search of network - given sufficiently high TTL, the shortest path
to data will be found Claim: Gnutella does not exhibit small-world characteristics - little network adaptation Simulation againo Random graph, 3 edges per vertex in average
Nodes Contacted - Distribution of the Number of Nodes Contacted per Query
Good worst-case performance, high network saturation
Scalability - Median Number of Nodes Contacted per Query vs. Network Size
Characteristic pathlength scales logarithmically with network size But bandwidth usage scales linearly...
(Current solution: "Super Peers", indexing all files of subordinate peers, cf also Kazaa)
Summary
P2P performance is most often dominated by communication costs Graph model of P2P systems as a basis of performance considerationso Nodes: peers, edges: connections to other peerso Freenet: Small-world graph, scales wello Gnutella: Random graph, good worst-case performance
Fundamental assumption: Peers are homogeneous (except for free riders)
Measurements of P2P Systems
Motivation
How do peers actually behave in P2P (file sharing) systems? Should be taken into account when designing P2P systems and algorithms Measurements of actual Napster and Gnutella use (i.e., no simulation)
Gnutella and Napster Revisited
Napstero Servers maintain index of files on peerso Also maintain metadata such as peers' reported connection bandwidth and
duration of connection to systemo Metadata returned with query answers
Gnutellao Peers form overlay network through point-to-point connections with a set of
neighbourso Queries flooded throughout the network - controlled by TTL fieldo Ping/pong messages used to manage overlay network
Measurement Methodology
Two stepso Periodically crawl each system to gather snapshots of peers participatingo Actively probe discovered peers over a couple of days to measure properties
Measured propertieso Latency
Round-trip time of TCP packet between measurement machine and peer
TCP discriminates against high round-trip timeso Lifetime
Using low-level TCP packets to tell whether peers are offline, inactive, or active
o Bottleneck Bandwidth The slowest hop between two hosts Used to approximate available bandwidth at peer
The Napster Crawler
No access to central Napster serverso Need to query for popular files and cache peers referenced in responses
Ask servers for metadata based on discovered peerso Reported bandwidtho Number of files shared by peero Current number of uploads and downloads in progress by the peero Names and sizes of files shared by the peero IP address of peer
Captured 40%-60% of peers on crawled server, contributing to 80%-95% of shared files (based on statistics from server)
Biased towards popular files
The Gnutella Crawler
Using well-known peers for bootstrappingo And ping/pong iteratively on the set of discovered peers
Capture metadata from pong messageso IP addresso Number and size of files shared
Captured 8000-10000 peers ~ 25%-50% of Gnutella peer population at a given time No biases
Peer Characteristics
"Server" peers need o High bandwidth (particularly upstream)o Low latencyo High availability
"Client" peers are o Not sharing fileso Always downloading
Potential heterogeneity has implication for P2P systems design...
Measured Bottleneck Bandwidths for Gnutella
92% with downstream bottlenecks > 100Kbps, only 8% with upstream bottleneck > 10 Mbps
22% with upstream bottleneck bandwidths < 100 Kbps, i.e., unsuitable to serve content and data to a high number of connections
Measured Latencies for Gnutella
Substantial fraction (20%) with latencies > 280ms
Session Durations
Measured durations less than twelve hours (due to length of total measurement period) Median duration is 60 minutes
Number of Shared Files in Gnutella
25% of peers do not share files 7% of peers share more than 1000 files, and more files than all other peers collectively
Willingness to Cooperate? (Reported Bandwidths for Napster)
30% of peers report Modems + ISDN but have higher bandwidth
Summary
Addresses need for actual data about peer behaviour Extensive measurements of real use of Napster and Gnutella Lessons for P2P system and algorithm designo Algorithms for P2P systems should take heterogeneity into account -
connection speed, latency, lifetime, shared data varies widelyo Peers should have incentives to cooperate
Scalability of P2P Systems
Gnutella Scalability?
One study showed (Clip2)...o Query rate of 10 queries per secondo 560 bits total per Gnutella queryo Queries = one quarter of Gnutella traffico On average three remote peers actively connected
10 queries/second
* 560 bits/query
* 4
* 3
------------------
67,200 bits/second
Compare common network connection speed and homogeneous networks...
Then What?
"Gia" protocol (and P2P system)designo Trying to take peer capacity constraints into accounto Here: capacity = number of requests a peer can handle per second
Four key componentso Dynamic topology adaptationo Active flow controlo One-hop replication of pointers to contento Biased random walks
Modelled on top of the Gnutella protocol
Topology Adaptation
Goal: ensure that high capacity nodes have high degree and that low capacity nodes are within short reach of higher capacity ones
Each node maintains node cache of other known nodes to be used for topology adaptation
Compute satisfaction level S for each node (say X)o S < 1: Adapt topology for X to have new neighbours and higher satisfaction
Pick potential neighbours for X randomly (prefer ones with high capacity)o num_nbrs(X) + 1 > max_nbrs: pick_neighbor_to_drop(X,Y)
pick_neighbor_to_drop(X,Y)
Active Flow Control
Nodes are only allowed to direct queries to neighbours, if actively allowed to do soo In "common" flow control mechanisms for Gnutella, nodes drop messages if
they are overloadedo Not acceptable to drop messages indiscriminately when using random walks
(more later) Gia assigns flow tokens to nodes that nodes send to neighbours from which they are
able to handle requests Assignment of tokens according to advertised capacity of neighbours - builds
incentive
One-Hop Replication of Pointers to Content
Each node maintains an index of the contents of neighbours Index incrementally updated - mostly up-to-date...
Biased Random Walks
Observation: high capacity nodes can typically provide most useful response for requests
Nodes forward incoming requests to nodes with highest capacity (for which it has a flow control token)
Simulation
Comparingo FLOOD: Search using TTL-scoped flooding over random topologies
Corresponds to original Gnutella protocolo RWRT: Search using random walks over random topologies
Corresponds to other proposed search techniqueso SUPER: Search using supernode mechanisms in which queries are only
flooded between supernodes and supernodes maintain indices for connected connected subnodes
Corresponds to the KAZAA protocolo GIA
Resultso Three to five orders of magnitude (1,000 to 100,000 times) improvement in
total capacity - retaining robustnesso No single component of Gia responsible for performance boost
Comparisons of Collapse Points
Collapse point = point beyond which success rate for queries drop below 90%
Summary
Summary
Dependability as central - discussed related qualities Performanceo Network communication dominateso Graph-based model for performance of Freenet and Gnutella
Measurements Measurements of real use of Napster and Gnutella Peers are heterogeneous Peers need incentives in order to cooperate Scalabilityo Gnutella-like protocol based on peer capabilitieso Orders of magnitude better scalability than previous protocols
Created by JackSVG
Routing and Location in P2P NetworksKlaus Marius HansenUniversity of Aarhus2003/09/23Routing and location in previously introduced systems. Routing in structured overlay networks: Pastry and Chord.
Routing and Location in P2P Networks Material Routing and Location in Introduced P2P Systems Pastry Chord Summary
Material
Material
Previous systems introduced in the course (Rowstron & Druschel 2001)o Rowstron, A. & Druschel, P. (2001), Pastry: Scalable, distributed object
location and routing for large-scale peer-to-peer systems, in IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001), pp. 329-350.
o P2P routing and location in a structured overlay network taking into account network locality
(Stoica, Morris, Liben-Nowell, Karger, Kaashoek, Dabek & Balakrishnan 2003)o Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek, M. F.,
Dabek, F. & Balakrishnan, H. (2003), Chord: A scalable peer-to-peer lookup protocol for internet applications, IEEE/ACM Transactions on Networking Software 11(1), 17-32.
o Algorithms for location in P2P networks. Provable correctness and performance.
Routing and Location in Introduced P2P Systems
Background
Routing: the process of moving a data packet to a location Central Questionso How do we efficiently locate a peer?o When a peer is located, how do we efficiently route messages to and from that
peer?o ... of course all in the context of no global network knowledge, and frequent
joins and leaves by peers...
A Traceroute Example
Indexed
Using index servers for location, IP for routingo Napstero SETI@Homeo ICQ
(Unstructured) walks based on neighbor setso Gnutellao Kazaa (hybrid)o (JXTA)
Key-Proximity
Route based on (unstructed) narrowing down of difference in keyso Freeneto Windows P2P
Weaknesses
Single point of failure for indexed Potentially low performance for walking/flooding Hard to prove correctness/performance/space requirements for routing protocols
Pastry
Pastry
Overview
Effective, distributed object location and routing substrate for P2P networkso "Effective": O(log N) routing hopso "Distributed": no servers, routing and location distributed to nodes, only
limited knowledge (size O(log N) of routing tables) at nodeso "Substrate": not an application itself, rather it provides Application Program
Interface (API) to be used by applications Runs on all nodes joined in a Pastry network
Each node has a unique identifier (nodeId) Given a key and a message, Pastry routes the message to the node with nodeId
numerically closest to the key Takes into account network locality
Pastry API
Pastry exportso nodeId = pastryInit(Credentials, Application)make the
local node join/create a Pastry network. Credentials are used for authorization. An object used for callbacks is passed through the Application parameter
o route(msg, key): routes a message to the live node D with nodeId numerically closest to the key (at the time of delivery)
Application interface to be implemented by applications using Pastryo deliver(msg, key): called on the application at the destination node for
the given ido forward(msg, key, nextId): invoked on applications when the
underlying node is about to forward the given message to the node with nodeId = nextId. (Actually using the FreePastry 1.3 open source Java is slightly more involved)
Assumptions and Guarantees
Each node is assigned a 128 bit nodeIdo nodeIds are assumed to be uniformly distributed in the 128 bit id space =>
numerically close nodeIds belong to diverse nodeso can be achieved, e.g., using a crypthographic hash of IP address of a node
Pastry can route to numerically closest node in ceiling(log2^b(N)) steps (b is a configuration parameter)o If less than |L|/2 (|L| is a configuration parameter) adjacent nodeIds fail
concurrently, eventual delivery is guaranteed Join, leave in O(log N) Maintains locality based on application-defined scalar proximity metric
Example Applications
SCRIBE:group communication/event notificationo Groups can be created and joined
Members of a group may multicast messages to all members of a group (delivered using best-effort)
Each group has a unique id, groupId (from a hash of the group name and the creators name)
o The node with nodeId numerically closest to groupId acts as rendezvous for the group
Group creation is handled by sending a CREATE message to the node with id groupId
Nodes wishing to join sends a JOIN message to this nodeo To send a message, a node sends a MULTICAST message to the rendezvous
In principle, the rendezvous might just then send messages to all joined nodes. (SCRIBE actually builds a multicast tree rooted in the rendezvous for optimization)
PAST: Archival storageo Each file inserted gets a 160 bit fileId (from a hash of file name, owner's public
key, and random salt)o Pastry routes the file to the k nodes that are numerically closest to the first 128
bits of the fileIdo Lookup ensures that the file is found as long as 1 of the k nodes are alive
SQUIRRELo co-operative web caching
SplitStreamo high-bandwidth content distribution
...
Routing Table
Routing Example
Pastry Routing Algorithm
Pastry Routing Algorithm - Analysis
Observation: Either 1), 2), or 3) must holdo For 3): leaf set must contain nodes numerically closer to the key with same
shared prefix as us (otherwise, we are the closest node)o - unless |L|/2 nodes in leaf set have failed... simultaneously
Terminationo 1) Directly terminates at chosen nodeo 2) Node routed to shares a longer prefix with keyo 3) Node routed to shares a prefix of same length but with numerically closer
key (Expected) performanceo 1) Destination one hop awayo 2) The set of possible nodes with a longer prefix match is reduced by 2^bo 3) Only one extra routing step is needed (with high probability)
Given accurate routing tables, the probability for 3) is the probability that a node with the given prefix does not exist and that the key is not covered by the leaf set
o => expected performance is O(log N)
Self-Organization - Node Arrival
New node, X, needs to know existing, nearby node, A, (can be achieved using, e.g., multicast on local network)
X asks a to route a "join" message with key equal to Xo Pastry routes this message to node Z with key numerically closest to Xo All nodes enroute to Z returns their state to X
X updates its state based on returned stateo neighborhood set = neighborhood set of Ao leaf set is based leaf set of Z (since Z has id closet to id of X)o Rows of routing table is initialized based on rows of routing tables of nodes
visited enroute to Z (since these share common prefixes with X) X calibrates routing table and neighborhood set based on data from the nodes
referenced therein X sends it state to all the nodes mentioned in its leaf set, routing table, and
neighborhood set O(log2^b(N)) messages exchanged
Self-Organization - Node Departure
Assumption: A node that can no longer be communicated with has failed Repair of leaf seto Contact the live node with the largest index on the side of the failed node and
get leaf set from that nodeo Returned leaf set will contain an appropriate one to inserto Contacting works unless |L|/2 nodes with adjacent nodeIds have failed
Repair of routing tableo Contact other node on the same row to check if this node has a replacement
node (the contacted node may have a replacement node on the same row of its routing table)
o If not, contact node on next row of routing table Repair of neighborhood seto Neighborhood set is normally not used in routing => contact periodically to
check for livenesso If a neighbor is not responding, check with other neighbors for close nodes
Locality
Routing performance is based on small number of routing hops - and "good" locality of routing with respect to underlying network
Scalar proximity metric (e.g., number of IP routing hops, geographical distance, or available bandwidth)o Applications are responsible for providing proximity metrics
Join protocol maintains closeness invariant
Handling Malicious Nodes?
Choose randomly between nodes satisfying the criteria of the routing protocol...
Experimental Results - Routing Performance
Experimental Results - Routing Distance
Experimental Results - Routing Distance
Experimental Results - Quality of Routing Tables
Summary
Pastry is a P2P content location and routing substrateo Structured overlay networko Usable for building various P2P application
Space and time requirements (expected) in O(log N), N = number of nodes in network Takes locality into account
Chord
Overview
One operationo IP address = lookup(key): Given a key, find node responsible for
that key Goals: Load balancing, decentralization, scalability, availability, flexible naming Performance and space usageo Lookup in O(log N)o Each node needs information about O(log N) other nodes
Example Applications
Cooperative File System (CFS)o Building a distributed hash table on top of Chord (DHash)o Storing blocks using DHash, lookup using Chord
Distributed Indiceso Derive keys from desired keywordso Let values be servers holding documents matching the desired keywords
Use of Consistent Hashing in Chord (1)
Keys are assigned to nodes with consistent hashing o Hash function balances loado Rebalancing (when node joins or leaves) requires moving only O(log 1/N)
Nodes and keys are assigned m-bit identifierso Using SHA-1 on nodes' IP addresses and on keyso m should be big enough to make collisions improbable
"Ring-based" assignment of keys to nodeso Identifiers are ordered on an identifier circle modulo 2^mo A key k is assigned to the first node n whose identifier is equal to or follows k
- n = successor(k) Chord improves on consistent hashing by only requiring knowledge about O(log N)
other nodes at each node
Use of Consistent Hashing in Chord (2)
Use of Consistent Hashing in Chord (3)
Designed to let nodes enter and leave network easilyo Node n leaves: all of n's assigned keys are assigned to successor(n)o Node n joins: keys k <= n assigned to successor(n) become assigned to no Compare "traditional hashing", e.g., h(x) = ax + b (mod p), in which p
(Each physical node runs a number of virtual nodes each with its own identifier to balance load)
Simple Key Location
(a) Simple key location can be implemented in time O(log N) and space O(1) (b) Example: Node 8 performs a lookup for key 54
Scalable Key Location (1)
Uses finger tables o n.finger[i] = successor(n + 2^(i-1)), 1 <= i <= m
Scalable Key Location (2)
If successor not found, search finger table to find n' whose ID most immediately precedes ido Rationale: this node will know the most about n' of all nodes in the finger table
Scalable Key Location (3)
Performance is O(log N) with high probabilityo Each node can forward a query at least halfway along the remaining distance
=> less than m steps to find nodeo After 2log N steps, the distance is max 2^m/2^(2log N) = 2^m/N^2 - and the
probability for two nodes to be in such an interval is 1/N, i.e., negligible Space required is O(log N) with high probabilityo As above: for i <= m - 2log N, the i'th finger of the node will be the node's
immediate successor with high probability
Self-organization - Node failures
Chord maintains successor lists to cope with node failureso Node leave could be viewed as a failureo If nodes leaves voluntarily, it may notify its successor and predecessor
Experimental Results - Path Length
Summary
Decentralized lookup of nodes responsible for storing keyso Based on distributed, consistent hashing
Performance and space in O(log N) for stable networks Simple; provable performance and correctness
Summary
Summary
"First generation" routing and location in P2P networkso Largely application-specifico Hard to analyse
"Second generation" routing and location in P2P networkso Based on structured network overlayso Typically expected O(log N) time and space requirements
General security concernso relevant to all distributed systems
Secure P2P systems and techniques
Security Basic security concerns (Lack of) Internet security Cryptography Closing remarks on security
Basic security concerns - all the things that can go wrong
Dangers of distributed systems
Trusto who can you trust?
Identity thefto pretending to be you (or someone you trust)
Privacyo preventing others listening in on the conversation
Censorship & attackso denying you the right to know
(Lack of) Internet security
The Internet
The Internet is vast and not safe at allo data packets going from machine to machine before they reach you
Many standards and protocols established back in safer dayso SMTP, NNTP, telnet, ...
Today there are plenty of sociopaths, who would delight in destroying your data or machineo see iloveyou, Code Red, SQL Slammer, SoBig.F, Swen, etc. etc.o not to mention industrial espionage etc.
Spammers, anyone?o it has been claimed that recent worms are behind DDoS attacks against anti-
spam sites...
Who can you trust?
Surely you can trust well-established Web sites? Several important open source ftp servers have been 'owned' over the yearso thus leaving black hats free to insert code of their own in the cvs trees...
This also happened for Microsoft last year (apparently without any ensuing nastiness)...
And of course numerous sites have been hacked for credit card numbers etc.
Email
Email remains (despite spammers) the most successful CSCW and file sharing application on the planet
The vast majority of email is not encryptedo neither in transit nor at source/destination
Standards for email encryption existo PGP (Pretty Good Privacyo S/MIME
These are generally somewhat cumbersome and are (therefore) not widely used
Email
Email headers can be easily spoofed faking the sender of an email is trivial One of the reasons behind the "success" of email wormso users naturally trust email received from friends, colleagues, and family...
Similar points can be raised for instant messaging
File systems
File systems are generally, by default, not encrypted Thus not funny at all to loose the company laptop PC... Without encryption your data is only as safe as the hard disk it resides on
Cryptography
Cryptography
Fact: Messages can be intercepted. But intercepted data is worthless, if the interceptor cannot read ito (the people involved are traditionally known as Alice, Bob, and Carol (the
latter usually trying to intercept and decrypt messages) Cryptography is very old (at least as old as the Roman Empire), and has been based on
a long number of techniqueso letter substitution or various permutations (e.g. ROT-13)o one time padso complex machines (e.g. Enigma)o etc.
Today cryptography is based on advanced, hard-to-solve mathematical problems Regardless of the method used, a key is used to signify how the plain text is
transformed into cipher text
Symmetric cryptography
The same key is used to encrypt and decrypt the message
Advantageso symmetric cryptography is fast
Disadvantageso the key must be securely exchanged between Alice and Bobo if the key is compromised, the entire communication is instantly readable
Asymmetric cryptography
Keys come in pairs:o a public key known to allo a private (or secret) key known only by the individual user
A message encrypted with the public key can be decrypted only by the private keyo So if Alice encrypts a message with Bob's public key, only Bob can decrypt it
with his private key A message encrypted with the private key can be decrypted only by the public keyo So if Alice encrypts a message with her private key, all can verify (using
Alice's public key) that Alice is the author
Asymmetric cryptography
Advantageso as the private key is never shared, the system is secureo the system can also be used to authenticate (or "digitally sign") messages
Disadvantageso only as secure as the private key...o much slower than symmetric cryptography
Establishing trust
How does Alice know Bob is really Bob, and not Carol claiming to be Bob? Asymmetric cryptography often relies on CAs - Certification Authorities o these, using out-of-band methods, establish the correct identity of Bob, and
assigns a (signed) certificate to Bobo Alice can then verify that some CA has vouchsafed Bob, and if she trusts the
CA, she can trust Bob A problem with these certificates is the cost... A less centralised approach is taken by PGP (Pretty Good Privacy), where Bob relies
on associates to confirm his identityo if Alice knows (and trusts) any of these associates, she can trust Bob's identity
Symmetric/asymmetric cryptography
Not an either/or situation - often used in combination Asymmetric cryptography is used for the initial communication to establish identity
and (securely) exchange a randomly generated symmetric key used for the rest of the session
This is the method used by SSL (Secure Socket Layer), which handles e.g. https o the Web server provides the Web browser with its CA signed certificate (this
makes man-in-the-middle attacks harder)
o the Web browser generates a random key, encrypts it with the Web server's public key, and returns it to the Web server
o as only the Web server can decrypt the key, the Web server and Web browser can now initiate a symmetric encrypted session
Secure hashes
Secure (or cryptographic) hashes are used to verify the integrity of a message Most common are MD5 (128 bit) and SHA-1 (160 bit) It is computationally infeasible to create two different messages with identical secure
hash codes (it requires brute force and 2^128 or 2^160 are big) Thus, if the (MD5/SHA-1) hash code of a message is known, we can check whether
the message has been modified by computing the hash code of the message Given the quality of the secure hash, it is just as good to encrypt the (compact) hash
code with your private key for authentication as encrypting the entire message
Closing remarks on security
Security - a purely technical problem?
Security can be addressed through a number of technical means However, these valiant efforts are all for naughto in the face of inexperience and general cluelessness
The most successful hackers have operated, not through absurd Hollywood computer guru excellence, but through social engineering o hacking is considerably easier if you can get people to tell you their password
Script-kiddies usually operate through kits exploiting well-published security holeso leaving their victims with a valuable lesson if nothing else
Most worms spread because people apparently just can't help clicking on attachments...o where is the problem? With Outlook or the users?o "Machine destroying email" used to be an Internet urban legend... but no more
(this is progress?)
Security in P2P P2P systems previously seen... Groove Various techniques for anonymity
P2P systems previously seen...
Gnutella/Napster/KaZaA/... - the vast majority of file sharing tools
No security to speak of No user authenticationo in some cases for quite obvious reasons...o but users are not anonymous...
o eavesdropping is trivial on most file sharing networks, as a number of people have discovered to their cost
No content integrity checkingo the retrieved file is not what it seems...
Freenet
No authentication (to real world identities) as such, but can authenticate pseudonyms, allowing e.g. only the original author to update a document
Each resource in a Freenet node space is encrypted and integrity checked with SHA-1 hash
Network traffic not encrypted, but as the resources are encrypted, this is less of a problem
Routing is performed in a way to foil surveillance
JXTA
Per default:o authentication at the cliento not on-the-wire encryptiono not strong checking of group membership
Howevero secure pipes can be usedo Arbitrary (as in "write your own") group membership checking can done
Groove
Security concerns for the corporate world - or this place for that matter
Most are placed behind a firewallo excellent protection for most attackso unless black hats somehow get insideo can make it quite difficult to collaborate with people on the other side of the
firewall As email pass through the firewall, it is a popular choice for collaboration and sharingo but as noted before email is usually not safeo mail filters check for spam, worms and trojans, but cannot be completely
updated at all times
Groove - P2P for the corporation
Aims to provide a secure shared space between coworkers Encryption is the default and quite transparent to the usero thus avoiding the hassle of PGP & S/MIME in email
o (according to their Web site, they now also integrate with Microsoft Office)
Identity in Groove - a system with many, many keys
A user in Groove has an account (possibly on a number of devices) witho A pass phrase to login to the client and to generate theo master symmetric key
The user can have a number of identities, each witho an asymmetric key pair for signing and verificationo an asymmetric key pair for encryptiono a digital fingerprinto a Diffie-Hellman key pair per member per shared space
Shared spaces - mutual trusting
A mutual trusting shared space haso a symmetric key used by all members to verify/authenticate messageso a symmetric key used by all members to encrypt messages
All space data is stored on all clients using a symmetric storage key per member per shared space (encrypted with the user's master key)
There is not guarantee for identity - users could in principle spoof identities when posting to the group
Shared spaces - mutual trusting messages
A delta (a chunk of data) is sent from Bob to the group containing:o a headero a body encrypted using the group's symmetric encryption keyo a digest (SHA-1) of header and body authenticated using the group's
symmetric authentication key Upon receiving this delta, Alice cano verify the integrity of the delta (and thus ensuring that the delta was sent by a
group member)o decrypt the deltao store the delta locally using her own encryption
Shared spaces - mutual suspicious
Mutual suspicious shared spaces are used in situation where the identity of the individual user must be ensured
Each member has a Diffie-Hellman key pair per other member D-H allows Bob to compute a shared symmetric key with Alice using Bob's private D-
H key and Alice's public D-H key (and vice versa) By using this symmetric encryption communication between Alice and Bob is secured
Shared spaces - mutual suspicious messages
A delta is sent from Bob to the group containing:o a headero a body encrypted using the group's symmetric encryption key
o digests (SHA-1) of header and body authenticated using each D-H derived key pair, including Bob/Bob
Upon retrieval, Alice can then verify that the delta was indeed sent by Bob
Initiating membership of a shared space
Bob is chair and sends Alice an invitation to a shared spaceo cryptographic context (parameters for D-H)o Bob's public keys
Alice then replies witho a one-time key encrypted in Bob's public keyo Alice's D-H public key
Bob can theno decrypt the one-time key, use it to send an encrypted message only Alice can
respond to and thus verifying that she intends to join the spaceo send the group keys to Aliceo send Alice's D-H public key to the other members of the space
Leaving a shared space
If Carol leaves the shared space, the group key is recomputed, so that she no longer can access the shared space's material
Group keys are not recomputed, when people join the space, as they should have access to the history of the group
Dependency on keys are stored, so that other members (who perhaps were off-line) can still access data
Communication in Groove
Usually peers communicate using point-to-point connections Peers are not always online or immediately available (e.g. they could be behind a
firewall) Relays are used for tunnelling through firewalls, handle fan-out of messages, and do
storing and forwarding
Various techniques for anonymity
Mix networks - defeating traffic analysis
Mix networks are used to ensure that a sender and receiver cannot both be known A mix network consists of a number of known mixes - routers with asymmetric key
pairs A sender chooses a path through the mix network (m_1, ..., m_n), and encrypts the
message (with final destination) with m_n's public key, encrypts this message (with m_(n-1)->m_n) with m_(n-1)'s public key and so on
The message is then sent to m_1, who decrypts the message using its private key, and sends it to the next mix, who repeats the process
Only m_1 knows the sender and only m_n knows the receiver and neither knows the route of the message (not even their own position on the path)
Crowds - defeating Web browsing tracking
A number of members participate in a crowd, and they are known to each other If a member, Bob, wishes to retrieve a Web page, Bob sends a request for the URL to
a random member, Carol (using symmetric encryption). Carol can then choose to retrieve the Web page or forward the request to another crowd member, Alice, and so on. Eventually a member chooses to retrieve the Web page, and the Web page is returned along the request's path
Summary and pointers
A number of proven technologies exists, which can enable safe computing The success of these technologies hinges on ease-of-use, as they are (in themselves)
quite complicated There are two directions in the areao ensuring anonymity and privacy on the Interneto ensuring identity and integrity in a working environment
Next time:o Accountabilityo Reputation
can get complicated if users are anonymous...
Project description time!
You must formulate a P2P project for your group You will present the result of this project to the rest of us during the first half of
December (and deliver a report about it to Klaus and I by the middle of January)
Project topics
Anything goes! As long aso it is P2P in natureo it is sufficiently ambitious (neither too much nor too little)
You cano develop new routing and searching algorithmso create a neato P2P applicationo extend JXTA in some directiono create a P2P framework The Way It Ought Be Done And Not The Way JXTA
Did Ito etc., etc.
Only one requirement prior to starting:o send an URL to a short project description (no more than a page) to Klaus and
P2P Security - Reputation and Credibility1.007/October/2003Niels Olof BouvinAarhus Universitet
Recapture from last time:
Cryptography enables (to a high degree) secure communication With asymmetric cryptography (public/private keys) messages can be free from
eavesdropping and tampering Thus, we have the basics for building a secure infrastructure This however still leaves the question: Who can you trust?
Reputation and Credibility Introduction Reputation and moderation systems
Introduction
Who can you trust?
Trust is inherent in most of our social interactions Generally we have a pretty good idea whom to trust and whom not to trust People (and companies) earn and loose our trust over time If Alice trusts Bob, and Bob trusts Daniel, Alice is more likely to trust Danielo and if Bob does not trust Carol, Alice is unlikely to trust Carol
Trust is hard to earn - easy to looseo a powerful incentive to be nice
Trust in a computer setting
In real life, we have a number of mechanisms for handling trust, and we are usually dealing with people we know
On the Internet, these mechanisms break downo "on the Internet, no one knows you're a dog"
You can establish trust across the Interneto and the techniques outlined last time can help you ensure that you are dealing
with the person you expect
Some types of attack on the Internet
Pseudospoofingo using a number of aliases to influence a situation (e.g. voting)
o on-line identities are not tied to real world identities - people cannot be prevented from using various aliases
Denial of Serviceo request a service so much it becomes unavailableo can be handled (to a degree) through caching and micropayment
Floodingo filling a system with garbage drowning out the valid contento various defences: micropayment or dropping unpopular content
Reputation and moderation systems
Usenet
People on Usenet earn their reputations by their postings Some are respected as authorities - others are reviled as kooks, flamers, spammers,
and trolls Especially trolls will often change their identities as they invariantly are kill filed by
their unwilling audienceo uncovering these new identities is a pastime of some newsgroup residents - but
they are of course always one step behind the troll
Usenet - anti-{kook,flamer,troll} weaponry
Most news readers have 'kill file' functionalityo the user adds an unwanted poster to his/her kill file and the unwanted one is
then automatically filtered by the news readero disadvantage: binary, requires user intervention. Per user.
Some news readers (Gnus) use adaptive scoring o postings and users are awarded scores depending on the reader's actionso advantage: much more flexibleo still not shared - does not work for newsgroups only visited seldom or for the
first time Apart from adaptive scoring, scoring can be explicitly designated, so that specific
subjects or authors are scored up or down. Scoring can depend on arbitrary computations on the postingso disadvantage: complex
Usenet - moderation
Some newsgroups become too cluttered by spam or flame wars Either the newsgroup is left to deteriorate (with the regulars moving elsewhere) or the
newsgroup becomes moderated A number of trusted regulars are elected as moderators by the newsgroup A posting must hence forward be approved by a moderator, before it appears on the
newsgroup Problems:o moderation is hard worko moderators can misuse their powero moderation of newsgroup can be bypassed
Usenet - NoCeM and GroupLens
Moderators do a great job, buto not all newsgroups are moderatedo you may not agree with all the moderators' decisions
NoCeMo opt-in moderation - if you trust a moderator, you can subscribe to his/her/its
decisions GroupLenso moderation done by people you agree witho you assign scores to individual postings, and thus build a profileo the moderation done by people with similar profiles are then used to score the
postings they see
Slashdot
Purposeo moderate postings on the discussion boards by scoring interesting posts up and
scoring uninteresting/inflammatory posts down Moderation were traditionally handled by a group of trusted moderatorso problem: way too many posts for the moderators to handleo misuse of moderator power (who watches the watchers?)
Slashdot - meta-moderation
All (registered) users in good standing occasionally gets (limited) moderation power Moderators cannot themselves participate in the discussions they moderate The moderations are meta-moderated by all registered users Bad moderators will not moderate again (or very rarely)
Amazon
Purpose:o the recommendation of books, you're likely to like (and buy)
Based on the buying habits of the Amazon customers You're (presumed) likely to buy books bought by people, who buy the books you buy This works surprisingly well
eBay
How can you trust a stranger with your money? Sellers and buyers mutually rate each other after each transaction So, you don't buy stuff from sellers with bad reputations Problem:o you can build up a good reputation over many smaller transactions and then
cheat people on high price deals
Advogato
System to establish the reputation of open source programmers
o users assign trust to each other - their own reputation determines how much their trust is worth to others
o pseudospoofing attacks become difficult as new users have zero trust to give to others
Micropayment - making cheating unprofitable
DoS attacks becomes infeasible if attackers must pay for the used resources Cash paymento using a number of sophisticated cryptographic methodso very much an ongoing research topic
Proof of Work (POW)o performing some non-trivial work to gain access to a resourceo typically variation of cryptographic hash collision calculation
Summary
Existing reputation systems provides users a modicum of quality of service However, they are not tamper proof and may be misused Even if the moderators have integrity, you may not agree with them Systems must have checks and balances in order to prevent abuse
P2P systems Reputation and security in P2P systems Damiani et al. Gupta et al
Reputation and security in P2P systems
Security?
File sharing networks such as Gnutella do not have much protection against malicious users or dangerous content
Some systems are more or less censorship proof (such as Freenet), but what about bad content and users?
Or flooding and DoS? A central authority is not available in the fully distributed systems Most users are anonymous Who can you trust?
Damiani et al.
Distributed reputation in Gnutella using XRep
Basic idea: collect other peers' votes on the reputation of resources and other peers Dangers:o Malicious users may distribute dangerous contento Other users may (unwittingly) distribute dangerous content
o Malicious users may lie about themselves or others
Gnutella revisited - how does it work again?
A Gnutella peer starts out with a number of peers from "somewhere" It can query these peers for the peers they know, and thus build a list of potential peers
to contact Queries are broadcast to all known peers who in turn call all their peers and so on Queries has a unique ID (128 bit) and a TTL (time to live). This ensures that peers do
not retransmit the same query twice and that queries eventually die out Peers remembers received and transmitted queries and whence they came If a query match is found, the response (containing the query and the host address) is
returned following the query route back to the originator The originator will (presumably) received a number of hits and then contact a host
directly for downloading
Extensions to the Gnutella system
Peers are known as "servents" (server/clients) All servents have (public,private) keys All servents have a unique ID based on a hash of their public key All resources have a digest - a cryptographic hasho similar to Freenet...
All servents have resource repositories, consisting ofo (resource_id, value)o value: + or -
All servents have servent repositories, consisting ofo (servent_id, num_plus, num_minus)
Resource Searching in XRep
Queries are broadcast in normal fashion Query replies additionally containo servent_ido digests for the matching resources
Resource searching
Resource selection and vote polling
The user decides on a resource The servent queries peers about the resource and servents offering it. The vote polling query consists ofo the servent's generated poll public keyo the resource digesto the servent_id for the supplying servent
Other servents check their repositories and return their knowledge - encrypted with the public key
Resource selection and vote polling
Vote evaluation
Votes are decrypted To prevent cheating by pseudospoofing IPs are collapsed and random voters queried
to confirm their vote
Vote evaluation
Best servent check
Based on the vote, the best servent is selected
To prevent overloading the best servent, it is contacted for the resource digest (thus confirming the existence and identity of the resource)
Best servent check
Resource downloading
A servent is decided upon, and downloading commences After download, the resource is checked against the digest and its repositories are
updated
Resource downloading
Summary
XRep makes it more difficult to pseudospoof by requiring different IPs (this can of course be circumvented)
Again we see the usefulness of the cryptographic hash Dangerous content gets a bad score in this systemo making sure we don't download it - even from good servents
Adds even more traffic to Gnutella...
Gupta et al
Reputation relying on a network of reputation agents
Basic concept:o peers calculates scores after each transactiono these scores are collected by Reputation Computation Agents (RCA)
o Capability Processing power Bandwidth Storage capacity Memory
Participation is voluntary All peers, including RCA, have (public,private) keys
Overall approach
Debit-Credit Reputation Computation
Credit based ono how often the peer responds to queries (QRC)o how much the peer uploads compared to its bandwidth (DC)o how much the peer shares (SC)
Debit based ono how much the peer downloads (DD)
Credit Only Reputation Computation
No debits, but scores deteriorates over time
RCA in action
Peers will regularly contact the RCA to update their score A peer sends (encrypted) Proofs of Processing consisting ofo (requester_id, query_keywords, query_size, time_stamp, self_id)
The RCA returns a new (encrypted) score to the peer The RCA maintains a history of PPs to ensure that work is not credited twice Debits are stored until a credit PP comes in (to prevent peers from throwing debits
away)
Downloading - DCRC
The requester and sender exchange receipts for the download:o the receipt is signed before transfer
Downloading - CORC
Receipt sent after download
Summary
Avoids overloading (already busy) Gnutella protocol At the cost of introducing a whole new layer (assumed not malicious!) Defence against a group of malicious peers?o malicious peers could just claim to exchange large fileso this can be handled through Advogato like techniques
Conclusions
Reputation and trust on the Internet is not easy A number of good techniques exist - often based on a central authorityo but can you trust the moderators?
P2P makes everything worseo no central authority
Trust becomes an issue of trusting well-behaving peers and their judgemento pretty much like real life
Created by JackSVG
P2P Searching and Metadata1.011/November/2003Niels Olof BouvinAarhus Universitet
Overview
How can we efficiently (or just reasonably) search over (unstructured) P2P networks? P2P networks are generally far too unstructured and transient to be crawled and
indexed properlyo most would be wrong or unavailable by the time you were done...
Searching in P2P networks Search in well-known P2P networks Alternatives to flooding YouServ/YouSearch JXTASearch Meta data P2P
Search in well-known P2P networks
Napster
Centralised directory service Very efficient - but requires big servers to scale
Completely decentralised searching Breadth First Search - Search by floodingo inefficient (in term of generated traffic), not scalableo but: handles transient networks wello if there is an answer out there, it will most likely be found
Freenet
Depth First Search - Walker - "Search by hints"o using resource GUID as guides to select the next peer to queryo replication (of resources and resource "directions") along request pathso this creates, over time, a fairly well structured distribution of documents
Freenet seems to assume relatively stable peers
Chord & Tapestry
Elegant designs - routing in O(log N) (!) Howevero joining also in O(log N) (used for building routing tables)
Alternatives to flooding
The structure of P2P networks - unstructured structures?
If searches over the P2P overlay network are to be efficient, we need to know something about the structure of the network
Centralized networks - dull as dishwater (Napster) Fiercely well-structured with optimal topologies (Chord, Tapestry, ...) Other are semi-structured (Freenet, KaZaA, ...) Completely unstructured (Gnutella, ...)
Gnutella structure - (Parts of) the Gnutella network has been charted from time to time
Gnutella structure - node degree/#links
Power-Law structure - node degree/#links
Random structure - node degree/#links
Grid structure - node degree/#links
TTL considered harmful
Naive Gnutella searching consists of spreading queries by flooding until TTL (Time To Live) is exhausted
This is not efficiento if a hit is found, the flooding continues regardless everywhere elseo if a hit is not found, a tremendous amount of messages have been sent for no
good purposeo high TTL generates a lot of traffico low TTL may not locate the desired resource
Measuring the consequences of TTL - Successful search/TTL
Measuring the consequences of TTL - avg #msgs per node/TTL
Measuring the consequences of TTL - %duplicate msgs/TTL
Measuring the consequences of TTL - #Nodes visited/TTL
Alternatives to TTL flooding - Expanding ring
Start with small values of TTL, and increase TTL until sufficient number of hits are found
Expanding ring - alternatives to TTL flooding
Advantageso ultimately as successful as ordinary floodingo if a resource is nearby, it is located at a lower overall cost
Disadvantageso if the resource is not found, more messages are generated than ordinary
flooding!o successive searches mean longer delays
Random walker
Depth-first searcho a query transverses the network randomly until a match is found
k random walkers
k walkers decrease delay
Random walkers
Advantageo much more efficient in term of overall traffic
Disadvantageo longer delays
Variationso walker terminate after TTLo walker checks periodically source for successo nodes maintain state and do not send the same query to the same neighbour
twice
Results
Adaptive probabilistic walkers
The nodes and walkers so far have been kind of stupido or rather not employing all available knowledge
What if nodes made informed choices when sending walkers on their merry way? Danger: It takes extra work to maintain knowledge!
Adaptive probabilistic walkers - algorithm
All nodes maintain indices foro each resource (forward) requested per neighbouro the value reflects the probability of the neighbour to be chosen for a future
request Queries are performed with k walkers Each node forwards walkers based on the probability distribution in its indexes Walkers remember visited nodes. Duplicates are discarded. Walkers terminate on
Swapping-APS (s-APS)o be pessimistic for unpopular resources and optimistic for popular stuff
Weighted-APSo adjust probabilities inverse proportional with distanceo choose close resources over remote resourceso adjusting scoring algorithm
No increased overhead
Results
Results
Resilient to transienceo adapts to new peers and their resourceso new peers are included - it is, after all, probabilistico new peers may not know a lot, but their neighbours will
YouServ/YouSearch
YouServ
A (rather elegant) distributed approach to handling multitudes of small Web servers within an organisation
Rather than distributing files in email, data is kept close to their originator Transience of user machines is handled through transparent replication and firewall
tunnelling Very modest hardware requirements (1500 users with a couple of standard PCs as
central coordinators)
YouServ - screen shots
YouServ - architecture
Searching?
Standard Web techniques not applicable Crawlingo slowo never up to dateo can return dead linkso requires some big central server
YouSearch
All heavy lifting done at client:o continual indexing of local documentso handling of queries to local documentso always fresh indexes - no dead links
To facilitate fast lookups, summaries are kept at central 'registrar'
User experience - search interface
User experience - search results
Architecture - indexing
Nodes index their own document A summariser computes a bloom filter over the index and sends it to the central
registraro bloom filters: bit vectors created with hashes over termso if H('term') yields k, the k'th bit is set in the summary
Architecture
Architecture - searching
The central registrar can determine which peers might have documents matching the query
The set of matching peers is returned to the originator, who then queries the peers "Dead peers tell no tales" Results are presented to the user as they come ino sorted according to each peers' ranking
Architecture - searching
Niceties
Queries are cached by querying peer who informs the registraro cached queries have a TTL
Work groups as contexto search context (only stuff within this work groupo recommendation of search results to other work group members
Results - peer lifetimes
Results - how fast is it?
Results - effect of caching
JXTASearch
JXTASearch
A JXTA project to provide search functionality across a P2P network Very general architecture - searching is handled by specialised peers (perhaps only
proxies for "real" search engines). The responsibility of the architecture is mainly hooking consumers and producers up
and routing between them
JXTASearch
JXTASearch
Query Routing Protocol
JXTASearch Provider Service: Provides an interface to a search mechanism, such as an search engine
JXTASearch Consumer Services: Generates the query, sends it to the hub, and formats the returned results
JXTASearch Registration Service: Hooks provides up to the hub JXTASearch Hub Service: Accepts queries, routes queries to appropriate provides,
returns results
JXTASearch
Meta data P2P
Meta data
Data about data The building block behind the Semantic Web Vision: Facilitate machine reasoning about the information available based on the
well-structured (RDF/XML) meta-data General problem: Meta data is not well-structured or reliable
Not generally applicable, men usable within domains
Edutella and Metadata P2P
JXTA based project trying to to scope, specify, architect and implement an RDF-based metadata infrastructure for JXTA
Used for supporting the sharing of E-Learning resources among universities and other educational institutions
There are quite a few metadata standards for E-Learning Uses in one implementation JXTASearch
General metadata P2P
In order to support rich searches over complex data, metadata must be employed But: All data cannot be classified with the same ontology (classification schema) Thus, a metadata aware P2P search mechanism must be able to cope with arbitrary
metadata schemas And preferably quite efficient!
Architecture
A peer/super-peer architecture Super-peerso provides routing to other super-peerso handle all the fiddling with metadata schemaso are arranged in a hypercube. This ensures routing in O(log N)
Peerso are consumers or producers of contento all according to metadata schemas
Routing
Super-peer/peer routing index (SP/P RI)o contains information of the kind of data understood or held by the peero ensures that only appropriate peers are queried or given appropriate results
Super-peer/super-peer routing index (SP/SP RI)o used for routing between super-peerso a summary of the SP/P RIs
Miscellaneous
Clusteringo the system supports clustering, so that related peers and super-peers are
brought together Metadata translationso To handle differences between various metadata schemas, translations between
schemas is supported Problemo who exactly will be writing queries like this?o ensuring consistent metadata across different entities is very optimistic
Created by JackSVG
P2P Storage1.025/November/2003Klaus Marius HansenUniversity of Aarhus
Overview
Storage (and retrieval) an original motivation for P2P systems (viz., file sharing)o Load balancing (share resources)
Fault toleranceResource utilization
How can P2P techniques be used to provide decentralized, self-organizing, scalable storage?o Two proposals built on top of Pastry and Chord
Material
(Rowstron & Druschel 2001)o Rowstron, A. & Druschel, P. (2001), Storage management and caching in
PAST, a large-scale, persistent peer-to-peer storage utility, in Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP '01), pp. 188-201.
o PAST: P2P global, archival storage based on Pastry (Dabek, Kaashoek, Karger, Morris & Stoica 2001)o Dabek, F., Kaashoek, M.F., Karger, D., Morris, R. & Stoica, I. (2001), Wide-
area cooperative storage with CFS , in Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP '01), pp. 202-215.
o CFS: P2P block file storage based on Chord
P2P Storage Looking Back... PAST The Cooperative File System (CFS) Summary
Looking Back...
Napster and Gnutella
Use local file system of nodes Napstero Index files centrallyo Allow nodes to search for files through index server
o Download in a peer-to-peer fashiono Single point of failure...
Gnutellao No central index - only local knowledge of storageo Search through flooding/walkingo Download in a peer-to-peer fashiono Bad scalability
Yes, this can be repaired in a number of ways :-) Basically just transient file sharing supported
Freenet
Completely decentralized Anonymous storage, clients, and publishers Replication through routing Probabilistic storage
PAST
Wants to
Exploit multitude and diversity of Internet nodes to achieve strong persistence and high availability
Create global storage utility for backup, mirroring, ... Share storage and bandwidth of a group of nodes - larger than capacity of any
individual node
The PAST System
Large-scale P2P persistent storage utilityo Strong persistence (resilient to failure)o High availabilityo Scalabilityo Security
Self-organizing, Internet-based structured overlay of nodes cooperateo Route file querieso Store replicas of fileo Cache popular files
Based on Pastry
Pastry Review
Effective, distributed object location and routing substrate for P2P overlay networks Each node has a unique identifier (nodeId) Given a key and a message, Pastry routes the message to the node with nodeId
numerically closest to the key ID Takes into account network locality based on an application-defined scalar proximity
metric
Pastry Routing Table
Pastry Routing Example
PAST Design
Any node running the PAST system may participate in the PAST networko Nodes minimally acts as access points for users, but may also contribute
storage and routing capabilities to the networko Nodes have 128 bit quasi-random IDs (e.g., lower 128 bit of SHA-1 on IP
address of node) -> nodes with adjacent IDs diverseo File publishers have public/private cryptographic keys
Inserts replicas of file on the k nodes whose IDs are numerically closest to fileId (k <= |L|)
o file = Lookup(fileId) Retrieve file designated by fileId from if it exists and one of the k
replica hosts are reachable The file is usually retrieved from the "closest" (in terms of a proximetry
metric) of the k nodeso Reclaim(fileId, owner-credentials)
Weak delete: lookup of fileId is no longer guaranteed to return a result
PAST: Insert Implementation
fileId = Insert(name, owner-credentials, k, file) fileId is calculated (SHA-1 of file name + public key + random number ("salt")) Storage required deducted against a client quota File certificate created and signed with private keyo Contains fileId, SHA-1 of file content, replication factor k, the random salt,
various metadata File certificate + file is then routed to the fileId destinationo Destination verifies certificate, forwards to k-1 closest nodeso Destination returns store receipt if all accepts
PAST: Lookup Implementation
file = Lookup(fileId) Given a requested fileId, a lookup request is routed towards a node with ID closest to
fileId Any node storing a replica may respond with with file and file certificate Since k numerically adjacent nodes store replicas and Pastry routes towards local
nodes, a node close in proximetry metric is likely to reply
PAST: Reclaim Implementation
Reclaim(fileId, owner-credentials) Analogous to insert, but with a "reclaim certificate" verifying that the original
publisher reclaims the file A reclaim receipt is received, used to reclaim storage quota
Storage Management
We want aggregrate size of stored files to be close to aggregate capacity in a PAST network, before insert requests are rejectedo Should be done in a decentralized way...
Two ways of ensuring thiso Replica diversiono File diversion
Replica Diversion
Balances free storage space among nodes in a leaf set If a node cannot store a replica locally, it asks a node in its leaf set if it cano Protocol must handle failure of leaf nodes then
Acceptance a replica at a node for storage is subject to policieso File size divided by available size should be lower than a certain threshold
(leave room for small files)o Threshold lower for nodes containing diverted replicas (leave most space for
primary replicas)
File Diversion
If one of k nodes with nodeId closest to fileId declines (primary and diverted) to store a replica, the file needs to be diverted
Inserting node generates a new fileId (using a new random salt) and tries again... Try three times, if all fails reject insertion
Caching
Goals of cache managemento Minimize access latency (here routing distance)o Maximize throughputo Balance query load in system
The k replicas ensures availability, but also gives some load balancing and latency reduction because of locality properties of Pastry
A file is cached in PAST at a node traversed in lookup or insert operations if the file size is less than a fraction of the node's remaining cache size
Caching files are evicted as needed - expiry not needed since files are immutable
PAST Evaluation - Experimental Setup
Prototype implementation of PAST in Javao Network emulation environmento All nodes run in same Java VM
Workload data from traces of file usageo Eight Web proxy logs (1,863,055 entries, 18.7 GBytes)o Workstation file system (2,027,908 files, 166.6 GBytes)o "Problematic to get data of real P2P usage"
2250 PAST nodes, k = 5, b = 4 Different normal distributions of storage capacity of nodes used
PAST: Storage Management is Needed
Experiment without replica diversion and file diversion (using d1 and Web trace)o Primary replica threshold = 1, diversion replica threshold = 0o Insertion rejection on first file insertion failure
File request characteristics based on web logso 775 unique clients mapped to PAST nodes
PAST: Summary
Based on Pastry P2P routing and location Insertion and replication of files High storage utilization and load balancing through storage management and caching
The Cooperative File System (CFS)
CFS Goals
Distributed, cooperative, read-only storage and serving of files based on blocks o Fault toleranceo Load balanceo Tap into unused resources
Challenges for a P2P architecture for thiso Decentralizationo Unmanaged participantso Frequent joins and leaves
Support multiple file systems in single CFS system with millions of servers...
CFS Design (1)
Two types of CFS nodes and three layerso CFS Client
FS: Uses DHash layer to retrive blocks, interprets blocks as files DHash: Uses Chord layer to locate CFS Server holding desired blocks Has public/private keys for signing file publishing
o CFS Server DHash: Storing blocks, replicating blocks, caching Chord: Looking up blocks, checking for cached copies
CFS Design (2)
Blocks (of size ~ 10 KB) interpreted similar to blocks in a Unix file system (with block IDs instead of disk addresses)
Publishers insert file systems o Each block is inserted into CFS using a hash on the block's contents as IDo Root block is signed using private key, public key as ID
File systems may be updated by publisher (by signing a new root block with same private key)
Data is stored for a finite period of timeo Extensions may be asked foro No explicit delete operation - assumes lots of storage
Chord Review
Nodes have m-bit IDs on an "identifier ring" One operationo IP address = lookup(key)o Given a key ID, find the successor node, i.e., node whose ID most closely
follows the key ID on the identifier ring
Simple Key Location
Simple key location can be implemented in time O(log N) and space O(1) Example: Node 8 performs a lookup for key 54 Each node maintains r successors in a successor list for fault tolerance purposes
Scalable Key Location (1)
Uses finger tables o n.finger[i] = successor(n + 2^(i-1)), 1 <= i <= m
Scalable Key Location (2)
If successor not found, search finger table to find n' whose ID most immediately precedes ido Rationale: this node will know the most about n' of all nodes in the finger table
Chord Extensions
Locality awareness in lookupo Reduce lookup latency by preferably contacting nodes that are close by in
underlying networko Chooses preceding node in algorithm based on calculated average RPC latency
and guesses on remaining number of routing hops Node ID authenticationo What if an attacker claims a node ID just after an inserted block ID?o A node ID is a SHA-1 hash on the nodes IP address concatenated with a virtual
node index Hard to choose own ID
o Joining nodes are checked When a new node is joined to a finger table, its ID is checked with the
claimed IP address (by sending a random "nonce" that should be included in reply from IP)
DHash
Stores and retrieves uniquely identified blocks Handles distribution, replication, and caching of blocks Uses Chord to locate blocks
Replication in DHash
Blocks are replicated to k CFS servers immediately after the blocks successor on ID ring (k <= r)
The k CFS servers are likely to be diverse in location DHash "get" operation uses replicas to choose server with lowest reported latency to
download from
Caching in DHash
Each DHash layer in nodes sets storage aside for caching blocks to help avoiding overloading CFS servers with popular blocks
Blocks are cached along lookup routeo Lookups takes shorter and shorter hops to get to target -> lookups from
different clients will likely to visit same nodes late in lookup o Least-Recently-Used (LRU) replacement of blocks in caches is used
Cached root blocks may become inconsistent since their ID is based on public key rather than on content hash
Load Balancing in DHash
Blocks are spread evenly in ID space Multiple virtual servers may be created on one physical nodeo Virtual server on same physical node may look at each other location
information
DHash Quotas
How to ensure Denial-of-Service attack by injecting large amounts of data?
Reliable identification of publishers would require certificate authority (as with smartcards in PAST)
CFS assigns a fixed storage quota per IP addresso IP addresses are checked upon insert using nonces
CFS Evaluation
Experiment on CFS performance on real hosts on the Interneto Real-world client-perceived performanceo 12 machines scattered over the Internet
Simulated servers on a single machineo Robustness, scalability
Real-Life: CFS vs TCP
Speeds comparable, less variation in download speed
Simulation: Load Balancing
Server storage close to 0.016 for 64 servers (x 6 virtual) and 10,000 blocks
Simulation: Caching
CFS: Summary
Based on Chord location in P2P overlay networks Implements a decentralized, distributed, read-only file system Scalable and fault-tolerant
Summary
Summary
File storage (or file sharing) one of the original drivers for P2P systems P2P routing and location substrates may be used to implement (file) storageo Additional requirements towards, e.g., load balancing and caching
PAST: Archival storage based on Pastry CFS: Read-only file system based on Chord
Created by JackSVG
Peer-to-Peer Networking (P2P) and Mobile DevicesNiels Olof BouvinUniversity of Aarhus2003/Sep/18Introduction to Peer-to-Peer networking, Mobile Ad-hoc Networking, JXTA basics, JXME
Topics
Introduction to P2P Computing Examples of P2P systems Developing P2P Applications in JXTA P2P for Mobile Devices
Introduction to P2P Computing What is Peer-to-Peer Computing?
What is Peer-to-Peer Computing?
What are P2P Systems?
Distributed systems in which nodes are symmetricalo "a serverless networking technology that allows several network devices to
share resources and communicate directly with each another "o "deployable in an ad-hoc fashion, without requiring centralized management or
control" Distributed systems in which nodes have variable connectivity and give "edge nodes"
autonomy
A Brief History of P2P Computing
1969-1995: The original peer-to-peer Interneto Usenet: based on Unix-to-Unix-CoPy (UUCP) originally, decentralized model
of control designed to utilise off-hours bandwidth
o DNS: hosts are clients and servers, caches replies 1995-2001: The Internet explosion (and implosion)o Movement away from peer-to-peer to client-server modelso Web downloads, firewalls, ADSL, NAT, ...
2001-...: New wave of peer-to-peer(?)o separating authoring from publishingo return to old Internet
Napster - The prototypical hybrid peer-to-peer system
Gnutella - The prototypical "pure" peer-to-peer system
o Development-time qualities Modifiability Portability Reusability Integrability Testability
Differences in runtime qualities are most discernible
Qualities (1)
Performanceo The time it takes for a system to react to a stimuluso Pro: Data and computation may be close to peers, high degree of distributiono Contra: Replicated, distributed state and computation; complex architectures
Scalabilityo The ability of a system to support an increasing useo Pro: Network, storage, computation of peers may be leveragedo Contra: Routing, locating, synchronizing may not scale; fat clients needed
Qualities (2)
Securityo The degree to which a system can withstand attackso Pro: Robustness against Denial of Service attacks; anonymityo Contra: Complex, decentralized security architecture
Availabilityo The part of the deployment period during which a system can deliver the
services it implementso Pro: No single point of failure/robustness; system may be self-configuring,
replicated, autonomouso Contra: Ensuring consistent availability; having knowledge of network state
Examples of P2P systems P2P Communication P2P Collaboration P2P for Distributed Computation P2P for File Sharing
P2P Communication
P2P Communication
Rationaleo Communication is essential in collaboration and communication need only be
between peers Exampleso ICQ
Pioneered instant messages in 1996 ICQ server maps from ICQ-specific addresses to IP addresses;
communication is peer-to-peero Microsoft Threedegrees
Instant messaging++: peer-to-peer social groups Builds on Microsoft P2P technology; enables traversal of
NAT/Firewalls
P2P Collaboration
P2P Collaboration
Rationaleo Human collaboration is intrinsically peer-to-peer, reflect this in software
architectures Exampleso Groove
Commercial peer platform for hosting peer-to-peer applications and business solutions
Focus on security Based on publish/subscribe in which events can be cached
o Distributed Knight Peer-to-peer collaboration on Unified Modeling Language (UML)
diagrams Tight integration with context-aware instant messaging system
P2P for Distributed Computation
P2P for distributed computation
Typical model:o central server divides "embarrassingly parallelisable" problem into manageable
chunks and distributes these to clients which perform computations and return resultso in principle similar to clusters, such as Beowulf
True P2P?o sort of... most projects are strictly hierarchical in architectureo certainly fits "deployable in an ad-hoc fashion, without requiring centralised
management or control"
P2P for distributed computation - pro et contra
Advantageso scales well for the right kind of problemo supercomputing for a low, low price
o as peers need not communicate with each other, peers only need to be online when receiving work or sending results - thus even modem users can participate
Disadvantageso far from all computational problems can be parallelised to the necessary degreeo project must generate sufficient "buzz" in order to get people to donate clock
cycles
SETI@Home - looking for the little green men
Largest (distributed) computation project ever Problem: To find radio signals from alien civilisationso this requires extensive filtering of radio signals, which is very computational
expensive due to the large amount of data Solution: Get people to donate their spare clock cycles to the project by running screen
savers and background processes Some statistics:o current #users: 4.670.336o current performance: 104.73 TeraFLOPS
NEC Earth-Simulator peak performance: 40.96 TeraFLOPSo (in other words: SETI@Home is a ridiculously powerful system)
SETI@Home - architecture
Data is collected by piggy-backing on the Arecibo radio telescope; it is then divided into work units to be distributed to the clients for processing
SETI@Home - experiences
A huge success!o the very success of the system has led to problems coping with the large
number of clientso still no alien civilisations...
Problemso the prestige of having a high ranking makes it attractive to cheat the system by
faking results. Others deliberately corrupt results to mislead the system.o SETI@Home uses cryptographic methods (and closed source) to combat this
behaviour. To ensure data integrity, all work units are processed repeatedly by different clients
Some other distributed computation projects
distributed.neto has led a number of projects to break various encryption methods by brute
force and solving mathematical problems Folding@Homeo simulates protein folding (a hard problem) using distributed computation
Genome@Homeo engineers new proteins through simulation
o Middleware infrastructure, tools, and applications concerned with integrating geographically distributed computational resources.
P2P for File Sharing
P2P for File Sharing
Rationaleo Peers want to share information. The machines of peers are often partly unused
Exampleso Napster...
MP3 file sharing and searching service Started in 1999, bankrupt June 2002 Hybrid P2P solution: Files on peers, metadata on server
o Freenet Goal: Anonymous information distribution, censor resistance Completely decentralized P2P solution Routing based on "closeness" to target; routing replicates data (that
may be purged later)
File Sharing Systems
Gnutella Freenet
Gnutella
The first major truly distributed P2P file sharing system. Napster demonstrated the problem of a single point of failure Gnutella is fully distributed and cannot be easily be taken out by an attack (legal or
otherwise) Invented by Justin Frankel & Tom Pepper of Nullsoft and Winamp fame Very quickly pulled by AOL/Time Warner (the owners of Nullsoft) At that point the source was "in the wild", and a number of Gnutella variants have
developed
How does it work?
A Gnutella peer starts out with a number of peers from "somewhere" It can query these peers for the peers they know, and thus build a list of potential peers
to contact Queries are broadcast to all known peers who in turn call all their peers and so on Queries has a unique ID (128 bit) and a TTL (time to live). This ensures that peers do
not retransmit the same query twice and that queries eventually die out Peers remembers received and transmitted queries and whence they came If a query match is found, the response (containing the query and the host address) is
returned following the query route back to the originator The originator will (presumably) received a number of hits and then contact a host
directly for downloading
How does it work?
Gnutella in action
Experiences
Hardly the most efficient use of network resources Downloads the whole file from a single peerso So if that peer goes missing in the middle of your download...
Objectiveo to build a virtual file space across peers that cannot be easily attacked and
provides a high degree of protection against censorship Decentralised architecture without a single point of failure Builtin redundancy - popular files are replicated across the network High security and plausible deniability - nodes have encrypted file spaces Have found use in mainland China where censorship is very, very real
Characteristics
Globally Unique IDentifiers (GUIDs) are crucial in Freenet - these are SHA1 hashes (160 bit)o Content-hash keys (CHK) : Hashes calculated over files inserted into Freeneto signed-subspace keys (SSK): Hashes calculated from a public key and a textual
description. The signified file is signed with the private key and can therefore only be modified by the owner. These ("indirect") files are intended to contain directory listings with GUIDs on other files
To participate in Freenet, a node must provide some disk space
Architecture
Freenet node know only their immediate neighbours.o traffic may have originated from the neighbour, or the neighbour might only be
passing it ono this makes it difficult to pinpoint whence a file originatedo this also means that files get transferred over a number of nodes before
reaching the destination Nodes maintains a table of known GUIDs and the neighbours thought to hold the
associated resource (maybe itself) Requests are forwarded to the most likely neighbour - the one with the closest GUIDs
Requesting a file
A user knows from somewhere the GUID of a desired resource This query is checked against the local node's store. If not found, the query is
forwarded to the neighbour with the closest GUID, and this process is repeated until the resource is located or TTL runs out
If the resource is located, it is returned by the same route to the originator (who is the only who knows it is the originator). Along the route back, nodes stores the GUID and may even cache the resource
Thus popular resources and their GUIDs are replicated across the network
Requesting a file
Storing a file on Freenet
Similar to query The originator stores the resource locally, hashes the resource and sends the CHK out
on the network with a TTL Other nodes checks the CHK for uniqueness and forwards it to the nearest neighbour
until TTL runs out. The 'all clear' is returned to the originator and the file is now available If other nodes request the resource, it will be propagated along the route
Joining Freenet
A new node joins Freenet by making an announcement (containing a public key, an IP address and TTL) to a (somehow) known node.
This nodes forwards the announcement until TTL and the "old" nodes generate a GUID in concert for the new node
The GUID is then the responsibility of the new node and request close to the GUID are forwarded to the node
Experiences
Searching is so far somewhat missing - this is handled elsewhere (and this of course presents a target for censorship)
Resources are encouraged to be encrypted using creator's private key system, allowing readers to decrypt it with the public key. How are these keys safely distributed?
The safety of the system means that resources may travel some distance before reaching their destination. OTOH replication of resources improves performance
Summary
The strength of P2P is in numbers:o Great number of unused processorso Great number of unused bandwidth
By leveraging these strengths, P2P systems can be built to increase
o Computing powero Data availabilityo Free speech
Developing P2P Applications in JXTA JXTA Basics
JXTA Basics
What is JXTA?
Basically, a set of protocol specification for P2P networkingo A number of language bindings developed or under way: Java, C, Python, Perl,
Ruby, Smalltalko Started out at SUN, now an open source effort: http://www.jxta.org
Goalso Interoperability: Various P2P system should be interoperableo Platform independence: JXTA should run on multiple programming languages,
protocols, and operating systemo Ubiquity: JXTA should run on multiple devices
JXTA Layers Overview
JXTA Layers
JXTA Core
o Essential building blocks for P2P applicationso Discovery, transport (including firewall handling), creation of peers and peer
groups, and associated security primitives. JXTA Serviceso Services common to P2P applicationso Searching, indexing, directory, storage, file sharing
JXTA Applicationso Integrated P2P applicationso May interoperate with other JXTA applications
Core JXTA Concepts
Peerso A networked device that implements one or more JXTA protocols
Peer groupso A set of peers providing a set of services
Pipeso Used to send messages between peers
Messageso Basic unit of data exchange between peers
Centralized server for metadatao Rendezvous peer (at napster.com)o Enables simple peers to locate MP3 file advertisements (title, IP address, port)
Computers sharing MP3so Simple peerso TCP as network transport
Firewall traversalo Peers behind firewalls make HTTP requests to get datao Only single firewall traversal possible
P2P for Mobile Devices P2P for Mobile Devices P2P Systems for Mobile Devices JXTA for Handheld Devices
P2P for Mobile Devices
The Vision
Devices are becoming network-awareo Bluetootho WiFio IrDAo GSM, GPRS, UTMS
Problem:o GPRS/UTMS is fairly expensive...
What if sharing and communication between devices could be handled directly? Uses?o killer application still missing (that is your mission)o dynamic configured data radio networks used by troops in the fieldo sharing of MP3s (and wotnot) with other hip & trendy people at the café...
Challenges
Network availabilityo Mobile devices move by definition
in and out of range Limited bandwidtho Bluetooth is not exactly speedy...
Limited storage capacityo compared to larger devices
Solutions - or attempts at solutions
Store and Forwardo messages hop from one peer to anothero if connections can be broken at any moment, network communication must be
very careful Dynamic routingo the Internet is bad enough with regards to changing conditions, but this is
ridiculouso still an area of much research - not at all easy to create an efficient algorithm
for routing packets in such a network MANET (Mobile Ad-hoc Networks)o This is an IETF working group on this topic
P2P Systems for Mobile Devices
Passive Distributed Index
A mobile P2P system must be a "pure" P2P networko we cannot rely on a central index - no peer has the resources and no single peer
can reach all other peers How is searching accomplished across a dynamically changing network? The index must be distributed and dynamically updated
Each peer maintainso a document repository (documents have unique IDs similar to URLs)o an index cache: (keywords, document ID)*
Queries are broadcast and forwarded (with TTL) Responses (Query, Document ID*) are broadcast and forwarded (with TTL) A peer will update its local index cache based on the received responses and forward
the responses to other peerso minus the Document IDs it already knew
JXTA for Handheld Devices
JXME
J2ME - Java Micro Editiono a small Java environment found in many devices (e.g. mobile phones)
Goalso Be interoperable with JXTA-J2SE and JXTA-J2ME(proxied) thru protocols.o Provide a p2p infrastructure for small devices.o Be simple and easy to use by developers.o Be small enough to be used with smart phones and PDAs.o Provide a good user experience.o Be CLDC-1.0 and MIDP-2.0 compliant.
JXME - current status
Discovery ofo Pipes.
An application is able to search for a named pipes created by other Peers.
o Groups. An application is able to discover a JXTA group and join it.
o Contents. Applications are able to discover application specific contents.
Createo Pipes.
An application is able to create pipes - both point-to-point and propagate pipes.
o Groups. An application is able to create peer groups to limit the scope of
discovery.o Contents.
Application specific contents. Join Groups.o An application is able to join a given group as per JXTA spec.
Communicate.o An application is able to communicate with other JXTA users thru JXTA
50k MIDlet size Current cell phones have a total limit of about 123K for storing all MIDlet suites. In addition, Motorola phones currently limit each MIDlet to be no more than 50K and NTT DoCoMo phones limit MIDlets to 30K.
Persistent storage on cell phones can be as little as 8K which is shared by all the MIDlets.
Runtime heap is of the order of 32K - 64K Bandwidth is very limited and latency is high CPU power is very limited - around 20MHz. Battery life is very critical. Limited libraries MIDP-2.0 haso No XML parsero Limited Networking (only outgoing HTTP is supported)
Summary
P2P systems successfully work in a number of contexts Challengeso dynamic net topologyo can be address by replication and caching
P2P for mobile deviceso still an area in progresso challenges are similar to standard P2P, but much more severeo as the technology matures and becomes generally available, the next problem
![[PPT]OCCUPATIONAL HEALTH - University of Pittsburghsuper7/13011-14001/13471.ppt · Web viewGOALS To reduce industrial accidents. To prevent occupational hazards/ diseases. To achieve](https://static.documents.pub/doc/80x56/5acfe1977f8b9ac1478d56f8/pptoccupational-health-university-of-super713011-1400113471pptweb-viewgoals.jpg)
![[PPT]PowerPoint Presentation - Johns Hopkins Hospitalschoolsofmedicalimaging.rad.jhmi.edu/documents/... · Web viewGoals of this Presentation Educate the prospective applicant about](https://static.documents.pub/doc/80x56/5b2373d27f8b9ac1328b6529/pptpowerpoint-presentation-johns-hopkins-hospitalsch-web-viewgoals-of-this.jpg)
