Transcript 6_How_To_final

How to Write JXTA Applications
6-1
Learning Objectives
●
This module will help you...
–
Gain familiarity with guidelines and design
conventions that help ensure best
performance and scalability of applications
written for the Project JXTA platform
6-1
Logical versus Physical Addressing
●
●
Physical addressing
–
Used by most current distributed systems
(Web services, CORBA, RMI)
–
Physical IP address or URL
Logical addressing
–
Logical IDs define a virtual indirection
between the physical location of a resource
and the addressing of a resource
6-1
Logical Addressing
Advantages
●
●
Logical ID can be mapped in a
completely dynamic way
Applications can protect the physical
location of their shared resources
–
●
Can help protect against denial of service
attacks
Enables resources to move in the JXTA
network transparently
6-1
Logical Addressing
Guidelines
●
Applications should take full advantage
of JXTA's virtualization of resources
–
When creating new resources (pipes,
services, etc.), publish and address them
via the JXTA logical ID addressing model
–
Avoid using the peer endpoint address to
reference a resource
–
Avoid hardcoded access of a resource via
an endpoint address
6-1
Peergroups
●
●
●
Everything belongs to a peergroup
–
Used to scope interaction of peers
–
Peers agree on a common set of policies
(membership, discovery, etc.)
No specific peergroup organization
imposed by the JXTA platform
A peer can create and deploy as many
peergroups as it needs, and can belong
to as many peergroups as it wants
6-1
Peergroups
Applications restricted to a single peergroup
●
●
Applications typically create and join a
well-defined peergroup
–
Only this peergroup is known to the
application
–
Provides implicit scoping
–
Defines secure boundaries
Advantages
–
Limits searches
–
Security
6-1
Peergroups
Applications using Multiple Peergroups
●
Some applications need the ability to
discover, create and join multiple
peergroups
–
●
●
●
Example: chatroom application
Each peergroup provides a different context
to the application
Any number of peergroups may be created
Peergroups may be created outside the
scope of the application and may be shared
between multiple applications
6-1
NetPeerGroup
●
●
●
Everything starts from the NetPeerGroup
–
Bootstrapping peergroup of the JXTA
network
–
Used to find other published peergroups
NetPeerGroup definition not hardcoded
–
Can be modified and customized
–
Can clone NetPeerGroup definition and add
or remove any services
Guidelines
–
After initial startup, applications should not
continue to run in the NetPeerGroup
6-1
Peergroup vs. Peer Services
●
●
Peergroup services
–
Defined as part of the peergroup
advertisement
–
Peers instantiate these services when
joining a peergroup
Peer services
–
Published independently by each peer; not
part of the peergroup signature
6-1
Peergroup vs. Peer Services
Publishing and Instantiation
●
Peergroup services
–
●
Published and discovered only when the
peer is joining the peergroup
Peer services
–
Can be published and discovered at any
time, even after the peer has joined the
peergroup
6-1
Peergroup vs. Peer Services
Which to Choose?
●
●
Type of functionalities to be provided
–
Peergroup services can be instantiated by all
members of the peergroup (e.g., a peergroup
membership service that all peers need to join
the group)
–
Peer services provided by only one peer (e.g.,
a naming service for the peergroup)
Availability
–
Peergroup service can potentially be
instantiated on all members; typically have
higher level of availability than peer services
6-1
Asynchronous Discovery
●
●
Unpredictable nature of P2P networks
–
Can't expect a response in a fixed time
–
No upper time limit on discovery responses
–
Query and response message may be
dropped by intermediary peers
Synchronous model strongly
discouraged
–
If application blocks until response arrives,
can lead to deadlock
6-1
Asynchronous Discovery
Query/Response Model
●
Asynchronous listener implementation
–
Peer does not block or wait for reply after
sending a request
–
Query/Response model
●
Peer registers a discovery listener handler
●
Handler waits for query responses to arrive
●
●
When response arrives, the listener will callback the
application with the response
Application can decide to either wait or discard
listener event responses when they arrive
6-1
Asynchronous Discovery
Guidelines
●
●
●
Avoid sending the same query at too short
intervals of time (can overload network)
Choose an appropriate time interval
–
Not less than 5 – 15 minutes recommended
(smaller peergroups can use a shorter interval)
–
Depends on peer connection, type of query, size of
peergroup, search domain
Can resend to protect against message
dropping
–
●
Send a few duplicate queries initially (or via
exponential delay), then stop shortly after
Qualify searches as much as possible
6-1
Nondeterministic Discovery
●
●
●
P2P networks are unpredictable and
nondeterministic
No guarantees an advertisement will be found
–
All peers that hold the advertisement may be down
or unreachable when request is made
–
Query request may be dropped by intermediary
peers
Applications need to plan for and protect
against failure
–
Always looking for currently available resources will
make applications more resilient to network failures
6-1
Unique IDs versus Unique Names
●
JXTA provides unique IDs, not a unique
naming service
–
●
128-bit random numbers, extremely low probability
that two identical IDs are generated to identify the
same resource
Applications should avoid creating resource
advertisements with non-unique names
–
Can use pre-defined advertisements that are
embedded in the application (no discovery needed)
–
Create peergroups that define their discovery
domain
6-1
Advertisements
Overview
●
●
Every resource is described by an
advertisement
–
Applications advertise resources by
publishing advertisements
–
Applications discover resources by
discovering advertisement
Platform defines core advertisements
–
Applications can create their own
advertisements
–
New advertisement types must be
registered
6-1
Advertisements
Expiration Lifetime
●
●
Advertisements assigned an expiration lifetime
when they are published
–
Can specify local lifetime as well as the lifetime for
other peers
–
Can renew the lifetime by republishing
Deletion of advertisements
–
When lifetime expires, advertisement removed
from local cache
–
Deletion occurs in parallel on all peers that have a
copy of the advertisement (decentralized)
6-1
Advertisements
Guidelines
●
●
●
●
●
Need to correctly handle expiration lifetimes to
minimize the number of stale advertisements
Use an appropriate expiration lifetime
–
In general, better to use a shorter expiration
lifetime (minimal lifetime 5 – 15 minutes)
–
Can set shorter expiration for remote peers than
local expiration time
Can republish advertisements
Try to separate static/dynamic information into
separate advertisements
Store logical IDs (not physical addresses)
6-1
Advertisements
Immutability
●
●
Once an advertisement is published, it
cannot be deleted or modified
Applications should be designed to
manage multiple versions of the same
advertisement
–
Applications can use a tag to specify
different versions
–
New tags can be easily added to an
advertisement
6-1
Advertisements
Publishing & Peergroup Scoping
●
Some applications might not publish
advertisements
–
●
Advertisement may be embedded as part of
the application
If advertisements are published
–
–
Published within the context of a peergroup
●
Restricts the scope of a discovery request
●
Request reaches only peers that are members
Can be published in multiple peergroups
6-1
Endpoint versus Pipe Service
Two Core Communication Services
●
Endpoint service
–
●
Low-level communication service between
two physical endpoint addresses
Pipe service
–
High-level communication service between
two logical peer IDs
6-1
Endpoint versus Pipe Service
Guidelines
●
Use pipe service whenever possible
–
●
●
Take advantage of JXTA virtual network
abstraction
Endpoint service
–
Developers who want to implement new pipe
service
–
Applications that need to communicate via
physical endpoint address
Applications that rely on physical endpoint
addresses need to handle unpredictable
nature of P2P networks
6-1
Pipes
Universal Resource Connector
●
●
Pipe service
–
Provides ability to create multiple virtual
communication channels between resources,
independent of physical location
–
Input and output pipes
●
Input pipe listens for pipe messages
●
Output pipe sends messages through the pipe
Core pipe services
–
–
Unreliable unicast
Unreliable propagate
6-1
Pipes
Unreliable Unicast
●
●
●
●
Provides ability to send message between two
pipe endpoints
UDP level of quality of service
– No reliability or guarantee of delivery
No JXTA-imposed limit to size of message;
limitations of underlying physical transport
Guidelines
–
Applications need to handle flow control
–
Should use relatively small messages (less
than a few MBytes)
6-1
Pipes
Unreliable Propagate
●
●
●
Provides ability to propagate message to
multiple pipe endpoints
Enable applications to propagate a message
to a subset of members of a peergroup
– Only members listening on the propagate
pipe will receive the message
Guidelines
–
Applications need to handle flow control
–
Should use very small messages (less than a
few KBytes) to avoid network flooding
6-1
Pipes
Secure Unicast
●
●
●
Provides a reliable secure (TLS) unicast pipe
service
– Data sent using an encrypted session key
negotiated by the two communicating peers
Guarantees ordering and delivery
Guidelines
–
Less efficient – need to minimize usage only
when needed
–
Can use non secure pipe to send encrypted
data
6-1
Pipes
Typical Scenario
●
Sender
–
Publishes pipe advertisement
●
●
–
●
Can publish pipe advertisement directly
Can publish more complex advertisement that
contains a pipe advertisement
Creates and input pipe end and listens on it
Receiver
–
Searches for pipe advertisement
–
Resolves the pipe (done transparently)
●
Finds physical peer where input end is located
6-1
Resolver
Generic Query/Response Framework
●
●
Each peergroup has its own resolver
service
Enables applications to send a generic
query within the scope of a peergroup
–
Propagates query (XML document) to all
peers listening to this specific resolver
handler
–
Receives responses from one or more
peers
–
Handles necessary credentials
6-1
Resolver Service
Guidelines
●
●
Typically, Resolver Service should not be
used by applications
–
Low-level JXTA service, uses physical
addressing
–
Should only be used by services that want to
implement new resolver policies (discovery,
pipe resolution, content management, etc.)
Use Pipe Service instead
–
Use propagate pipe for query requests, and
use unicast pipe to send response
–
Takes advantage of JXTA virtual network
6-1
Rendezvous Service
●
●
●
Used to facilitate the discovery of
advertisements in a peergroup
Each member of a peergroup runs the
rendezvous service
–
Most run only edge side (search)
–
Some run rendezvous side (act as
rendezvous peer)
Each peergroup has its own set of
rendezvous peers
6-1
Rendezvous Peers
●
●
●
Maintain a loosely-coupled index of
resources published in the peergroup
Each rendezvous typically stores only a
portion of the entire index space
Requests propagated via rendezvous
network
–
If rendezvous peers does not have answer,
propagates request to other rendezvous peers
it knows
–
Loop detection guarantees request does not
visit same rendezvous multiple times
6-1
Rendezvous Service
Guidelines
●
●
Ratio of rendezvous peers varies
–
As peergroup grows, need rendezvous to ease
discovery and reduce latency
–
Larger peergroups typically need more rendezvous
–
Not all peers need to act as rendezvous
Peers need to know sufficient rendezvous
–
●
Rule of thumb: know at least 3-5
Rendezvous peers
–
Need to be stable (help avoid inconsistent state)
–
Need sufficient memory
–
Ideally, direct connectivity
6-1
Infrastructure Peers for NetPeerGroup
●
●
Relay peers
–
Required for communication with peers that are not
directly addressable
–
May need more relays depending on size of
targeted peergroups, number of peers that are not
directly addressable, and amount of traffic
–
Should be stable, fast network connectivity
Rendezvous peers
–
Needed for initial discovery of resources in
NetPeerGroup
–
Should be stable, fast network connectivity,
sufficient computing resources
6-1
Modules
Dynamic Service Loading
●
●
Module = generic abstraction
– Used to represent any “code” used to
implement a behavior
–
Allows a peer to instantiate new behavior
–
Enables representation and advertisement of
platform-independent behaviors
–
Allows peers to describe and instantiate any
type of implementation of a behavior
Essential to support peergroup services with
heterogeneous peers
6-1
Modules
Terminology
●
Module Class
●
●
–
Advertises existence of a behavior
–
Each has unique ID (ModuleClassID)
–
Role ID used to distinguish different data sets (e.g.,
company phone directory or personal phone directory)
Module Specification
–
Used to access a module, implies compatibility
–
Each has unique ID (ModuleSpecID)
Module Implementation
–
Implementation of a given Module Specification
●
Contains ModuleSpecID of associated specification
●
May be multiple implementations for same specification
6-1
Modules
Example
●
JXTA Discovery Service
–
Has unique ModuleClassID, identifying it as a
discovery service (its abstract functionality)
–
There can be multiple specifications of the
discovery service, each possibly incompatible with
each other
●
–
Each specification has a unique ModuleSpecID,
which references the ModuleClassID
For each specification, there can be multiple
implementations, each of which contains the
ModuleSpecID
6-1
Review
●
●
●
●
●
Logical vs. physical addressing
Peergroups
–
NetPeerGroup
–
Peergroup vs. peer services
Discovery
–
Asynchronous discovery model
–
Nondeterministic discovery
Unique IDs vs. unique names
Endpoint vs. pipe service
6-1
Review (continued)
●
●
Advertisements
–
Expiration lifetime
–
Immutable (cannot be deleted or modified)
–
Publishing & peergroup scoping
Pipes
–
●
●
●
●
Unreliable unicast/propagate, secure unicast
Resolver service
Rendezvous peers
Infrastructure peers for NetPeerGroup
Modules
6-1
End – How to Write JXTA Applications
6-1