Difference between revisions of "Distributed Space"
m |
m (typos) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
*Protocol-independent content distribution (like Hydranode) | *Protocol-independent content distribution (like Hydranode) | ||
*Event-capable (ie changes "pushed" to viewers, tuple-spaces don't work this way) | *Event-capable (ie changes "pushed" to viewers, tuple-spaces don't work this way) | ||
| + | |||
| + | == One:Many == | ||
| + | The class-instance relationship can be seen as a subclass of the more general one-to-many relationship. In a distributed model the one:many relationship is a fundamental requirement since each article of content is stored over many separated peers. These relationships can be static or dynamic, unidirectional or bidirectional or even asymetric. In the same way that a normal DHT uses a portion of the bandwidth resource for routing and query information, the semantic space uses a portion to maintain the dynamic one-to-many relationships content-distribution and membership indexes. | ||
| + | *See also [[w:Associative Entities|Associative Entities]] | ||
| + | |||
| + | == DHT == | ||
| + | The DHT network overlay can be used to maintain a global shared object tree (a semantic space, or TripleSpace). This layer holds small (kilobyte scale) information concerning the relational aspect of the objects not the content associated with them which could be large binary files etc. Rather than maintain a local object cache, we could expect the DHT to handle this - or should be easily extended to do so. | ||
| + | |||
| + | == Resource Allocation & Scheduling == | ||
| + | The storage and communications to content is achieved by the resource allocation layer, which should be a multiplexing solution. Descriptions of resources must include the ability to define the process of completing jobs on a part-by-part basis. | ||
| + | |||
| + | Even more preferable to a Hydranode type solution would be a generic resource allocation and scheduling solution. [[Grid]] technology uses this approach to allocate and account for resource. The layer of the grid architecture which handles this allocation is called [[w:Grid middleware|Grid middleware]] | ||
| + | *[[w:Advanced Resource Connector|Advanced Resource Connector]] | ||
| + | *[[w:Parallel Virtual Machine|Parallel Virtual Machine]] | ||
| + | *[[w:O(1) scheduler|O(1) scheduler]] | ||
| + | *[[w:Statistical multiplexing|Statistical multiplexing]] | ||
| + | |||
| + | == Organisation == | ||
| + | Organisation objects have resource availability and current work which the allocation layer will connect over time. Execution is an event model connecting processes to environmental conditions and recipients groups. | ||
== See also == | == See also == | ||
Latest revision as of 07:11, 28 May 2007
In the project we need a space with the following properties:
- Decentralised and self-organising (like most modern DHT's)
- Protocol-independent content distribution (like Hydranode)
- Event-capable (ie changes "pushed" to viewers, tuple-spaces don't work this way)
One:Many
The class-instance relationship can be seen as a subclass of the more general one-to-many relationship. In a distributed model the one:many relationship is a fundamental requirement since each article of content is stored over many separated peers. These relationships can be static or dynamic, unidirectional or bidirectional or even asymetric. In the same way that a normal DHT uses a portion of the bandwidth resource for routing and query information, the semantic space uses a portion to maintain the dynamic one-to-many relationships content-distribution and membership indexes.
- See also Associative Entities
DHT
The DHT network overlay can be used to maintain a global shared object tree (a semantic space, or TripleSpace). This layer holds small (kilobyte scale) information concerning the relational aspect of the objects not the content associated with them which could be large binary files etc. Rather than maintain a local object cache, we could expect the DHT to handle this - or should be easily extended to do so.
Resource Allocation & Scheduling
The storage and communications to content is achieved by the resource allocation layer, which should be a multiplexing solution. Descriptions of resources must include the ability to define the process of completing jobs on a part-by-part basis.
Even more preferable to a Hydranode type solution would be a generic resource allocation and scheduling solution. Grid technology uses this approach to allocate and account for resource. The layer of the grid architecture which handles this allocation is called Grid middleware
Organisation
Organisation objects have resource availability and current work which the allocation layer will connect over time. Execution is an event model connecting processes to environmental conditions and recipients groups.
