Objectives Understanding of Peer-to-Peer architectures Solid knowledge of well-known P2P systems Node 2 Node 1
Peer-to-Peer State and behavior are distributed among peers which can act as either clients or servers. Peers: independent components, having their own state and control thread. Connectors: Network protocols, often custom. Data Elements: Network messages Topology: Network (may have redundant connections between peers); can vary arbitrarily and dynamically Supports decentralized computing with flow of control and resources distributed among peers. Highly robust in the face of failure of any given node. Scalable in terms of access to resources and computing power. But caution on the protocol!
Issues to consider in P2P Locating resources Retrieving resources
Resource localization is decentralized Gnutella is, essentially, a decentralized search system Resource retrieval is P2P Protocols: custom over TCP/IP + HTTP Spec Spec
Case Study: Gnutella Node discovery done off-band channel List shipped with software IRC Mailing lists Only need 1 neighbor node to connect to the node network Gnutella nodes = “servents”
Case Study: Gnutella Search: flooding (originally)
Case Study: Gnutella Connection to peer: GNUTELLA CONNECT/ \n\n Response: GNUTELLA OK\n\n
Case Study: Gnutella Ping messages Used to discover other servents Pong messages Responses to ping messages May be cached; receiver may send may many pong messages to to ping request Payload:
Case Study: Gnutella Query messages Used to find resources Payload: QueryHit messages Responses to query messages Payload:
Case Study: Gnutella [Normal] File download is done via HTTP GET GET /get/ / / HTTP/1.0\r\n Connection: Keep-Alive\r\n Range: bytes=0-\r\n User-Agent: Gnutella\r\n3 \r\n HTTP 200 OK\r\n Server: Gnutella\r\n Content-type: application/binary\r\n Content-length: 4356789\r\n \r\n file data
Case Study: Gnutella Routing Protocol rules: Pong messages may only be sent along the same path as corresponding pings QueryHit messages may only be sent along the same path as corresponding queries Push messages may only be sent along the same path that carried the incoming QueryHits. A servent will forward incoming Ping and Query messages to all of its directly connected servents, except the one that delivered the incoming Ping or Query. A servent will decrement a descriptor header’s TTL field, and increment its Hops field, before it forwards the descriptor to any directly connected servent. If, after decrementing the header’s TTL field, the TTL field is found to be zero, the descriptor is not forwarded along any connection. A servent receiving a message with the same Payload Descriptor and Descriptor ID as one it has received before, should avoid forwarding the message to any connected servent.
A mixed client-server and peer-to-peer architecture addresses the discovery problem. Replication and distribution of the directories, in the form of supernodes, addresses the scalability problem and robustness problem encountered in Napster. Promotion of ordinary peers to supernodes based upon network and processing capabilities addresses another aspect of system performance: “not just any peer” is relied upon for important services. A proprietary protocol employing encryption provides privacy for calls that are relayed through supernode intermediaries. Restriction of participants to clients issued by Skype, and making those clients highly resistant to inspection or modification, prevents malicious clients from entering the network.
Summary Understanding of Peer-to-Peer architectures node discovery resource retrieval how to deal with firewalls Solid knowledge of well-known P2P systems Napster Gnutella Skype (briefly)