Computational Application Architectures

Computational systems rely heavily on one or more server peers distributing work (work packages) to a network of peers and collating the returned results. The client-server relationship of such systems is often so strong that computational systems (such as SETI@home) are often considered to be not true P2P systems.

The main capabilities of such systems include:

 

It can also be possible for client peers within a computational system to posses autonomy and to be able to communicate directly with each other. This, for example, could allow client peers to communicate results to each other, or possibly to work together as a cluster. The architectures presented here represent those computation systems where the client peers do possess autonomy.

 

Obviously one of the most important aspects of computational systems is that the actual computation that is carried out is correct and not compromised. As a result the best policy to adopt within P2P systems would be to incorporate redundancy into the system, i.e. having a work package processed by multiple peers and comparing the results. Ideally these peers' hardware profiles would also be different (i.e., different operating systems, etc).

 

Semi-centralised: Server Node

The architecture of a server peer would operate in a very similar manner to the document management system. Rather than managing documents the server would instead manage work packages. This would include sending out work packages to client peers, collating the results, comparing the returned results (if redundancy is used), and also keeping track of which client peers are processing which packages. As mentioned, incorporating redundancy would be beneficial and so results returned by client peers need to be authenticated and compared.

Figure 1 – Computational System Server Architecture

Server peer Layers

 

Semi-centralised: Client Node

The client peers would essentially do nothing more than process the work packages that they have been assigned. Such activity may be transparent to the actual user of the peer. If the client peers possess autonomy then they might also communicate with other client peers. This could, for example, allow client peers to work together, in clusters. Obviously, security and trust would be important issues in such scenarios.

Figure 2 – Computational System Client Architecture

Client peer Layers

 

Decentralised Node

Decentralised computational systems can raise a number of design issues. As with the decentralised shared workspace architectures, they will be decentralised in the fact that any peer on the network can initiate a distributed computation, but also centralised in the fact that the peer will need to co-ordinate the work. The lack of control, unpredictable nature of the network and the need to assign peers unique ID’s may hinder this process, and so such a system would need to be carefully designed. Decentralised systems are likely to make much more use of redundancy, and possibly allow peers to further delegate work in a hierarchical fashion. 

 

The decentralised layered architecture extends the client architecture presented above by including mechanisms to manage the work packages. In addition the node would also need to handle the decentralisation specific issues (e.g., publishing, discovery and message routing).

Figure 3 – Computation System Decentralised Architecture

Decentralised peer Layers