Adaptive control of Request Based Distributed Computing

The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC).

This is how I summarised RBDC in a recent post:

Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution – instead issues like availability of computing power, intellectual property and security will dictate this at run time.

This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion.

In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request.

DIAGRAM 1
RBDC Diagram 1

In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it’s local computing capacity. In this case the relevant code is evaluated on the server.

DIAGRAM 2

The two ways of satisfying the request have differing performances. The relative performance of the two alternatives will be determined by things like the server/client balance of: response time, network bandwidth, and network latency.

A monitor can observe the time to complete each http request and recommend to the client whether to request mobile code or to let the server evaluate the code that generates the resource. This is an adaptive process because during a 24 hour period server availability, network latency and available bandwidth could change radically. Once the monitor has decided on the fastest way to execute a piece of mobile code, it may attempt the evaluation of mobile code in the opposite way once every N requests – in this way keeping its adaptive capability current.