420 likes | 536 Views
Department of Communications, Optics & Materials Technical University of Denmark. JXTA protocols. Colin Chaballier s051081@student.dtu.dk. 34352-Advanced Protocols 18/04/2006. JXTA. Peer-to-Peer Networking ?. a well-known subject (File Exchange, Instant Messaging ….).
E N D
Department of Communications, Optics & Materials Technical University of Denmark JXTA protocols Colin Chaballier s051081@student.dtu.dk 34352-Advanced Protocols 18/04/2006
JXTA Peer-to-Peer Networking ? a well-known subject (File Exchange, Instant Messaging ….) Peer-to-peer networks are dedicated to their application … a lack of inter-operability … a lack of independence with platforms - Transport Networks - Operating System & programming language A real need for an independent, adhoc, pervasive p2p network >> JXTA !
JXTA Context & Overview - What Jxta is - Jxta’s philosophy - An overlay network2. Protocols- Protocol stack overview - Protocols description - Peer Discovery Protocol - Peer Resolver Protocol - Rendez Vous Protocol - Endpoint Routing Protocol - Pipe Binding Protocol - Peer Information Protocol - Jxta 2 improvements3. Discussion - Jxta’s issues - Implementations, applications and future Agenda
JXTA Context & Overview - What Jxta is - JXTA’s philosophy - An overlay network2. Protocols3. Discussion
What Jxta is A set of specifications by Sun Microsystems Version 1 in June 2001 Version 2 in June 2003 Still improving … Objective: to define protocols for generic peer-to-peer networking Implementations proposed by Sun Microsystems on the Java platforms Colin Chaballier, s051081@student.dtu.dk
JXTA’s philosophy (1/2) Jxta enables to build p2p applications on a common platform (JXTA) with the following characteristics: > scalability > Robustness & fault-resistance > Dynamic behavior & spontaneity > self-organization >> Creation of a new set of applications Colin Chaballier, s051081@student.dtu.dk
JXTA’s philosophy (2/2) Organization of these applications: > Services offered within peergroups > Each peer is able to “provide” or “consume” a service Colin Chaballier, s051081@student.dtu.dk
An overlay network (1/2) Illustration copied from the paper “Project JXTA: A Loosely-Consistent DHT Rendezvous Walker”, B.Traversat and al., Sun Microsystems. Colin Chaballier, s051081@student.dtu.dk
An overlay network (2/2) The basics elements of a JXTA network: > Peer The basic element, could be a PC, a cluster, a sensor … > Peergroup A group of peers with a common interest. Peers must be part of the same peergroup to communicate. > Service Peers can proposes services within their peergroups. > Endpoint Abstraction of peers’ network interfaces. An endpoint can matches with more than one peer (broadcast). > Pipe High level mean of transport between endpoints. > Advertisement Way to provide descriptions of every resources in the network. Colin Chaballier, s051081@student.dtu.dk
JXTA Context & Overview2. Protocols- Protocol stack overview - Protocols description - Peer Discovery Protocol - Peer Resolver Protocol - Rendez Vous Protocol - Endpoint Routing Protocol - Pipe Binding Protocol - Peer Information Protocol - Jxta 2 enhancements3. Discussion
The Jxta protocol stack (1/2) • 6 defined protocols for adhoc and p2p networking to : • Route • Discover • Organize • Monitor • and communicate • … between peers • Without any assumptions on the underlying transport network Colin Chaballier, s051081@student.dtu.dk
The Jxta protocol stack (2/2) 1 5 6 2 3 4 Colin Chaballier, s051081@student.dtu.dk
The Peer Discovery Protocol (1/2) Description Publish and discover ressources using advertisements • Every network resources represented by an advertisement • (peer, peergroup, pipe, module …) • A very simple and generic mechanism • 2 messages types : • Discovery Query Message lookup for a keyword for example • Discovery Response Message reply matching advertisements • No guarantee of response to a query Colin Chaballier, s051081@student.dtu.dk
<?xml version=“1.0” encoding=“UTF-8”?> <jxta:DiscoveryQuery> <Type> . . . </Type> <Threshold> . . . </Threshold> <PeerAdv> . . .</PeerAdv> <Attr> Name </Attr> <Value> *sidus* </Value> </jxta:DiscoveryQuery> The Discovery Query Message structure : <jxta:DiscoveryResponse> <Type> . . . </Type> <Count> . . . </Count> <PeerAdv> . . .</PeerAdv> <Attr> Name. </Attr> <Value> *sidus*</Value> <Response Expiration= ‘’expiration time’’> <!-- pipe adv., containing the string “sidus” in its name> </Response> </jxta:DiscoveryResponse> The Discovery Response Message structure : The Peer Discovery Protocol (2/2) Messages Colin Chaballier, s051081@student.dtu.dk
> Next step: Peer Resolver Protocol 2 The Peer Discovery Protocol - Summary • How to publish and discover network resources with advertisements 1 Colin Chaballier, s051081@student.dtu.dk
The Peer Resolver Protocol (1/2) Description • Spread generic queries to one or more peer inside a peergroup • And matches responses to them • 2 messages types : • Resolver Query Message • Resolver Response Message • A unique ID for each query • Best effort behaviour … any guarantee to get a response to a query Colin Chaballier, s051081@student.dtu.dk
<?xml version=“1.0” encoding=“UTF-8”?> <jxta:ResolverQuery> <Credential> . . . </ Credential> <SrcPeerID> . . . </ SrcPeerID> <HandlerName> . . .</HandlerName> <QueryID> . . . </ QueryID > <Query> <!-- ex: Discovery Query Message --> </Query> </jxta:ResolverQuery> The Resolver Query Message structure : <?xml version=“1.0” encoding=“UTF-8”?> <jxta:ResolverResponse> <Credential> . . . </ Credential> <HandlerName> . . .</HandlerName> <QueryID> . . . </ QueryID > <Response> <!-- ex: Discovery Response Message --> </Response> </jxta:ResolverResponse> The Resolver Response Message structure : The Peer Resolver Protocol (2/2) Messages Colin Chaballier, s051081@student.dtu.dk
> Next step: Rendez Vous Protocol 1 3 2 The Peer Resolver Protocol - Summary • How to send query-based messages through the network Colin Chaballier, s051081@student.dtu.dk
Notion of rendezvous peers Explicit connection between a simple peer and a rendezvous peer The RendezVous Protocol (1/3) Description • Propagation of messages within a peergroup • And control of propagation (TTL, loopback detection) • 3 types of messages : • LeaseRequest • LeaseGranted • LeaseCancelRequest • LeaseCancelled Colin Chaballier, s051081@student.dtu.dk
The RendezVous Protocol (2/3) XML element The rendezvous Propagate Message element: <jxta:RendezVousPropagateMessage> <MessageId> … </MessageId> <DestSName> . . . </DestSName> <DestSParam> . . . </DestSParam> <TTL> … </TTL> <Path> . . . </Path> </jxta:RendezVousPropagateMessage> MessageId : time in ms since propagation start DestSName & DestSParam : name & parameters of the destination service TTL : current TTL of the propagated message Path: peer Ids of peer already visited Colin Chaballier, s051081@student.dtu.dk
The RendezVous Protocol (3/3) Propagation Control Loops: With the path element, messages already processed on a peer are discarded. Expiration: With the TTL element, messages are propagated until the TTL reach zero. Duplication: With the unique identifier, duplicated messages can be detected on peers. > modification with version 2 Colin Chaballier, s051081@student.dtu.dk
3. Send query 4. Propagate query with RVP 5. Peers look for the asked resource 6. Positive replies are sent back No Yes RendezVous Peer Peer 2 Peer 1 Peer 4 Peer 3 No No Partial summary: how to discover resources ? Using the Peer Discovery Protocol, Peer Resolver Protocol, and Rendez Vous Protocol 1. Prepare the Discovery query <jxta:DiscoveryResponse> <Type> . . . </Type> <Count> . . . </Count> <PeerAdv> . . .</PeerAdv> <Attr> Name. </Attr> <Value> *sidus*</Value> <Response Expiration= ‘’expiration time’’> <!-- pipe adv., containing the string “sidus” in its name> </Response> </jxta:DiscoveryResponse> <jxta:ResolverResponse> <Credential> . . . </ Credential> <HandlerName> . . .</HandlerName> <QueryID> . . . </ QueryID > <Response> <!-- Discovery Response Message --> </Response> </jxta:ResolverResponse> <jxta:ResolverQuery> <Credential> . . . </ Credential> <SrcPeerID> . . . </ SrcPeerID> <HandlerName> . . .</HandlerName> <QueryID> . . . </ QueryID > <Query> <!-- Discovery Query Message --> </Query> </jxta:ResolverQuery> <jxta:DiscoveryQuery> <Type> . . . </Type> <Threshold> . . . </Threshold> <PeerAdv> . . .</PeerAdv> <Attr> Name </Attr> <Value> *sidus* </Value> </jxta:DiscoveryQuery> 2. Pack it with a Resolver Query 7. Unpack the Resolver Response 8. Get Discovery Response Animation inspired from the book “JXTA” page 127, Brendon Wilson, New Riders Edition. Colin Chaballier, s051081@student.dtu.dk
> Next step: Endpoint Routing Protocol 1 3 4 2 Colin Chaballier, s051081@student.dtu.dk
The EndPoint Routing Protocol (1/4) Description Any assumption on the underlying transport network (even TCP/IP) … … need to define a own routing protocol. > A routing protocol > A transport protocol Colin Chaballier, s051081@student.dtu.dk
<jxta:EndpointRouter> <Type> RouteQuery </Type> <DestPeer> . . . </ DestPeer> </jxta:EndpointRouter> The Route Query Message: <jxta:EndpointRouter> <Type> RouteResponse </Type> <DestPeerIdTag> . . . </ DestPeerIdTag> <RoutingPeerIdTag> . . . </RoutingPeerIdTag> <RoutingPeerAdvTag> . . . </RoutingPeerAdvTag> <NbOfHops> … </NbOfHops> <GatewayForward> @gw1 </GatewayForward> <GatewayForward> @gw2 </GatewayForward> … </jxta:EndpointRouter> The Route Response Message: The EndPoint Routing Protocol (2/4) A Routing Protocol • Route Query/Response Messages to find routes • Best path decision: dependent of the application, not specified in JXTA. • Allow NAT traversal (use of HTTP for transport) Colin Chaballier, s051081@student.dtu.dk
The Endpoint Router Message element: <jxta:JxtaEndpointRouter> <jxta:Src> … </jxta:Src> <jxta:Dest> … </jxta:Dest> <jxta:Last> … </jxta:Last> <jxta:NBOH>… </jxta:NBOH> <jxta:GatewayForward> @gwForward1 </jxta:GatewayForward > <jxta:GatewayForward> @gwForward2 </jxta:GatewayForward > … <jxta:GatewayReverse> @gwReverse1 </jxta:GatewayReverse > <jxta:GatewayReverse> @gwReverse2 </jxta:GatewayReverse > … </jxta:EndpointRouter> The EndPoint Routing Protocol (3/4) A Transport Protocol • Add routers path (as an XML element) to the sent message Colin Chaballier, s051081@student.dtu.dk
Route Query Message No No Route Response Message Message to sent + Endpoint Router Message Yes Peer 1 Peer 4 Peer Router Peer Router Peer 3 Peer 2 private network http transport Within the same PeerGroup The Endpoint Routing Protocol (4/4) Message exchanges Animation inspired from the book “JXTA” page 278, Brendon Wilson, New Riders Edition. Colin Chaballier, s051081@student.dtu.dk
> Next step: Pipe Binding Protocol 5 1 3 2 4 The EndPoint Routing Protocol - Summary • How to reach a peer in the network Colin Chaballier, s051081@student.dtu.dk
broadcast pipe Peer 2 Peer 3 Peer 4 Peer 1 Unicast pipe The Pipe Binding Protocol (1/2) Description • Used to bind network Endpoint and pipes input/output • Pipes: abstraction to allow easy communication between endpoints • 3 types of pipes: unicast, broadcast, and secure • Only mandatory support of unicast & asynchronous pipe type Colin Chaballier, s051081@student.dtu.dk
<jxta:PipeResolver> <MsgType>Query</MsgType> <PipeId> … </PipeId> <Type> … </Type> <Cached> … </Cached> <Peer> … </Peer> </jxta:PipeResolver> • Pipe Binding Query: • To discover listening peer endpoints to a particular pipe advertisement <jxta:PipeResolver> <MsgType>Answer</MsgType> <PipeId> … </PipeId> <Type> … </Type> <Cached> … </Cached> <Peer> … </Peer> <Found> … </Found> <PeerAdv> … </PeerAdv> </jxta:PipeResolver> • Pipe Binding Response: • Optional response to a Pipe Binding Query The Pipe Binding Protocol (2/2) Colin Chaballier, s051081@student.dtu.dk
> Next step: Pipe Binding Protocol 5 6 1 3 2 The Pipe Binding Protocol - Summary • How to realize a high-level abstraction communication between endpoints 4 Colin Chaballier, s051081@student.dtu.dk
The Peer Information Protocol • A generic protocol to obtain peer status and monitoring information • > help load balancing in the network • A simple Query/Answer mechanism • Peer Info Query and Peer Info Response Messages • PeerInfoResponse Message fields: • Peer uptime • Information timestamp • Response string (unspecified format) • Timestamp of last incoming and outgoing messages • Details on inbound and outbound traffic seen • Number of processed bytes Colin Chaballier, s051081@student.dtu.dk
How to Publish and discover network resources with advertisements • How to send query-based messages through the network • How to propagate messages within a peergroup • How to reach a peer wherever in the network • How to realize a high-level abstraction communication between endpoints • How to monitor peers status 1 5 6 3 2 4 Protocols description - Summary (1/2) Colin Chaballier, s051081@student.dtu.dk
Protocols description - Summary (2/2) The “service” view Colin Chaballier, s051081@student.dtu.dk
Jxta 2 improvements Version 1 since June 2001 Version 2 since February 2003 (now v2.3.5) • Improvement of overall performance and scalability with: • New mechanisms for advertisement discovery (Rendezvous Super-peers) • New mechanisms for NAT traversal (Relay Super-peers) • Specification of a binary message format • … Colin Chaballier, s051081@student.dtu.dk
Jxta 2 improvements • Advertisement discovery with Rendezvous Super-peers • Loosely-consistent Distributed Hash Table • Rendezvous Peer View Illustration copied from the paper “Project JXTA 2.0 Super-Peer Virtual Network“, B.Traversat and al., Sun Microsystems, 2003. Colin Chaballier, s051081@student.dtu.dk
JXTA Context & Overview2. Protocols3. Discussion - Jxta’s issues - Implementations, applications and future
Jxta’s issues • Abstraction: generic, multi-platform, multi-language … • Use of XML: • - easy understand & debug for developers • - flexibility • No definition for services invocation • Not optimized for application oriented: cost of the XML overhead • Not optimized if usage of a reliable transport network (TCP/IP) Trade-off: Performance vs. Flexibility -> Not suitable for a short-term particular p2p application -> But provide the flexibility for a long-term solution requiring scalability Colin Chaballier, s051081@student.dtu.dk
Implementations, applications and future And now, what to do with JXTA protocols ? 1/ Developing a new application based on JXTA > Choose an existing implementation of the JXTA specifications: J2SE, J2ME, C, Perl, PocketPC … or do your proper implementation > And fit the implementation to your application Which components are useless ? What services to deploy ? Topology of rendez-vous peers … etc. 2/ Contribute to the Project JXTA > an open-source intiative still needing contributions … • 3/ Or simply use a current application based on JXTA • from the Jxta community: myJXTA, Gnougat, … • more and more adopted by companies (Boeing, Verizon …) Colin Chaballier, s051081@student.dtu.dk
Summary • Specifications for a generic p2p network • A global adhoc overlay network • Peer group organization • Any assumption on underlying transport network • 6 key protocols • XML based • Performance/flexibility trade-off • Still in improvement - open source community Colin Chaballier, s051081@student.dtu.dk
References > Official web sitefor project JXTA: www.jxta.org • > Books: • "JXTA in a nutshell", S. Oaks, B.Traversat and L.Gong, O'reilly. • "JXTA", Brendon J. Wilson, New Riders Edition. • Freely available online at http://www.brendonwilson.com/projects/jxta-book/ > Articles and reports: • "JXTA Technology Brings the Internet Back to Its Origin”. Available at http://java.sun.com/developer/technicalArticles/JXTA/ • "Project JXTA Virtual Network", B. Traversat et al., Sun Microsystems, 2002. • "Project JXTA 2.0 Super-Peer Virtual Network", B. Traversat et al., Sun Microsystems, 2003. • "Project JXTA: A Loosely-Consistent DHT Rendezvous Walker ", B. Traversat et al., Sun Microsystems. • "The JXTA performance model and evaluation", Emir Halepovic and Ralph Deters, Department of Computer Science, University of Saskatchewan, Canada, published in the Elsevier database "Future Generation Computer Systems", 2004. Colin Chaballier, s051081@student.dtu.dk
Thank you for your attention … Questions ? Colin Chaballier, s051081@student.dtu.dk