Download JXTA Overview - 123SeminarsOnly.com

JXTA Overview and Demo
M. Ranganathan
ITG/ANTD/NIST
Peer-peer networking
Focus at the application level
Create an overlay network : Separation between physical and logical structure using
one layer of indirection.
P2P Applications
• Application Characteristics:
–
–
–
–
–
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.
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.
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
http://www.jxta.org.
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.
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.
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
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.
Structure
JXTA Community
Applications
JXTA Applications
Sun Applications
JXTA
Shell
Peer
JXTA Services Commands
JXTA Community
Services
JXTA
Services
Peer Groups
Peer Pipes
JXTA Core
Security
Any Peer on the Web
Sun
Peer Monitoring
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 email systems.
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.
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.
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.
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.
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.
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.
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.
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.
Pipes Hide Plumbing Details
Pipes
• Point-to-point Pipes:
– 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.
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.
JXTA Advertisement
<?xml version="1.0"?>
<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
<Id>
urn:jxta:uuid-59616261646162614E5047205CFDF904
</Id>
<Type>
JxtaUnicast
</Type>
<Name>
foo
</Name>
</jxta:PipeAdvertisement>
Advertisements
• Peer 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.
Advertisements
• Module Spec 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.
Advertisements
• Rendezvous 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.
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.
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
Demo
• From shell 3 discover the pipe
– 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
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
Note
• Asynchronous programming model
– 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).
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.
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
JXTA Protocol Stack
Peer Disc
Via Peer Rslv
Peer Disc
Peer Info
Via Peer Rslv
Peer Info
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
Animation of Scenarios
Advertisement Animation
http://platform.jxta.org/graphics/adv.swf
Connection Scenarios
http://platform.jxta.org/TutorialGraphics.html
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.
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
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.
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.
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.
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.
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.
Network Architecture
• Rendezvous 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
JXTA based Grid Broker Service
Broker – matches jobs to available resources
broker
Res. Avail Adv
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
Resource Adv
Job Adv
User Adv
JOB
Resource
Discover
Pipe
Publish
http://www.unix.globus.org/cog/projects/jxa/?Projects=&
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!
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.
http://vop2p.jxta.org/
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).
Project Ideas (discussion)
• Firewalls are here to stay:
– Firewalls are a huge barrier for IP Telephony.
– Effective FW solution is a huge win (see
www.skype.com over 300000 downloads of
the beta client in a single day).
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?
JXTA vs. JINI
• Language dependence
– 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.
Material for this talk
• JXTA Protocol Specification
– http://spec.jxta.org
• JXTA Programmers Reference
– http://www.jxta.org
• 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
http://www.brendonwilson.com )