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