Generic Co-operative Architectures

The following diagrams give an example of the layers that would typically be required for a co-operative environment based P2P system. The main capabilities of such a system include:

 

Semi-centralised: Server Node

One of the main roles for the server within a semi-centralised version of this architecture would be to support/administer the communications between peers. In addition the server would most likely enforce the security protocols used within the system, and if required, maintain a system data repository. The P2P Network Layer would deal with the communication (possibly in a secure fashion) with other peers. Incoming data would be passed up to the Message Resolver so it may be decomposed and channelled to the layer it is intended for. In some cases communication may first be authenticated before it is acted upon.

Figure 1 - Generic Co-operative Environment Server Architecture

 

Server peer Layers

 

Semi-centralised: Client Node

One of the key roles of the Client peers would be to keep the server informed of their own status and likewise to be kept informed by the server on the status of other peers that they are aware of. The Awareness Controller would typically carry out such tasks. Again the Message Resolver would take incoming data messages, and after some form of processing pass them on to their destination.

Figure 2 - Generic Co-operative Environment Client Architecture

 

Client peer Layers

 

Decentralised Node

The main difference between decentralised and semi-centralised architectures is that decentralised nodes need to handle the publishing and discovery of peers/resources themselves (rather than relying on a server), and also need to be able to route messages to other peers. Such additional functionality would typically be incorporated into the P2P Network Layer, and would normally involve the creation and publication of adverts onto the network. In addition, some form of discovery mechanism would be required that could propagate discovery requests around the network and collate any responses. In order to reduce the over use of such a mechanism, discovered adverts would typically be stored in a cache allowing them to be re-used at a later date. Cached adverts can be assigned a lifetime, so that the peer/resources need to be rediscovered after a certain point.

 

A routing mechanism would also need to be provided so that messages not for that peer can be forwarded onto other known peers (based on peer adverts in the cache). Normally messages that have been received by the peer are stored for a short time so that if the same message arrives again, it is not repeatedly forwarded around the network. A cache would typically be used to store such messages.

 

Figure 3 – Generic Co-operative Environment Decentralised Architecture

 

Decentralised peer Layers