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

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 SP1 SP2 SP3 SP4 SP5 Super-peer backbone C1 Client C1 connects and publishes a resource to super-peer SP1 C2 Client C2 connects and poses an one-time query to super-peer SP4 SP4 broadcasts the query to the super-peer backbone SP1 sends a notification directly to client C2 Client C2 requests the resource from client C1

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

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