Distributed Search System Application Architectures
Search systems allow users/peers to search for data that is distributed around the P2P network. The main capabilities of such systems include:
- Peer Discovery - Allowing peers to discover and be aware of each other
- Resource Discovery - Allowing peers to discover and be aware of resources (for example, data) that may exist on the network
- Peer Communication - Allowing peers to communicate with each other, including allowing the transference of data
- Resource Searching - Allowing peers to search the network for resources, potentially using a variety of filtering techniques
- Peer and Resource ID - Allowing peers and resources to be uniquely identified on the network
- Security - Providing security within the system
- Data Management - Allowing data to be stored and managed on the peers
- User Interface - Allowing for the creation of a search system user interface for the peers
- Network Structure - Allowing for the creation of de-centralised and semi-centralised systems
Semi-centralised: Server Node
The server version of this architecture domain would
typically utilise mechanisms for searching and filtering data that is indexed
within a local data repository. When a search request comes in it would
typically pass to the Data Search/Filtering layer where it would be acted upon. The Data Repository would be interrogated
and the returned results could be crosschecked against current online peers if
necessary. Returned results belonging to a peer that is offline or is
overloaded could be filtered out. The final set of search results could then be
returned back to the requesting peer. Server nodes would need to ensure that
the indexed data is kept up to date.
Figure 1 - Search System Server Architecture
Server peer Layers
- Server Control/GUI
- Repository Manager
- Data Search/Filtering
- Checking in/out data
- Awareness Monitor
- Authentication
- Message Resolver
- P2P Network Layer
- Network Interface
Semi-centralised: Client Node
It will be important for the server to be aware of what
data a client peer is making publicly available and what client peers are
on-line. As a result the Awareness Controller within the client is liable to be
tightly coupled to the Awareness Monitor within the server. Typically a client node could supply details
of locally stored data at startup, or whenever the data is changed in someway
(for example, new data being added). When a client receives the search results
from the server it is likely that details regarding the location and
authentication requirements of these peers (if needed) will also be included.
This allows the client peer to then establish a direct connection with the
target peer.
Figure 2 - Search System Client Architecture
Client peer Layers
- Application/GUI
- Awareness Controller
- Message Resolver
- P2P Network Layer
- Network Interface
Decentralised Node
Decentralised search systems are already quite common (Gnutella, Freenet, etc). A node within a decentralised system would possess the same functionality as a client node described above, but would also need to handle the data searching aspect as well. When that node receives a search request then it would need to perform a search on the data that is held locally. In addition the node would also need to handle the decentralisation specific issues (e.g., publishing, discovery and message routing).
Figure 3 – Search System Decentralised Architecture
Decentralised peer Layers
- Application/GUI
- Data Search/Filtering
- Awareness Controller
- Message Resolver
- P2P Network Layer
- Network Interface