P2P-Diet: Ad-hoc and Continuous Queries in Super

Download Report

Transcript P2P-Diet: Ad-hoc and Continuous Queries in Super

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


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
P2P-DIET Network
Shortest path tree for this super-peer
NETWORK
Super Peer Network ( Alert System )
Client-peer
Client-peer
Access Point
TCP/IP
Client-peer
P2P-DIET CP
Access Point
Access Point
Super Peers
Each
client-peer
isdifferent
connected
totosecure
the
network
through
The
A
The
super-peer
functionalities
AWP
query
stores
of
language,
off-line
locally
notifications
used
metadata
tocreate
describe
of
and
resources
rendezvous
queries,
published
is
The
Client-peers
A
The
continuous
The
goal
super-peer
AWP
of super-peers
can
data
query
publish
form
model
poset
a
is
pure
resources
is
to
is
used
used
handle
peer-to-peer
at
and
client
each
pose
requests
metadata
super-peer
network
for
to
Public
There
Client
key
migration
are
technology
two
type
to
of
is
nodes
used
super-peer
:
for
super-peers
is
communication
allowed
and
client-peers
P2P-DIET is a super-peer system
a
single
super-peer
resources
by
Boolean
the
connected
handle
formulas
problems
to
with
itvalue
client-peers
proximity
that
may
operators
while
arise
itwhen
broadcasts
referring
clients
toare
queries
one-time
prune
and
resources
use
messages
or
shortest
continuous
(attribute
when
path
trees
queries
broadcasting
to
pairs)
communicate
continuous
queries
off-line
to
attribute
the super-peer
values backbone
Demonstration scenarios
The basic scenario

Create super-peer network


Add client-peers



Creating appropriate routes to and from
each super-peer
Storing appropriate information for each
client-peer
Add remove super-peers or client peers
Fault tolerance
Demonstration scenarios (cont’d)
The one-time query scenario
Super-peer backbone
SP5
SP2
SP1
SP3
C1
SP4
C2
Client
Client
Client
C2
C1
C2connects
connects
requests
and
and
the
poses
publishes
resource
one-time
from
asuper-peer
resource
client
query
C1
to to
SP1
a notification
directly
client
C2
SP4sends
broadcasts
the
query
toan
theto
super-peer
super-peer
SP1
backboneSP4
Demonstration scenarios (cont’d)
The continuous query scenario
Super-peer backbone
SP5
SP2
SP1
SP3
C1
SP4
C2
SP1
delivers
thethe
notification
to the
C1asuper-peer
and
toa all client-peers
SP1
broadcasts
query
q
to
backbone
Client
Client
C2
C1
connects
connects
and
and
publishes
subscribes
with
resource
that
matches
Client
SP4
unicasts
C1
requests
a
notification
the
resource
for
q
from
to
SP1
client
C2
with
less general
profiles
continuous
query
q toqthe
super-peer
SP1SP4
the continuous query
to the
super-peer
Demonstration scenarios (cont’d)
Off-line notifications and rendezvous resource
scenario with migrations
Super-peer backbone
SP5
SP2
SP1
SP3
C1
SP4
C2
Client
Client
C2
C1
requests
requests
off-line
the
IP
address
notifications
ofhas
C2.
Client
Client
C2
C1
connects
is
connected
to
super-peer
to
SP1
and
SP4
and
subscribed
Client
Client
SP1
Client
Client
C1
stores
C2
C2
C1
requests
disconnects
uploads
disconnects
the
notification
its
the
off-line
from
resource
from
n
the
notifications
the
because
network
to
network
SP3
C1
is
Client
Client
SP3
SP4
SP3
C1
sends
C2
unicasts
unicasts
reconnects
reconnects
a
notification
a
the
notification
rendezvous
to
to
super-peer
super-peer
to
C1
n
for
request
q
SP3
SP5
to
SP1
(migration)
(migration)
to
SP4
Client
C1
requests
the
resource
from
C2
from
C2
is
SP4.
off-line
SP4
so
informs
C1
requests
C2
it
must
a
rendezvous
upload
a
publishes
with
a continuous
a resource
query
that matches
q to super-peer
query qSP1
from
off-line
SP1
resource
with the resource
to SP3 of C2
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 P2PDIET and Edutella.
We are implementing P2P-DIET on top of the
Chord protocol
Thank you