Project JXTA – Guide to a peer-to-peer framework

Ekaterina Chtcherbina Siemens AG, Corporate Technology Munich

Thomas Wieland Siemens AG, Munich University of Applied Sciences, Coburg

1 High-level agenda

Introduction Peer-to-Peer Computing The Project JXTA JXTA Concepts JXTA Protocols "Hello JXTA-World"

2 © Siemens CT, Chtcherbina/Wieland, 2002 Introduction: Benefits of Peer-to-Peer Computing

3 5 Myths about P2P

It is always fully decentralized P2P is about People-to-People communication It is only about file sharing P2P is not secure P2P is not scalable

4 © Siemens CT, Chtcherbina/Wieland, 2002 Distributed Search

5 © Siemens CT, Chtcherbina/Wieland, 2002 Multi-user applications and games

6 © Siemens CT, Chtcherbina/Wieland, 2002 Auctions

7 © Siemens CT, Chtcherbina/Wieland, 2002 Collaboration

8 © Siemens CT, Chtcherbina/Wieland, 2002 Resource sharing

9 © Siemens CT, Chtcherbina/Wieland, 2002 Distributed storage and file sharing

10 © Siemens CT, Chtcherbina/Wieland, 2002 Blackboards

11 © Siemens CT, Chtcherbina/Wieland, 2002 Examples of P2P Applications

Building facilities (sensor equipment) Collaboration work support (development tools, data sharing) Medicine (effective collaboration, file sharing, distributed data processing) Building site automatization Business & entertainment communication support Cars (driver support, location based services, car tracking)

12 © Siemens CT, Chtcherbina/Wieland, 2002 Peer-to-Peer Computing

13 What is Peer-to-Peer Networking?

Traditional P2P network definition (comp. sc. encyclopedia): “A type of network in which each workstation has equivalent capabilities and responsibilities. This differs from client/server architectures, in which some computers are dedicated to serving others.”

Our P2P network definition: “An adaptive, self-configuring network which does not rely on central servers. The peers in a P2P network are devices that can act as both servers and clients (servents).”

14 © Siemens CT, Chtcherbina/Wieland, 2002 Disadvantages of Client/Server Systems

Central servers (or server clusters) are potential bottlenecks and single points of failure of distributed systems P2P allows for efficient use of resources and robustness

15 © Siemens CT, Chtcherbina/Wieland, 2002 Peer-to-peer and Ad Hoc Networks

Ad hoc networks require self- configuration Dynamic environment, unstable connectivity, infrastructureless Issues: addressing, service discovery & advertisement, dynamic service composition, connection mgt., routing

P2P enables self-configuration of dynamic distributed systems

16 © Siemens CT, Chtcherbina/Wieland, 2002 Messages in C/S and P2P

Traditional traffic ClientPeer congestion zone

ClientPeer Server Cache ClientPeer ClientPeer Server ClientPeer ClientPeer ClientPeer ClientPeer

17 © Siemens CT, Chtcherbina/Wieland, 2002 Centralized

Distributed networking technologies such as DCOM, CORBA and Web Services currently rely on a priori known directory servers (registry, naming server, UDDI, etc.)

Database 1. 2. Service Client Server

3.

18 © Siemens CT, Chtcherbina/Wieland, 2002 Centralized Distributed Computing (2)

Distributed auto-configuration technologies such as Jini also rely on directory servers

P2P plug and play technologies such as UPnP are more suitable for infrastructureless environments

Peer Peer Peer

Peer Peer

19 © Siemens CT, Chtcherbina/Wieland, 2002 Special Features

Decentralized ☺ /Redundancy/Fault tolerance P2P networks scale well with increasing numbers of users Multiple distributed copies of of frequently accessed resources Nondeterministic Peers can appear and vanish spontaneously Behaviour is less predictable

20 © Siemens CT, Chtcherbina/Wieland, 2002 Requirements for P2P Systems

Metadata/Interoperability When are they essentially independent ? Encapsulation? Privacy? Trust? Discovery Who is out there ? How do I reach them ? Messaging QoS Security Trust/Reputation Peer-to-peer interaction issues

21 © Siemens CT, Chtcherbina/Wieland, 2002 Security in P2P Networks

22 Security Issues

Authentication The of determining whether or not some entity is in fact who that entity declares itself to be. Authorization Process of giving an authenticated entity permissions to do some action or access some resource Encryption and confidentiality Integrity

23 © Siemens CT, Chtcherbina/Wieland, 2002 Challenges in P2P Systems

Memberships and groups are dynamic People do not trust each other Each peer is untrusted Peers don't have trust relationships Unpredictable network latencies Firewalls and other barriers No central services (especially no directory) Individuals can cause local damage that spreads Every peer may run run different software Code may be mobile Complex systems: hard to understand

24 © Siemens CT, Chtcherbina/Wieland, 2002 Solutions

Mostly based on "web of trust" A trusts B, B trusts C, so A can also trust C Users exchange their public keys and encrypt messages with their private keys Enrich by reputations • Assign reputations to entities • Allow others to retrieve reputations • Use reputation to build trust relationships • Example: eBay Alternative: centrally issued group membership certificates (PKI) Introduces dependencies from a server-like infrastructure component

25 © Siemens CT, Chtcherbina/Wieland, 2002 FurtherPossibleSecurity Tools

Encryption Authentication Firewalls May be installed on each peer Drawbacks: Block all traffic on port, not application; generally static rulesets Sandboxes Essential for mobile code systems! E.g. in Java/JVM, .NET/CLR

26 © Siemens CT, Chtcherbina/Wieland, 2002 Search in P2P Networks

27 Distributed Search: Network Topology Based

Centralized Decentralized (e.g. Napster) (e.g. Gnutella)

Relies on the organization of the peers within the network to route requests Optimization focuses on the reduction of the diameter (no. of hops, round trip time) of the graph representing the distributed network 28 © Siemens CT, Chtcherbina/Wieland, 2002 Distributed Search: Content Mapping Based

Content addressable networks: distributed hash table. Content (or pointer to content) is stored in assigned peers not a practical approach for content described by multiple attributes

Publish/subscribe networks: peers agree on a certain query and advertisement template. Content based routing.

29 © Siemens CT, Chtcherbina/Wieland, 2002 Hybrid Search

Super Hybrid approach: Peer locally centralized + globally decentralized + publish/subscribe (e.g. JXTA Search)

No perfect solution, choice depends on the application

30 © Siemens CT, Chtcherbina/Wieland, 2002 Support for Message Exchange

Routing in multi-hop ad hoc networks Caching mechanism (relaying) for overcoming Disruptive connectivity Relay Firewalls Peer Peer C Firewall Peer Polling B

Peer A Relay Mobile Peer Peer

31 © Siemens CT, Chtcherbina/Wieland, 2002 Peer-to-Peer Systems

P2P platforms Messaging Sun Microsystems: frameworks JXTA Open Source: Jabber Distributed computing Collaboration SETI@home Engenia Software, Inc Entropia Others File sharing Magi: Endevors Freenet Gnutella KaZaA

32 © Siemens CT, Chtcherbina/Wieland, 2002 Project JXTA

33 What is JXTA? conceptual framework for Peer-to-Peer applications serves as a specification, an effort to create a common platform for building distributed services and applications neither a standalone Peer-to-Peer application nor a concrete framework implementation! But: Sun has provided a reference implementation (in Java) which incorporates the specified components Napster, Gnutella, Freenet & Co. provide users with limited ability to share resources and are unable to share data with other, similar applications 34 © Siemens CT, Chtcherbina/Wieland, 2002 The Project JXTA

Started as a research project at Sun Microsystems by Chief Scientist Bill Joy First official release of a Java reference implementation in April 2001 Since then put under an open-source license

The name JXTA is derived from the word juxtapose, meaning to place two entities side-by-side or in close proximity. By choosing this name, the development team at Sun recognized that P2P solutions would always exist alongside the current client/server solutions, rather than replacing them completely. Brendon Wilson

35 © Siemens CT, Chtcherbina/Wieland, 2002 Key Assumptions

Platform Independence (any language, any OS, any hardware) But: JXTA dependence Allow for absolute heterogeneity of peers Highly unreliable & changing network environment Asynchronous,Unreliable,Uni-directional transport Idempotent protocol exchanges – No protocol state Applications to build their own security & encryption models

36 © Siemens CT, Chtcherbina/Wieland, 2002 Technology

JXTA technology is based on XML, Java technology, and key concepts of UNIX operating system Transmitted information is packaged as messages Messages define an XML envelop to transfer any kind of data The use of Java language is not required JXTA protocols can be implemented in C, C++, Perl, or any other programming language

37 © Siemens CT, Chtcherbina/Wieland, 2002 JXTA Concepts

38 JXTA Architecture

Application Level JXTA Services JXTA Platform Components pipes peers peer groups peer groups

Core Services resolver pipe discovery membership

propagation service

router and relay services transports

39 © Siemens CT, Chtcherbina/Wieland, 2002 Key Aspects

XML documents (advertisements) used to describe network resources Abstraction of pipes to peers, and peers to endpoints without reliance upon a central naming/addressing authority A uniform peer addressing scheme (peer IDs)

40 © Siemens CT, Chtcherbina/Wieland, 2002 Peers and Peer Groups

Peer

Peer Group

Net Peer Group 41 © Siemens CT, Chtcherbina/Wieland, 2002 Pipes

Point-to-point pipe

Peer A Peer B

Propagate pipe

Peer B

Peer A Peer C

Peer E Peer D

42 © Siemens CT, Chtcherbina/Wieland, 2002 Advertisements

Representation of JXTA resources Like peers, peer groups, pipes etc. Metadata structures Used to decribe and publish peer resources, e.g. Peer advertisement: Comprises name, ID, endpoints, etc. Peer group advertisement: name, ID, decription, specification Pipe advertisement: ID, pipe type

43 © Siemens CT, Chtcherbina/Wieland, 2002 Kinds of peers

Minimal peer Simple peer Rendevour peer Relay peer

44 © Siemens CT, Chtcherbina/Wieland, 2002 Security in JXTA

Usual issues Confidentiality, integrity, availability - authentication, access control, encryption, secure communication, etc. Developing more concrete and precise security architecture is an ongoing project JXTA does not mandate certain security polices, encryption algorithms or particular implementations! JXTA 1.0 provides Security Primitives: crypto library (MD5, RC4, RSA, etc.) Pluggable Authentication Module (PAM) password-based login transport security mechanism modeled after SSL/TLS

45 © Siemens CT, Chtcherbina/Wieland, 2002 Security Model

Role based trust model with four basic requirements Confidentiality Authorization Data Integrity Refutability XML messages allow meta data such as credentials, digests,certificates Credential – a token when presented in a message uniquely identifies the sender, helps verify the sender’s right to send a message to the endpoint Credential – default mechanism, Applications to implement mechanisms for better security Need to establish trust among peers

46 © Siemens CT, Chtcherbina/Wieland, 2002 Summary

47 Lessons from P2P

P2P is not a new concept, but it offers new possibilities P2P applications Sharing of files and other resources Distributed computation Instant messaging Self-configuring compound services P2P applications need a standard open platform P2P networking does not suit to all application scenarios No QoS guarantee (variable connectivity) ! Hybrid solutions

48 © Siemens CT, Chtcherbina/Wieland, 2002 JXTA summary (for the moment ...)

JXTA – An open-source framework and launching pad for p2p systems Aims to be Interoperable, platform independent and ubiquitous Peers are required to implement a low over-head stack of six JXTA protocols that standardize Peer discovery Self organization into peer groups Peer-to-peer Communication Peer monitoring Challenges Naming & Binding services Security & Trust models Solutions to overcome limitations on NAT gateways & firewalls

49 © Siemens CT, Chtcherbina/Wieland, 2002 Thanks

Stay tuned for more details to come Any Questions?

50 © Siemens CT, Chtcherbina/Wieland, 2002