1 / 9

P2P-DIET: One-time and Continuous Queries in Super-Peer Networks

P2P-DIET: One-time and Continuous Queries in Super-Peer Networks. By Stratos Idreos, Manolis Koubarakis and Christos Tryfonopoulos Intelligent Systems Laboratory Technical University of Crete Department of Electronic and Computer Engineering. Introduction.

elijah-harrington
Download Presentation

P2P-DIET: One-time and Continuous Queries in Super-Peer Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. P2P-DIET: One-time and Continuous Queries in Super-Peer Networks By Stratos Idreos, Manolis Koubarakis and Christos Tryfonopoulos Intelligent Systems Laboratory Technical University of Crete Department of Electronic and Computer Engineering

  2. Introduction • Peer-to-peer systems have recently become a very active research area • In recent P2P systems the basic scenarios are: • The one-time query scenario, for example, “I want music by Van Morrison” • The continuous query scenario, for example, “notify me when music by Van Morrison becomes available” • In this work we designed and implemented a peer-to-peer system that supports one-time and continuous queries in a single unifying framework

  3. P2P-DIET Network Shortest path tree for this super-peer NETWORK Super Peer Network ( Alert System ) Client-peer Client-peer Access Point TCP/IP P2P-DIET CP Client-peer Access Point Access Point Super Peers Each client-peer is connected to the network through a single super-peer The functionalities of off-line notifications and rendezvous resources handle problems that may arise when clients are off-line A super-peer stores locally metadata of resources published by the connected to it client-peers while it broadcasts queries to the super-peer backbone The AWP query language, used to describe queries, is Boolean formulas with proximity operators referring to attribute values The goal of super-peers is to handle client requests Client-peers can publish resources and pose one-time or continuous queries A continuous query poset is used at each super-peer to prune messages when broadcasting continuous queries The super-peer form a pure peer-to-peer network and use shortest path trees to communicate The AWP data model is used to create metadata for resources (attribute value pairs) Public key technology is used for secure communication Client migration to different super-peer is allowed There are two type of nodes : super-peers and client-peers P2P-DIET is a super-peer system

  4. Demonstration scenarios The basic scenario • Create super-peer network • Creating appropriate routes to and from each super-peer • Add client-peers • Storing appropriate information for each client-peer • Add remove super-peers or client peers • Fault tolerance

  5. Demonstration scenarios (cont’d) The one-time query scenario Super-peer backbone SP5 SP2 SP1 SP3 SP4 C1 C2 Client C2 connects and poses an one-time query to super-peer SP4 Client C1 connects and publishes a resource to super-peer SP1 Client C2 requests the resource from client C1 SP1 sends a notification directly to client C2 SP4 broadcasts the query to the super-peer backbone

  6. Demonstration scenarios (cont’d)The continuous query scenario Super-peer backbone SP5 SP2 SP1 SP3 SP4 C1 C2 SP1 delivers the notification to C1 and to all client-peers with less general profiles SP1 broadcasts the query q to the super-peer backbone Client C2 connects and publishes a resource that matches the continuous query q to the super-peer SP4 Client C1 connects andsubscribes with acontinuous query q to the super-peer SP1 Client C1 requests the resource from client C2 SP4 unicasts a notification for q to SP1

  7. Demonstration scenarios (cont’d) Off-line notifications and rendezvous resource scenario with migrations Super-peer backbone SP5 SP2 SP1 SP3 SP4 C1 C2 Client C2 requests off-line notifications from SP4. SP4 informs C2 it must upload a resource to SP3 Client C1 requests the IP address of C2. C2 is off-line so C1 requests a rendezvous with the resource of C2 Client C2 connects to super-peer SP4 and publishes a resource that matches query q Client C1 is connected to SP1 and has subscribed with a continuous query q to super-peer SP1 Client C1 requests its off-line notifications from SP1 Client C2 disconnects from the network SP1 stores the notification n because C1 is off-line Client C2 uploads the resource to SP3 Client C1 disconnects from the network Client C1 reconnects to super-peer SP3 (migration) Client C2 reconnects to super-peer SP5 (migration) SP3 sends a notification to C1 SP4 unicasts a notification n for q to SP1 SP3 unicasts the rendezvous request to SP4 Client C1 requests the resource from C2

  8. Conclusion • P2P-DIET is implemented using the java programming language on top of DIET Agents • More information and source code can be found in http://intelligence.tuc.gr/p2pdiet • We have an ongoing implementation of a system that combines functionalities of P2P-DIET and Edutella. • We are implementing P2P-DIET on top of the Chord protocol

  9. Thank you

More Related