A Peer-to-Peer Mechanism for Resource Location and Allocation over the Grid Hung-Chang Hsiao 1 , Mark Baker2 , and Chung-Ta King 3 1
Computer and Communication Research Center, National Tsing-Hua University, Taiwan 300,
[email protected] 2 The Distributed Systems Group, University of Portsmouth, UK, PO1 2EG,
[email protected] 3 Department of Computer Science, National Tsing-Hua University, Taiwan 300,
[email protected]
Abstract. Recent advances in P2P lookup overlays provide an appealing solution for distributed search without relying on a single database server. In addition to performing resource discovery, these P2P substrates also offer membership management for dynamic peers. In this paper, we propose a publicly shared architecture called VC2 A that takes advantage of a P2P lookup substrate for computational applications. VC2 A targets computational master-slave applications. An application running in VC2 A dynamically allocates resources from the system on the fly. These allocated resources then self-manage and -heal. We have implemented an architecture based on our previous efforts that include an enhanced P2P lookup overlay and a mobile agent system on top of this overlay. We show that VC2 A is not only scalable but robust, and takes advantage of heterogeneity of the resources.
1 Introduction Peer-to-peer (P2P) computing research is extremely active. The first generation of P2P substrates, such as Gnutella, implemented the flooding-based search protocol to locate resources. Due to the potential burden of network traffic introduced by the flooding protocol, and the consequential inefficiency of resource discovery, research projects such as CAN, Chord, Pastry, Tapestry and Tornado implement distributed hash tables (DHT) for efficiently locating resources [1]. The DHT-based P2P overlay is thus appealing, and can serve as an ideal overlay infrastructures for managing resource information. A DHT-based P2P overlay, however, is unable to offer complex search capabilities for resource discovery. Recent proposals have shown that a DHT-based P2P overlay can be enhanced to perform keyword and/or range searches [1]. One use of DHT-based P2P substrates is for computational applications, which are based on the master-slave programming paradigm. Here, the master is responsible for control the workflow of the entire task, which includes providing the input to, and collecting output from, computational tasks, while the slaves perform the computation.
This work was supported in part by National Science Council, Taiwan, under Grant NSC 932752-E-007-004-PAE, and National Center for High-performance Computing, under Grant NCHC–KING 010200.
Examples of this type of P2P application includes SETI@home, computational biology, and parameter-sweep applications. In this study, we are interested in designing a “publicly shared” P2P substrate that allows the execution of multiple master-slave applications. Unlike a proprietary design, such as SETI@home, running multiple applications in a shared infrastructure can have several benefits. For example, (1) application developers only need to take care of the development of their applications regardless of design, deployment and maintenance the infrastructure. (2) A resource provider can have a simple, but complete, control of their resources and can delegate its control to the shared substrate without paying attention to each application that may be executed using their resources, and (3) running multiple applications can further increase the utilization of resources in the substrate, and pooling resources together increases the possibility for an application to discover those resources that can meet the application’s demand. Running these applications in a shared substrate can have the following requirements. (1) Expressiveness. First, the substrate should be capable of allowing an application to designate what specific characteristics allocated resources should be met. These parameters could include, for example, the current loads of the designated resources, the processor speed, or the available memory size. (2) Code mobility. The shared infrastructure should be capable of running any application. It could be possible that the infrastructure does not know what applications will be deployed in advance and how many resources will be allocated to a particular application. The shared infrastructure should allow an application to arbitrarily deploy its computational logic at any place within the playground formed by the resources that are allocated on-the-fly. (3) Autonomy. Since resources in the substrate may have their own utilisation plans and each of these plans may vary, resources allocated to a particular application should not violate their local policies 4 . In addition, resources allocated to an application should self-configure and -heal in order to relieve the burden on an application developer of needing to set up the dynamically formed execution environment. (4) Robustness. In a publicly shared environment, resources may dynamically join and leave the system. The substrate should be reliable enough for any application. A robust computing environment can also mitigate the load of an application developer to handle failure during the execution of his application. It is unlikely to rely on a central control point for managing information, and allocating and scheduling resources. This is because the central point can become the single point of failure. (5) Scalability. The number of resources appearing in the shared environment is unknown, but may be very large. An approach based on a central point of management will become a performance bottleneck if the number of resources is large. A substrate should thus be designed with the scalability in mind to accommodate any number of resources allocated to an application. (6) High performance. The resources allocated to an application should be effectively utilized. This will accelerate the execution of the application. A P2P infrastructure for supporting computational applications should bear performance criteria in mind. 4
The local policy that is defined for a resource can be for example, the load that a resource can sustain, or the time over which it can be. The local policy may further depend on the policy defined by its domain administrator. Defining a local policy is out of the scope of this paper.
In this work, we propose a publicly shared P2P infrastructure architecture called VC2 A for computational applications. Particularly, we implement the VC 2 A architecture using our previous efforts, i.e., a DHT-based overlay called Tornado [2] along with an enhanced search ability [1]. The enhanced lookup overlay allows an application to efficiently and effectively perform similarity and range searches for resources in a large and dynamic environment. In addition, VC 2 A is integrated with a mobile agent system called Armada [3]. In VC 2 A, an application designer develops their application using Armada agents. Agents in Armada can be deployed on any resources that are dynamically discovered; they can communicate with each other regardless of their movements. VC2 A is thus programmable on the fly. Since in VC 2 A a resource defines its own local policy and helps overall computation according to this local policy. When the resources are discovered for an application without violating their local policies, they self form an individual tree overlay 5 . The tree overlay self manages without involving any effort from the application. It can arbitrarily be scaled to any size while each resource only maintains a constant number of members in the associated tree. VC 2 A ensures that a tree overlay is robust by taking advantage of the heterogeneity of resources. Moreover, a tree in VC2 A is nearly balanced. This allows the spread of computational tasks to the allocated resources and to collect the results, rapidly. This also provides the responsiveness needed for maintenance. Our contributions of this work include that (1) we propose a novel architecture to leverage DHTs for grid resource discovery. (2) We design a scalable tree-based overlay which robustly organizes allocated resources, helps disseminate computational tasks, and provide an execution environment for mobile agents. (3) We integrate the DHTbased and tree-based overlays for resource discovery and organization.
2 VC2 A Overview Figure 1(a) shows an example that illustrates the operations of VC 2 A. Each peer in VC2 A initially publishes its resource descriptor to the system using the Tornado DHT interfaces (i.e., the publish interface). For example, node 3 publishes its resource descriptor to nodes 1, 6 and 8. A peer that has a computational task to accomplish then discovers the resources that can satisfy its requirements using the lookup interface. In Figure 1(b), node 0 issues the lookup requests to nodes 2, 4, 5 and 7. Those peers receiving the lookup requests inform the nodes (i.e., nodes 4, 8, 2 and 1) that can provide designated resources for the computational demands (see Figure 1(c)). If the matched peers can accept the computational tasks (i.e., nodes 2, 4 and 8 in Figure 1(d)) according to their local policies, they self-form a tree overlay, where the root of the tree is the entry point that can accept the tasks submitted by the task producer (Figures 1(e) and (f)). We assume that a peer registers its resource descriptor into the system using enhanced DHT lookup interfaces. Enhanced DHTs include PeerSearch, Meteorograph, Neuron, Squid and XenoSearch [1]. These enhanced DHTs can efficiently perform keyword and/or range searches, for example. Figure 2 shows an example of describing de5
Actually, VC2 A maintains “tree-like” overlays in the system, where redundant links in a tree are used for tolerating faults. We will not differentiate the terms–“tree” and “tree-like” overlays.
7
6
4
6
8
5 publish
5
publish
0
4
Tasks
publish
3
7 lookup lookup
6
8
2
Join
0 Join
(c)
7
6
8
5
Join 4
1
8
4
0 Tasks
3
7
5
4 Tasks
0
8 2
4 3
1
1
2
2
2
(d)
(e)
0 Tasks
1
2
7
3
inform inform
(b)
5 4
inform 3
1
(a) 6
8
4
0 lookupTasks
2
7
5 inform
lookup 3
1
6
8
Task 1
8
Task 2
2 Task 3
(f)
Fig. 1. An example of VC2 A consisting of nine nodes, where (a) node 3 publishes its resource descriptor to the system, (b) node 0 looks up the resources for its computational task by consulting nodes 2, 4, 5 and 7, (c) nodes 2, 4, 5 and 7 respectively inform nodes 4, 8, 2, and 1 that have the designated resources, (d) nodes 2, 4 and 8 can help perform the computational task for node 0, (e) nodes 2, 4 and 8 self-form a tree overlay for receiving the computational tasks issued by node 0, and (e) node 0 submits the tasks to the tree overlay using Armada agents
manded resources. VC 2 A can discover resources that have the attribute values shown in Lines 4 and 5 of Figure 2 via searching by keywords as well as the range search for Lines 1, 2, 3 and 6. A peer publishes its resources using the similar description.
1: 2: 3: 4: 5: 6:
CPU Main memory Disk OS Domain Idle
≥ 1.5 GHz ≥ 256 Mbytes ≥ 256 Mbytes & ≤ 1024 Gbytes Linux kernel 2.4 version cs.nthu.edu.tw | nchc.gov.tw from GMT 10:00 PM to GMT 7:00 AM
Fig. 2. An example of a resource descriptor VC2 A is designed with scalability, high performance and robustness in mind. For scalability, VC2 A is based on a scalable DHT-based P2P overlay (i.e., Tornado). Each node in Tornado only maintains a number of O(k × log nk ) connections, where k is a constant and n is the total number of nodes appearing in the system. In addition, a node joining in a tree overlay for accepting computational tasks only maintains a constant number of connections to its tree members. For high performance and robustness, by placing more capable nodes near the job producer, tasks can be more rapidly assigned to more capable nodes and the overall system’s throughput is boosted. Note that a node in VC 2 A may join multiple trees if its corresponding resource descriptor matches several different lookup requests and meanwhile it is capable of performing multiple tasks without violating its local policy. We also note that the publish, lookup, inform and join messages are routed using the routing algorithm provided by the DHT-based overlay. The routing algorithm ensures that the routing is resilient.
Notations Without loss of generality, we assume that the capability 6 of a node x is measured by the maximum number of connections (we note that connections maintained in a VC2 A overlay are duplex TCP/IP links) that it can accommodate, which is denoted c(x). Based on c(x), x estimates the maximum number p of connections m i (x) that are used by an overlay i. If x joins p tree overlays, then j=1 mj (x) ≤ c(x). Note that the overlays may have different sizes. The larger the overlay, the larger the number of connections allocated. To simplify the discussion, we concentrate on operations that manipulate “one” overlay. We thus drop the subscript i in the following discussion, i.e., using m(x) instead of m i (x). A node x will maintain at most m(x) pointers pointing to its children (x.child[i], where i = 1, 2, 3, . . . , m(x) − 1) and parent (x.parent). These nodes are the active neighbors of x. The nodes x.parent and x.child[i] are initialized with null pointers. Node x also maintains a look-ahead cache indicating potential parent nodes of x. Each entry in the look-ahead cache consists of the IP address, the port number and the maximum number of connections of a node that can become the parent of x. Finally, x maintains a value height(x) that indicates its height in the tree, where height(x) = 0 initially. The variable d(x) is used to indicate the number of connections in use. Self-Configuration and -Healing When a node intends to join a tree overlay, it first connects to the root node of the tree corresponding to the overlay. The two nodes then compare their heights. Since the height of the new node is always zero, it will become the child of the root, as long as the root node has not reached its capability limit, i.e., the maximum number of connections. In general, a node x becomes a child of another node y if y has not reached the limit of its capacity and height(y) > height(x). On the other hand, if the root of the tree has exhausted its capacity, it designates a child that has the maximum remaining capacity as the parent of the new node. If no child node can accept that node as a child due to capacity limitation, the root node randomly picks a child to forward the joining request of the new node. That child node performs similar operations as the root node until a child can accommodate the joining request of the new node. After the new node joins the overlay, the nodes along the path to the root update their heights if necessary. Due to the space limitation, we refer readers to [4] for the details. A VC2 A tree may be fragmented due to node failure or departure. To solve this problem, each node periodically broadcasts its IP address, port number and maximum capacity to its children. The broadcast horizon is specified by a small constant s. If a node receives such a message, it pushes the associated IP address, port number and capacity value into its look-ahead cache. In this way, a node can “look ahead” s nodes (including the parent) to the tree root. A node x first checks whether its parent is active. If the parent is not active, the node then creates a connection to the closest ascendant node u, which is found through the look-ahead cache and has a free connection. If u does not have a free connection, then it helps to discover a descendant node that can accept x’s connection. Note that if the 6
A node’s capacity (in terms of number of connections) is defined by mixing its “static” machine characteristics such as the computational power and communication speed as well as the policy of how the resource provider contributes his resources.
ascendant nodes maintained in the look-ahead cache are not available, x consults the root of the tree for rejoining. Since nodes periodically monitor the “aliveness” of their parent, the monitoring message can piggyback the value height(x) to the parent. The parent can then determine whether its height is maintained according to the height values from all the children. We note that there must be a sibling of x, j, such that height(x.parent) = height(j) + 1, where height(j) is the maximum compared with other siblings. If the height value of x’s parent is not equal to height(j) + 1, height(j) + 1 is taken as the height value of x’s parent. Exploiting Heterogeneity of Nodes The algorithms mentioned above do not guarantee that nodes with higher capacities are placed close to the root of a tree, because a joining node may be connected to a node whose capacity is smaller than it own. Thus, a node in VC2 A needs to monitor the capacities of its children and to determine whether a child node more capable of providing connections to accommodate new nodes. If a node can be replaced, the node is moved to the position of the child node in the tree. Notably, a node is only replaced by one of its children by locking the data structures it maintains. We note that in our algorithm we not only organize more capable nodes around the task producer in order to boost the system throughput, but ensure a robust tree overlay. This is because volatile nodes will not appear in the nearby of the task producer and will not fail the tree structure. This thus allows the task producer to submit its jobs to the peers in the tree overlay. Tasks Multicasting and Termination The task producer submits its computational tasks using Armada mobile agents to the root of its associated overlay tree. The root then clones the mobile agents and migrates the cloned agents to each of its children. A node receiving an agent performs a similar operation. In addition, to submit a cloned agent, an installed agent retrieves the associated data set before performing the computation associated with that agent. In VC 2 A an agent will be automatically programmed by implicitly specifying its input as its parent agent or explicitly designating a location outside the system. Similarly, an agent can designate its output using the same way. We note that an application developer may manually configure the input and output for an agent. In addition, VC 2 A allows an agent to designate the communication protocol used, such as HTTP and FTP, in order to interact with an entity that is not in the system. If an agent has the input data set to compute and the node hosting the agent is not overloaded according to its local policy, then the agent performs the computation. If the agent does not overload its hosting peer and its input queue is not full, it tries to obtain (or wait for) another data set from its parent agent for further computation. We note that (1) the delivery of data sets and the computation performed by the agent can be handled, simultaneously. In the current implementation, a node computes its tasks, sends tasks in its input queue, and returns the results stored in its output queue in the round-robin fashion. (2) It is possible that a number of k input data sets can be only sent k children nodes out of the k requesting ones, where k < k. In such a case, the parent node selects top-k more capable peers from k ones to receive the input data sets. (3) We also note that the scheduling of computation and communication in order
to maximize the utilization of resources in a tree overlay is an orthogonal design space. In addition, with the application knowledge to push a task to its children or pull a task from its parent is left to the application developer. VC2 A is based on the Armada mobile agent system in which agents in different locations can communicate with each other. This allows VC 2 A to support an application that has complex interactions among agents. We preserve this capability for investigating applications that have complex communications among agents in the future. For termination of an application, the task producer broadcasts a termination message to the root of the associated tree overlay. The termination message is then broadcasted down to the tree. Each of the tree nodes receiving the termination message leaves the tree overlay. Multiple Tree Overlays We have discussed operations that manipulate a single overlay. However, a node may join several overlays. Here, we discuss how a node manages the available connections for the participating overlays. Initially, a VC2 A node x allocates an equal number of connections to each of the overlays that it joins. Assume that x may participate in g overlays at most. Then, x will have mi (x) = c(x) g , where i = 1, 2, 3, . . . , g. The node periodically monitors the number of connections (d i (x)) used by the i th participating overlay. Itthen assigns the con nections to the participating overlays proportionally as m i (x) =
gdi (x) j=1 dj (x)
× c(x) .
Consequently, if an overlay comprises of a small number of nodes, these nodes must use few connections to link with each other. The above assignment ensures that nodes use few connections to participate in a small overlay and more connections for a large overlay. This reduces the height of a tree since nodes joining in a large overlay have relatively large degrees; can allow tasks to be rapidly sent to nodes by traversing a smaller number of nodes. To estimate the size of a tree overlay, the root node of a tree broadcasts a counting message to each of its child nodes. Upon receiving a counting message from the parent, a node recursively performs the same operation. If a node (i.e., a leaf node) does not have any children, it returns the number of children (i.e., zero) to its parent. When a node receives the number of child nodes from each of its children, it can then estimates the total number of its descendant nodes and reports such a number to its parent. In this way, the root node can eventually determine the total number of nodes in the tree. It then broadcasts such a value to each tree member. Finally, a peer can determine how many connections should be allocated for each tree overlay that it participates. We show that the depth of a tree overlay is bounded by the logarithmical size of a tree overlay (see [4]). Clustering Nearby Nodes It is possible that an application may restrict the resources that meet its requirements on their network-specific constrains in order to conform to the performance aim of the application. For example, an application may want to allocate resources that are geographically nearby by designating the delay or the bandwidth between the task producer and the resources having above or below a certain value. If so, in the absence of network weather services resources in VC 2 A that can meet an
application’s demand need to measure the delay or bandwidth between the designated location and itself. Only those resources that satisfy the delay or bandwidth requirement can join the tree overlay formed for the application. Security First, malicious peers have several ways to potentially break down VC 2 A. For example, a malicious peer may not honestly perform the protocol operations, such as, publish, lookup, inform and join. To prevent malicious peers joining the system, VC2 A includes additional “authentication nodes”. It should be noted that these nodes are not used for any other VC 2 A purpose, apart from authentication. A node intending to join the system needs to access an authentication node, and only after being authenticated can nodes join VC 2 A and participate in a computation. However, authenticated nodes that have joined the system may be compromised, i.e., authenticated nodes may not be trusted. Since VC 2 A integrates the security mechanism in [5], the compromised nodes cannot modify the protocol codes and thus change their behavior (e.g., by stopping forwarding or maliciously forward a message to another compromised node). This ensures that a message will be correctly forwarded to its destination. Third, it is possible that a number of compromised nodes could introduce cycles to the system by repeatedly and rapidly joining and leaving the system. Since VC 2 A is implemented on top of the resilient DHT-based overlay, which can self-heal and consequently tolerate cycles introduced by compromised nodes. Unless all VC 2 A nodes are compromised, it is difficult to fail the entire system. Possibly, malicious nodes could overhear messages exchanged by overlay nodes and then tailor their messages to break down the system. For such a case, VC 2 A is further integrated with the secure communication mechanism [6] proposed for DHT-based overlay networks. The secure communication mechanism can set up secure channels among overlay peers. Fourth, compromised nodes can be used to “attack” the system. This can be achieved by letting compromised nodes send a large amount of normal traffic (e.g., the join messages) to the root of a tree overlay. In this way, the root could be busy processing large amounts of normal traffic, which may prevent further participants from joining the tree. The root may also be unable to clone agents for its established child nodes, or send tasks to, and receives results back from these nodes. For relieving such an attack, the root (denoted as r) of a tree overlay designates a few nodes in VC2 A as “secret” entry points into the overlay. r can only accept messages from its designated secret nodes. These secret nodes ensure the rate-limited communication (r informs the secret nodes its maximum communication bandwidth). To select k secret points requires k distinct hash functions (H i , where i = 1, 2, . . . , k). The secret nodes will have the node ID closest to H i (name) (this can be simply achieved by routing a message to the node, i.e., the secret node, that has the closest ID to H i (name)) and the name is r’s IP address. Thus, node x in VC 2 A, which meets the resource description and intends to join r’s tree, sends a join message with the destination address r. The join message will reach one of the secret node that can help x to join r’s tree. Since the message communication in VC 2 A is a multi-hop end-to-end communication, compromised nodes cannot easily determine the ultimate destination (i.e., the secret nodes) of a message transfer by simply eavesdropping the source and the destination fields of one TCP/IP end-to-end connection. To determine which nodes are secret
nodes requires globally monitoring all communication traffic in VC 2 A and then analyzing the traffic. Consequently, compromised nodes cannot simply shut down the secret nodes in order to break down the associated tree overlay. Finally, compromised nodes could arbitrarily send a large amount of overlay-irrelevant traffic (e.g., the TCP SYN flooding) to a tree root at the same time in order to the shut down the root. For such a case, the tree root needs to set up a few proxy nodes (the proxy node is not part of VC 2 A computation) in its vicinity. The proxy node can act as a router that is responsible for forwarding network messages to the tree root. The tree root simply configures those proxy nodes to accept traffic from the secret nodes that had been previously established. Traffic that is not from a secret node will be discarded. Note that if the proxy nodes are the high-powered routers, attackers cannot easily attack the network routers since these devices can discard traffic that is not from the secret nodes at line speed.
3 Comparison with Alternatives We compare the previously mentioned architectures with VC 2 A from two aspects: resource discovery and organization of allocated resources. Both are the fundamental components for assembling a computational infrastructure. The details including references can be found in [4]. Resource discovery Recent projects such as SETI@home/BONIC, Entropia and XtremWeb have taken the first steps towards realizing a large-scale systems to include worldwide desktop machines. Both systems employ a central server to manage the participating resources. However, the use of a central control leads to the usual issues, such as the performance bottlenecks and a single point of failure. In contrast, OurGrid and NaradaBrokering are based on a Gnutella-like P2P network model that adopts broadcasting to discover resources without relying on a central server. Although broadcasting does not have the issues as those introduced by SETI@home/BONIC, Entropia and XtremWeb, it may generate a significant amount of traffic and does not have the guarantees for discovering demanded resources in terms of efficiency and effectiveness. Triana is a workflow management system, which is based on JXTA. JXTA does not exactly mandate how resource discovery is done. A possible decentralized discovery mechanism in JXTA is through utilizing rendezvous peers. Resource providers publish their resource metadata information to rendezvous peers. A set of rendezvous peers acts as a search network that implements a Gnutella-like search protocol. To discover resources is to send a query message to the search network. Butt et al. [7] propose to take advantage of network locality for resource discovery by exploiting the geographically close neighbors in a DHT-based overlay. However, nearby resources may not meet the request demand. Although their design has incorporated with an expanded ring search mechanism, this may lead to the system to degenerate into a broadcasting-based P2P network similar to Gnutella. In contrast to previous architectures, VC 2 A is based on the enhanced DHTs [1] to support complex queries. These enhanced DHTs provide the efficient performance bounds for discovering the demanded resources.
Organization of allocated resources To our best knowledge, SETI@home/BONIC, Entropia, XtremWeb, OurGrid and Triana all rely on a central control point to manage resources that satisfy the demand of the requester. The central point in SETI@home/BONIC, Entropia and XtremWeb is a standalone sever, while in OurGrid and Triana the requester handles all requested peers. Clearly, this is a non-scalable design. Butt et al. extend Condor to the Internet using Pastry. No explicit mechanism for managing resources discovered from different Condor pools is provided. The architecture Butt et al. propose strongly relies on each central manager of each Condor pool. Similarly, NaradaBrokering does not offer the ability for discovered resources to selfmanage. However, NaradaBrokering provides the messaging capabilities including the publishing/subscribing and the secure channel for nodes in the system. In VC2 A, discovered resources autonomously structure into a tree overlay according to their capabilities without involving entities that not are not allocated in the publicly shared infrastructure of VC 2 A. Such a design is not only scalable, but can tolerate faults. Moreover, this allows the requester to utilize relatively more capable resources in order to speed up their computation.
4 Conclusions and Project Status We have presented the design of P2P-based system called VC 2 A. VC2 A is based on a DHT-based overlay, which further incorporates a tree structured P2P overlays and takes advantage of nodes’ heterogeneity. We have shown how to manage the overlay and manipulate it using mobile agents. Due to space limitation, we refer readers the performance results of VC 2 A to [4]. We have prototyped VC 2 A and will implement a real application to examine the system in the near future. The results will be reported when they are available, as will be our experiences using the system.
References 1. Hsiao, H.C., King, C.T.: Resource Discovery in Peer-to-Peer Infrastructure. In: High Performance Computing: Paradigm and Infrastructure. John Wiley & Sons Ltd (2004) 2. Hsiao, H.C., King, C.T.: Tornado: A Capability-Aware Peer-to-Peer Storage Overlay. Journal of Parallel and Distributed Computing 64 (2004) 747–758 3. Hsiao, H.C., Huang, P.S., Banerjee, A., King, C.T.: Taking Advantage of the Overlay Geometrical Structures for Mobile Agent Communications. In: Proceedings of the International Parallel and Distributed Processing Symposium, IEEE Computer Society (2004) 4. Hsiao, H.C., Baker, M., King, C.T.: VC 2 A: Virtual Cluster Computing Architecture. Technical report, Department of Computer Science, National Tsing-Hua University, Hsinchu, Taiwan (2004) http://www.cs.nthu.edu.tw/∼hchsiao/projects.htm. 5. Castro, M., Druschel, P., Ganesh, A., Rowstron, A., Wallach, D.S.: Security for Structured Peer-to-Peer Overlay Networks. In: Proceedings of the International Symposium on Operating Systems Design and Implementaion. (2002) 6. Freedman, M.J., Morris, R.: Tarzan: A Peer-to-Peer Anonymizing Network Layer. In: Proceedings of the International Conference on Computer and Communications Security, ACM Press (2002) 193–206 7. Butt, A.R., Zhang, R., Hu, Y.C.: A Self-Organizing Flock of Condors. In: Proceedings of the International Conference on High Performance Networking and Computing. (2003)
