6-1 how to write jxta applications. 6-1 learning objectives ● this module will help you... –...
DESCRIPTION
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 resourceTRANSCRIPT
6-1
How to Write JXTA ApplicationsHow 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● 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
Advantages
6-1
Logical Addressing● 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
Guidelines
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 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
Applications restricted to a single peergroup
6-1
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
Applications using Multiple Peergroups
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● 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
Publishing and Instantiation
6-1
Peergroup vs. Peer Services● 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
Which to Choose?
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● 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
Query/Response Model
6-1
Asynchronous Discovery● 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
Guidelines
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● 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
Overview
6-1
Advertisements● 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)
Expiration Lifetime
6-1
Advertisements● 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)
Guidelines
6-1
Advertisements● 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
Immutability
6-1
Advertisements● 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
Publishing & Peergroup Scoping
6-1
Endpoint versus Pipe Service
● Endpoint service– Low-level communication service
between two physical endpoint addresses
● Pipe service– High-level communication service
between two logical peer IDs
Two Core Communication Services
6-1
Endpoint versus Pipe Service● 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
Guidelines
6-1
Pipes● 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
Universal Resource Connector
6-1
Pipes● 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)
Unreliable Unicast
6-1
Pipes● 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
Unreliable Propagate
6-1
Pipes
● 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
Secure Unicast
6-1
Pipes● 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
Typical Scenario
6-1
Resolver● 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
Generic Query/Response Framework
6-1
Resolver Service● 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
Guidelines
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● 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
Guidelines
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● 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
Dynamic Service Loading
6-1
Modules● 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
Terminology
6-1
Modules● 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
Example
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 ApplicationsEnd – How to Write JXTA Applications