1. M. Ranganathan ITG/ANTD/NIST
JXTA Overview and Demo
M. Ranganathan
ITG/ANTD/NIST

2. Peer-peer networking Focus at the application level
Create an overlay network : Separation between physical and logical structure using
one layer of indirection.

3. P2P Applications Application Characteristics: Examples
Centralization not possible or desired.
Massive Scalability
Relationships are transient or ad hoc
Resources are distributed
Resilience is desired
Examples
File sharing.
Collaborative Applications
Distributed/Grid Computing.
Distributed Storage.
Distributed Caches.

4. P2P Applications
Search the entire web and all its connected devices (not just servers) for needed information
Save files and information to distributed locations on the network
Connect game systems so that multiple people in multiple locations
Participate in auctions among selected groups of individuals
Collaborate on projects from anywhere using any connected device
Share compute services, such as processor cycles or storage systems, regardless of where the systems or the users are located
Wireless tic-tac-toe / picture sharing.

5. JXTA Overview
JXTA is a set of open XML-based protocols to build Peer to Peer Applications.
API bindings for the protocols are defined for J2SE, J2ME, C++ etc.
Project JXTA is sponsored by SUN.
JXTA open source community hosted at

6. Goal/Purpose
Enable a wide range of distributed computing applications by developing a common set of general purpose P2P protocols
Platform independence - any language, any OS, any hardware. JXTA is a set of protocols.
Minimal Hardware assumptions: enable new applications to run on any device that has a digital heartbeat (desktop computers, servers, PDAs, cell phones, and other connected devices)
Security / monitoring features to enable commercial deployment.

7. JXTA is based on Protocols
Defines XML message formats or protocols for communication between peers.
Protocols are used to discover peers, advertise or discover resources communicate, route messages and provide monitoring.
Protocols can be implemented in any language.

8. JXTA Protocol Abstractions
Peer - A JXTA speaking process.
Peer Service – A Fragment of code specific to a peer
Peer Groups - Peers providing a common service
Peer Group Service – A fragment of code that is common to the peer group.
Advertisements – XML Document that publishes existence of resources
Pipes – uni-directional, asynchronous, virtual channels for point-point and point-multi-point communication.
Messages – XML envelopes

9. JXTA Abstractions Each JXTA resource is identified by a UUID.
Six types of JXTA entities with unique IDs:
Peers, Peer groups, pipes, message contents, module classes and module specifications.

10. Structure JXTA Applications JXTA Services JXTA Core
JXTA Community Applications
Sun Applications
JXTA Shell Peer Commands
JXTA Community Services
Sun JXTA Services
JXTA Services
JXTA Core
Security
Peer Groups
Peer Pipes
Peer Monitoring
Any Peer on the Web

11. The Layers
Platform Layer, also known as the JXTA core, encapsulates the minimal and essential primitives that are common to all P2P environments. These include the creation of peers, peer groups and security primitives.
Service Layer. The Service layer includes the services that are not completely necessary for P2P networking, but are often used to make some tasks easier.
Application Layer. Implementations of integrated applications: i P2P instant messaging, document and resource sharing and P2P systems.

12. Peers
Peer is any networked device that implements one or more of the JXTA protocols.
Each peer operates independently and asynchronously from all other peers.
Uniquely identified with a Peer ID.
Peers publish one or more network interfaces for use with the JXTA protocols.
Intermediate peers may be used to route messages.

13. Peer Groups
Collection of Peers that have agreed upon a common set of services.
Each Peer group is identified using a unique peer group ID.
Peers may belong to more than one peer group simultaneously.
All peers belong to the NetPeerGroup.

14. Motivations for Peer Groups
To Create a Secure Environment:
Local domain of control in which a specific security policy can be enforced. Peer group boundaries permit members to access/publish protected contents.
To Create a Scoping Environment:
Allow the establishment of a local domain of specialization.

15. Peer Group Services
A set of services that are replicated through the whole peer group.
Root peer group has the following services:
Discovery Service: search for peer group resources.
Membership Service: Accept/deny new members.
Access Service: Validate requests
Pipe Service: Create / Manage pipe connections
Resolver Service: Send generic queries to other peers.
Monitoring Service: Allow one peer to monitor the other members of the same peer group.

16. Network Services
Peer Service: Accessible only on the peer that is publishing the service:
Multiple instances of the service can be run on different peers.
Peer Group Service: A collection of instances of the service (potentially collaborating with each other).
Peer group services are published as part of the peer group advertisement.

17. Modules Modules: Abstraction to represent a piece of Code.
Can be java class, DLL a set of XML messages or a script.
Generic Abstraction to allow a peer to instantiate new behavior.
JXTA platform uses module advertisements to describe itself.

18. Modules Module Class : identified by unique class id.
Module Spec: Contains all the information necessary to access a module. Module Spec implies network compatibility:
For a service module spec may contain pipe advertisement.
Module Implementation – can be multiple module implementations for a given module spec.

19. Pipes
Virtual communication channel that may connect peers that do not have a direct physical link.
JXTA peers use PIPES to send messages to each other.
Pipes are an asynchronous and unidirectional message transfer mechanism used for service communication.
Pipes support transfer of binary/text.
JXTA pipes may have endpoints that are connected to different peers at different times or not connected at all.

20. Pipes Hide Plumbing Details

21. Pipes Point-to-point Pipes: Propagate Pipes: Secure Unicast Pipe:
Connect exactly two endpoints together
Propagate Pipes:
Connect one output pipe to multiple input pipes.
All propagation is done in the scope of a peer group. That is, the output pipe and all input pipes must belong to the same peer group.
Secure Unicast Pipe:
Point-to-point secure communication channel.

22. Advertisements
All network resources are represented by advertisements.
JXTA protocols use advertisements to describe and publish the existence of peer resources.
Peers discover resources by searching for corresponding advertisements.
Advertisement is published with a lifetime that specifies the availability of associated resources.

23. JXTA Advertisement <?xml version="1.0"?>
<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xmlns:jxta="
<Id>
urn:jxta:uuid E CFDF904
</Id>
<Type>
JxtaUnicast
</Type>
<Name>
foo
</Name>
</jxta:PipeAdvertisement>

24. Advertisements Peer Advertisement: Peer Group Advertisement:
Describes Peer Resources
Peer Group Advertisement:
Describes Peer group specific resources.
Pipe Advertisement:
Describes a Pipe Communication channel.
Module Class Advertisement:
Describes a Module Class.
Formally documents the existence of a module class.

25. Advertisements Module Spec Advertisement Module Impl Advertisement
Defines a Module Specification
Provides references to the documentation needed to create a conforming implementations of that specification.
Module Impl Advertisement
Defines an implementation of a module spec.
Includes name, module spec Id , code, package and parameter fields which enable the peer to retrieve the data necessary to execute the advertisement.

26. Advertisements Rendezvous Advertisement Peer Info Advertisement
Describes a peer that acts as a rendezvous.
Peer Info Advertisement
Describes peer info resources.
Holds information about the current state of a peer.

27. Quick JXTA Demo Demo will do the following: Make advertisements.
Publish the Advertisements.
Discover the advertisement.
Use the advertised pipe to send a file from peer to peer.

28. Demo Start 3 jxta shells on the same machine.
Make one jxta shell the rendezvous peer.
Make the other two use the rdv peer.
Test peer discovery.
Examine the peer advertisement.
Make a Pipe advertisement (from sh2)
p = mkadv –p pipename
publish –d p
inpipe = mkpipe –i p

29. Demo From shell 3 discover the pipe Make a message to send
search –r #send out discovery request
search #see what arrived in cache
cat advxx #Examine the pipe advertisement
outpipe = mkpipe –o advxx # make outpipe
Make a message to send
importfile –f data mydata #Create data object
put mymsg mytag mydata #assign data tag
cat mymsg #examine the message

30. Demo Send message through pipe (sh3):
send outpipe mymsg
Read from other end of pipe (sh2):
newmsg = recv inpipe #blocking read
cat newmsg #see what you got
newdata = get newmsg mytag #extract data
cat newdata #see what you got

31. Note Asynchronous programming model Mailbox like message delivery
Results are cached and cache is queried.
Mailbox like message delivery
Advertisements are persistent.
Some amount of configuration necessary.
You can extend the shell and add new commands to it.
Conversely, you can imbed jxta into another shell (tcl/tk).

32. JXTA Protocols
Allow Peers to dynamically route messages to any other peer in the network, potentially traversing firewalls.
Allow Peers advertise their resources and discover resources.
Peers can co-operate to form self-organized and self configured peer-groups independent of their positions in the network ( edges, firewalls, NATS, Public vs. Private Addresses), without the need for a centralized management infrastructure.

33. Protocols Peer Discovery Protocol - find peers, groups, advertisements
Peer Information Protocol - learn peers’ status/properties
Peer Membership Protocol - sign in, sign out, authentication
Pipe Binding Protocol - pipe advertisement to pipe endpoint
Peer Resolver Protocol - send/receive search queries
Endpoint Routing Protocol - available routes to destination

34. JXTA Protocol Stack Via Peer Rslv Peer Disc Peer Info Via Peer Rslv
Pipe Bind
Via Peer Rslv
Pipe Bind
Peer Rslv
Via Peer Rslv
Peer Rslv
Rendezvous
Via Endpt. Routing
Rendezvous
Peer Endpt Routing
Via Network Transport
Peer Endpt Routing
Network Transport
Network Transport

35. Animation of Scenarios
Advertisement Animation
Connection Scenarios

36. Peer Discovery Protocol (PDP)
Peers publish advertisements and discover about resources using advertisements.
Every peer resource is described and published using an advertisement.
Advertisements are XML meta data that describe resources.

37. Peer Information Protocol
Once a peer is located, its capabilities and status may be queried.
PIP ping sent to a peer to check if the peer is alive and to get info about the peer.
Peer Info message used to respond to a ping

38. Peer Resolver Protocol (PRP)
Enables Peer to send generic query requests to other peers and identify matching responses.
Query requests can be sent to specific peer or can be propagated via rendezvous service within the scope of a peer group.
PIP and PDP built using PRP.

39. Pipe Binding Protocol (PBP)
Used by peer group members to bind a pipe advertisement to a pipe endpoint.
Pipe is an abstract named message queue supporting open/resolve (bind), close (unbind), delete, send and receive.
Pipe IDs are unique.
PBP message sent to find a pipe endpoint bound to the same pipe advertisement.

40. Endpoint Routing Protocol
A protocol that allows an endpoint to discover a route (sequence of hops) used to send a message to another peer.
If there is no direct route then the peer needs to find an intermediate peer or set of peers to route the message.

41. Rendezvous Protocol (RVP)
A mechanism by which peers can subscribe to a propagation service.
Within a peer group peers can be Rendezvous peers or listening to RDV peers.
RVP is used by PRP and PBP in order to propagate messages.

42. Network Architecture JXTA Peers have different capabilities:
Micro Peer, Standard Peer, Super Peer, Rendezvous peer.
Minimal Edge Peer:
Device with minimal capability. Must implement the Peer Resolver Protocol and Endpoint Routing Protocol.
Full Featured Edge Peer
Will Cache advertisements.

43. Network Architecture Rendezvous Peer: Relay Peer:
RDV peer forwards advertisements. Peers seek RDV peers in their peer groups. Discovery requests are forwarded through RDV peers
Relay Peer:
Maintains information about routes to other peers and routes messages to them.
Forward messages on behalf of peers that cannot directly access another peer.

44. Discovery Service Retrieve Remote / Local Advertisements
Application can dispatch queries using getLocal/Remote Advertisements to fetch advertisements.
Publish Advertisements Locally
Publish Advertisements remotely
Flush local advertisements.
Informs the application through an asynchronous Listener Interface.
Delivers discovery event when a query is processed.

45. Resolver Service
Encapsulates the Resolver Protocol and hides its complexity.
Discovery Service uses the resolver service.
Resolver Service needs two types of messages:
Resolver query message and Response message.
Developer can create a Resolver Query message at any time and send query to a specific Resolver handler on a remote peer.
Developer can register a query handler for a resolver query for a given handler name.

46. Shared Distributed Index (SRDI)
Optimization to reduce the number of messages for search.
When edge peers publish new advertisements, they use the SRDI service to push advertisement indexes to the Rendezvous peer.
Queries are only propagated to RDV peers.

47. Firewalls and NATs
Firewalls offend and defend the nation’s IT infrastructure.
Firewall traversal depends upon the existence of a RDV peer that both communicating parties can contact.
Assumption – Firewall allows HTTP through.
Use polling to pipeline the message through the firewall.
Ugly but effective solution.

48. Security Requirements
Confidentiality – contents of a message are not divulged.
Authentication – guarantees a sender is who he claims to be
Authorization – Sender is authorized to send the message.
Integrity- Message was not modified in transit.
Refutability – guard against replay attack.

49. JXTA Security Peer group is a “web of trust”
Group can have an authentication method for allowing peers to join the group.
Authentication method using X.509v3 certificates:
Peer must have X509 root cert of any peer with which it wishes to communicate securely
When peer joins the PG, it receives PG creator’s Root cert under TLS
Certificate Service Request is used to acquire group membership cert.
Peers can authenticate each other using the group membership certificate.

50. Virtual TLS JXTA pipe might span multiple relays.
When a JXTA secure pipe is created and the associated endpoints are resolved, an end to end TLS channel is created. Independent of the relays and underlying physical transport.
Peer certificates are exchanged and verified during initialization of the secure pipe.
Peer certificates are digitally signed by the JXTA platform.
JXTA creates a self signed root certificate and issues a peer certificate based on that root certificate.

51. Security
XML meta data in advertisements provide Credentials, Certificates, Digests and Public Keys.
Credential – token that can be used to identify the sender.
Credentials are used for authorization and authentication.
Message can be encrypted/decrypted using private/public key pairs.
Certificates are distributed using TLS.

52. JXTA Security API API are based on the JAVA Smart Card API.
JXTA API does not provide support for key distribution.
Provides support for cypher / decypher, hash computation and digital signature.

53. JXTA based Grid Broker Service
Resource or User Registration –
Peer Advertisements User wants to submit the job to broker –
Job Advertisement  Broker matches jobs and resource –
Pipe Message sent back to User Job Submission –
Using Pipe to send the job to resource
Broker – matches jobs to available resources
broker
Res. Avail Adv
Resource Adv
Job Adv
JOB
User Adv
Resource
Discover
Pipe
Publish

54. JXTA XML RPC and JXTA SOAP
SOAP – Simple Object Access Protocol.
Tunnel XML RPC (lightweight SOAP) or SOAP on JXTA Pipes.
Allow users to build and publish web services in a firewall-controlled environment.
Free the web from the tyranny of system administrators.
Everybody can run a web server like in the good old days!

55. Voice Over P2P Try to stream voice over JXTA pipes. Why? Firewalls.
Advantages
Instant deployment
No need for complex protocol (RADIUS/DIAMETER whatnot).
Disadvantages:
Voice quality will likely be bad.
People will tolerate bad quality for convenience.

56. Project Ideas (discussion)
Measurements of peer to peer protocol performance.
A simulation of JXTA vs other P2P protocols:
Decentralization and timeouts means inconsistencies in application state are possible.
How to tune cache advertisement timeouts.
The variation of responsiveness and peer discovery with group size (what is the latency of finding a pipe or advertisement as a function of network parameters).

57. Project Ideas (discussion)
Firewalls are here to stay:
Firewalls are a huge barrier for IP Telephony.
Effective FW solution is a huge win (see over downloads of the beta client in a single day).

58. Project Ideas (discussion)
JXTA allows P2P interaction through firewalls:
What bandwidth/delay characteristics can we expect.
How can we bridge between SIP/SDP (which specifies RTP parameters) and JXTA?
Can we build a gateway which will allow you to do voice calls through a SIP phone using JXTA as a transport for everything (signaling and voice)?
If so you can use your MSN messenger or SIP phone through a FW and deployment would be easy (could be an applet). What performance can you expect?

59. JXTA vs. JINI Language dependence Centralization JXTA is XML based.
JINI relies on java object serialization.
JXTA protocols are language independent.
Centralization
JXTA assumes no centralization (well, except for the RDV peers??).
JINI uses a centralized service location broker.

60. Material for this talk JXTA Protocol Specification
JXTA Programmers Reference
JXTA in a Nutshell by Scott Oaks, Bernard Travesat and Li Gong
O’Reilly publishing
JXTA by Brendon Wilson
New Riders Publishing ( Free PDF available from )