1. 6-1 How to Write JXTA Applications

2. 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

3. 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

4. 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

5. 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. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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?

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 6-1 End – How to Write JXTA Applications