|
There are two kinds of nodes in P2P-DIET: super-peer nodes
and client nodes. All super-peers are equal and have the same
responsibilities, thus the super-peer subnetwork is a pure
peer-to-peer network (in terms of graph theory, it can be an
arbitrary undirected graph). Each super-peer serves a fraction of
the clients and keeps indices on the resources of those clients. A
client node can run on the computer of a user. Resources (e.g.,
files in a file-sharing application) will be kept at client nodes,
although it is possible in special cases to store resources at
super-peer nodes. Clients are equal to each other only in terms of
download. When a client wants to actually download a resource, it
downloads it directly from the resource owner client. A client node
can be connected to the network through a single super-peer node,
which is the access point of the client. It is not necessary
for a client to be connected to the same access point continuously
i.e., client migration is allowed. Clients can connect, disconnect
or even leave from the system silently at any time. To enhance the
general form of the network, we also allow clients to use dynamic IP
addresses.
 Clients may publish a resource by sending
a notification to their access point. Among other things,
a notification contains metadata for the resource
expressed in some metadata model e.g., AWPS, RDF etc. In the
current implementation of P2P-DIET resource metadata are
conjunctions of attribute-value pairs in the model AWPS.
Since the current implementation targets resource sharing
applications, attributes have been chosen to be the properties of
the Dublin Core metadata
element set. In the file-sharing application which currently runs on top of
P2P-DIET, a resource can be a file of any type, for example, a
music file or
a Microsoft Word document.
P2P-DIET supports the typical ad-hoc query scenario of
super-peer networks [Yang and Garcia-Molina, 2003]. A client can
send a query to its access point and the access point will
broadcast this query to all super-peers. In this way, answers
will be produced for all matching network resources. Answers are
returned to the access point of the client originating the query
and are then passed to the client for further processing.
P2P-DIET also supports SDI scenarios. Clients may subscribe
to the system with a profile (or long-standing
query) expressing their information needs. Whenever a
notification is generated at any point in the network,
P2P-DIET makes sure that clients with profiles matching this
notification are notified. A high-level view of the P2P-DIET
architecture is shown in the above figure.
References:
Yang and Garcia-Molina, 2003 B. Yang and H. Garcia-Molina.
Designing a super-peer network. Proceedings of the 19th
International Conference on Data Engineering (ICDE 2003),
Bangalore, India, March 5--8, 2003.
|
