P3: P2P-based Middleware Enabling Transfer andAggregation of Computational Resources
Kazuyuki Shudo, Yoshio Tanaka, and Satoshi Sekiguchi
Grid Technology Research Center
National Institute of Advanced Industrial Science and Technology
AIST Tsukuba Central 2, Tsukuba, Ibaraki, 305-8568, Japan
shudo@ni.aist.go.jp, {yoshio.tanaka,s.sekiguchi}@aist.go.jp

Abstract
This paper presents middleware enabling mutual andequal transfer of computing power between individuals,
as in the original idea behind P2P, while also supporting large-scale distributed computation utilizing heterogeneous PCs. This goal is strongly supported by a network overlay over which peers can communicate witheach other directly and bidirectionally. We made use ofa general-purpose P2P library, JXTA, supporting thecommon requirements of P2P software, including network overlay. Other features of the P2P library, suchas ad-hoc self-organization, discovery and grouping ofpeers, also support our middleware eﬃciently. In thispaper, we propose and evaluate an application of thoseP2P concepts to virtual resource transfer and parallel computation with aggregated resources. However,such a P2P library imposes a certain amount of overhead on the middleware in terms of communication performance. Measured communication performance andthroughput of an application program shows the feasibility of the application of P2P concepts. The middlewareachieves 100×106 bps communication performance andover a 20 fold increase in speed with 32 computers, eventhough the granularity of workunits is as ﬁne as lessthan a second.

1

Introduction

Recently, activities have emerged that allow us to
use computational resources greater than we keep andmaintain ourselves. In these circumstances, we can use
others’ resources and pay-per-use for the supplied services. Application Service Providers (ASP) oﬀers suchcomputational services and Utility Computing should
enable transfer and trade of those services.
In Grid research and experiments, large-scale scarce
resources, such as high-end supercomputers, data storage, observation sensors and experimental devices, havebeen transferred virtually, and shared mutually and securely across multiple organizations.
Internet-wide distributed computing projects [1, 2]
are also resource transferring activities, but specialized(C) 2005 IEEEfor utilization of the computing power of individual
PCs. In those projects, participants can only donate
their resources. A participants can be only a “resource
provider” and the project owner is the only “resourceuser.” The two are asymmetric in capability. Suchasymmetry is contrary to the the original idea of P2P,
in which peers ought to have equal capability. Equality
in resource transfer means that everyone not only provides his/her resources to others but also uses others’
resources.
This paper presents middleware named P3 (Personal
Power Plant) which we designed and developed. It enables mutual and equal transfer of computing power
between individuals as called for in the original ideaof P2P. Any user of P3 can use any others’ resources
by submitting a computational job. It also supports
traditional large-scale distributed computation utilizing heterogeneous computers.
On the Internet of today, it is the normal situation that communication targets and directions are
restricted. Firewalls and NA(P)T impose such constraints on most computers. However, it is highly desirable that any computer can initiate communication
to other computers to achieve mutual transfer of resources. These constraints also restrict communication
patterns and programming models in parallel processing to the master-worker model, and the like.
We made use of a general-purpose P2P communication library which provides a network overlay to get
rid of the constraints. On the overlay any computercan communicate directly with other computers evenover an underlying restricted network with ﬁrewalls.
Most P2P software needs that sort of overlay and there
have been development eﬀorts, including a relay-based
approach, and a hole-punching approach. By re-using
these results, our middleware can beneﬁt from improvement of the existing eﬀorts.
Such a P2P library provides other beneﬁts, such asad-hoc self-organization of computers, discovery, andgrouping of computers. These functions can eﬃciently
support P2P distributed computation middleware, including P3. In this paper, we propose an application ofProc. Cluster Computing and Grid 2005 (CCGrid 2005, Fifth Int'l Workshop
on Global and Peer-to-Peer Computing), May. 2005.

these functions to this kind of middleware.
A P2P library undoubtedly provides us a rich setof features. But it is also certain that such a library
introduces performance overhead. We conﬁrmed thefeasibility of a P2P library, JXTA, as a base for distributed computation by measuring basic communication performance and application throughput. Theseexperiments also showed the current scalability of P3
in number of processing computers, and the workunit
processing throughput of a master in a master-workerstyle job.
The rest of the paper is organized as follows. Section 2 presents the usability of a network overlay forthe middleware, and a P2P library supporting network
overlay. In section 3, we propose an application of P2Pspeciﬁc functions for the middleware P3. Section 4 andsection 5 describe the design of the middleware, which
reﬂects the proposed application. Section 6 shows theresults of performance measurement, and the feasibilityof the application method for distributed computation.
In Section 7, we compare other middleware to P3.

2

A general-purpose P2P librarysupporting overlay

It is highly desirable to have a network overlay for P3 on
which all computers can communicate equally and bidirectionally each others because the goals of P3 include
mutual and equal transfer of computational resources.
We made use of a general-purpose P2P library, JXTA[3], providing a network overlay on which any computer can initiate communication to other computerseven though those computers are behind ﬁrewalls andNA(P)T. Such bidirectional and nonrestrictive communication also enables message-passing-style parallel processing, even though only a limited class of parallel processing, like master-worker, can usually be performed
with ﬁrewalls.
On a network overlay provided by JXTA, a computeris called peer and it is distinguished from others by
its peer ID. A communication target is speciﬁed using its peer ID. A peer can create and join multiple
peer groups, in which a peer discover other peers, peergroups and communication pipes.
These functions provided by JXTA are primitives
common to many kinds of P2P applications, such as ﬁlesharing, groupware, and instant messenger service. It
requires a great deal of labor to accomplish distributed
computation using the JXTA API directly. We developed middleware to facilitate management and development of parallel applications.

Figure 1: Job selection using the Host’s graphical shell.

3

Application of P2P functions
to P3

Besides network overlay, P2P-speciﬁc functions provided by JXTA can be naturally applied to, and efﬁciently support, distributed computation middleware,in addition to the usual P2P applications such as ﬁlesharing software.
Peer group: Parallel processing naturally involves
collective communication to control multiple computersand broadcast a message to all computers. P3 createsa JXTA-supported peer group called a ‘job group’ foreach job that is a submitted parallel application.
In a job group, in addition to collective communication by parallel applications, distribution of the parallel
applications and data ﬁles and job execution control are
performed. JXTA utilizes IP multicast and also relays
a message across networks to achieve this broadcast.
Discovery: JXTA supports server-less decentralized
discovery of resources, including peer, peer groups,
communication pipes, and so on. It enables ad-hoc selforganization of computers.
In P3, a resource user creates a job group for his/her
job and publishes an advertisement for the group. Resource providers discover the job group, determine
whether they want to contribute to the job, and join
the group if they do. Every computer is also discovered in the same way as a job.

4

Job Management Subsystem

P3 consists of a job management subsystem, a job monitor, and parallel programming libraries. This section
describes the job management subsystem, and the next
section depicts the libraries. The web-based job monitor shows the progress of a job and computers participating to the job group.
A P3 user manages a job using the following software.
• Host: The Host is a daemon program which a resource provider runs on his/her computer. It dis-(3) Share application code in the groupwith JXTA CMS service
Application
Application
Code
Code

(1) Create a Job Peer Group

Controller(2) Join the Job Peer Group

Job Peer Group

Figure 2: Job submission using the Controller’s graphical shell.

Controller

Base Peer Group

Figure 4: Controller’s job submission process.

Host

Host

Host

Host
Host
Controller

Job Peer Group

Controller

Host(4) Discover Application code(5) Obtain the code from a Controller

Controller
Job Peer Group

Application
Application
Code
Code

Job Peer Group

Job Peer Group(1) Discover Job Peer Groups(2) Decide to join a discovered job

Host
Host

Host
Host

(3) Join the Job Peer Group

Base Peer Group

Base Peer GroupNet Peer Group(always existing JXTA’s base group)

Figure 3: Organization of job management softwareand related peer groups.
covers a job group, receives a parallel application
representing the job, and hosts the application.
• Controller: The Controller is a tool using which a
resource user submits and controls jobs to a computer pool running Hosts (Figure 2).
The Host ﬁrst veriﬁes the digital signature of a discovered job. Secondly, if the Host is running in nonGUI mode, it decides whether to accept the job or notautonomically according to a policy supplied by theuser. A policy has declarations representing acceptablejobs, for example, by the name of a job or a job submitter. The user running the Host can also make thedecision by himself/herself on the GUI (Figure 1).
Figure 3 shows peer groups which Controllers andHosts construct. The base peer group is the base groupwhich all Controllers and Hosts create and join justafter it is invoked. A user uses his/her Controller to use
others’ computing power by submitting a job, or runsa Host to contribute compute power to others. Figures
4 and 5 illustrate job submission using the Controller,and job participation by a Host.
A P3 application is written in Java language, andthen compiled and packed into a JAR (Java Archive)
ﬁle. A resource user submits those JAR ﬁles and dataﬁles, using a Controller. A parallel application can use

Figure 5: Host’s job participation process.
parallel processing libraries (section 5) for inter-Hostcommunication. A Host can also invoke a natively compiled application. But it will have better support later
when P3 adopts a sandbox implementation, in which
native applications run securely and a resource provider
feels easy about accepting native applications.

5

Parallel Programming LibraryP3 provides two parallel programming libraries for application developers. One of the common goals of suchlibraries is easy development of parallel applications.
Developers should not have to deal with the details ofcommunication and the underlying distributed environment. We designed the libraries along these certain
rules. For example, one of the libraries, the masterworker library, can detect false computation results andan application on it does not have to do anything forthe detection.
Figure 6 shows the structure of the parallel programming libraries of P3.

5.1

Object Passing Library

We provided an object passing library to support multiple parallel programming models with less development
work. It is implemented directly on JXTA, hides theclass AMaster implements Master {Serializable getWorkerInitData() {return <data to initialize a worker>;}
start() {while (...) {WorkUnit wu = <a workunit>;// submit a workunit
submitWorkUnit(wu);}}Figure 6: Libraries supporting parallel programming.
interface ObjectPassing {void send(PeerID receiver, Serializable obj);
void broadcast(Serializable obj);
Envelope recv(PeerID sender);Envelope recv(PeerID sender, long timeout);}

Figure 8: Master side of an application program complying with the master-worker API.
class AWorker implements Worker {void init(Serializable initData) {// initialize this worker instance}// receive a message from anyone
Envelope recv();
Envelope recv(long timeout);// check if a message is available
boolean available();boolean available(PeerID sender);// register and unregister a message listenervoid addObjectPassingListener(
ObjectPassingListener listener);void removeObjectPassingListener(
ObjectPassingListener listener);}

Figure 7: API of object passing library.
complexity of the JXTA API, and presents a simple setof APIs to libraries relying on it. The master-worker
library and the message passing library could be easily
implemented because they rely on the object passing
library.
Figure 7 shows the API of the object passing library, by which an application can unicast or broadcast
Java objects, and receive them synchronously or asynchronously. A communication target is speciﬁed using
its peer ID. The raw JXTA API is suﬃciently complicated to support all needs of P2P software. The object
passing API wraps the JXTA API in a simple set ofAPIs to facilitate construction of various programming
libraries.

5.2

Message Passing Library

The message passing library also sends and receives
objects the same as the object passing library, but
the communication target is distinguished using a nonnegative integer rank, not a peer ID. This is the sameas the method used in MPI [4]. This library maintains correspondence between a rank and a peer ID

WorkResult process(WorkUnit wu) {// process a workunit and// return the result}}

Figure 9: Worker side of an application program complying with the master-worker API.
and translate one to the other.
The rank of a Host is assigned by a Controller whena job starts running, and a correspondence table is announced to all Hosts in the job group. Thus consistency of the message delivery target is assured because
all Hosts share the table.

5.3

Master-Worker Library

The master-worker library supports master-workerstyle parallel processing. An application developer
writes programs for the master-side program, theworker-side program, and the workunit, respectively.
A workunit represents a certain amount of work whichcollectively composes a job. It is delivered from a master to a worker and processed by the worker. Figures
8 and 9 show instances of a master-side program and aworker-side program.
Workunit delivery and scheduling are the charge ofthe master-worker library, not an application. A worker
can join or leave a job at any time, even though thejob has started running or the worker is processing aworkunit. This feature, ad-hoc joining and leaving, isimplemented entirely by the library, and an application
developer does not need to take care of it. If a worker
leaves a job group, a workunit delivered to the worker
but not completed is delivered to another worker, andthe whole of a job is accomplished after all.

We have to assume that there are malicious participants in Internet-wide distributed computing. They
may receive workunits and not process them. It is also
possible for them to return false calculation results toobstruct the job.
The former lazy worker problem is addressed by thetimeout-based redistribution of workunits. The latter
false results problem, is also dealt with by the masterworker library automatically. The library detects a
false result by voting [5]. In P3, if a false result is
detected, the workunit is distributed again. This detection process is performed completely by the library
and an application does not deal with false results.
A master distributes a single workunit m times toworkers and compares n returned calculation results.
The master accepts a result as the correct one if n results agree. An application developer can provide code
performing a custom matching process in which n results are examined, while the default code in P3 performs exact matching. Such a custom matching process
allows automatic veriﬁcation to work for results likeﬂoating-point values, which have some play in themand cannot be compared exactly.
A Host, not Controller, takes the role of master. In
P3, a Controller does only job management work. A
Host taking the master’s role is chosen by the Controller
submitting the job. It is possible that a Host stands asa candidate for master. A user can specify it wheninvoking a Host. If a Controller ﬁnds multiple standing
Hosts, it chooses one standing Host randomly. If there
is no standing Host, a Host is chosen randomly out of all
Hosts in the job group. The Controller announces thechosen Host as the master and all Hosts recognize it.
The current master selection process is naive, but it canbe improved on future work involving the capabilities ofHosts, like computing power and network bandwidth.
Consequently, one of the Hosts participating in amaster-worker-style job performs the work of a master.

5.4

Emulator

It is time-consuming work to develop and debug a parallel program, compared to a sequential program. The
reasons for this include diﬃculty in understanding parallel activities in the program in addition to longer
turnaround time to set up and run the program.
P3 includes an emulator of the object passing library. The emulator hosts and runs a parallel application on a single computer (Figure 6). The emulator supports both master-worker-style applications andmessage passing applications because both libraries relyon and use only the object passing API for communication. This generality of the emulator is derived from

Table 1: Communication latency.
TCP (C language)
0.062
TCP (Java language)
0.064
Message passing library 4.5(msec)
the generality of the object passing API and the layered
design of P3 libraries.

6

Performance Evaluation

This middleware beneﬁts from a rich set of P2P-speciﬁcfunctions provided by a P2P library as described in section 2 and 3. It is naturally expected that such richfunctions introduce a certain amount of overhead into
communication performance and application throughput. We measured both to evaluate the feasibility of
the P2P library, JXTA.
All experiments were carried out on a PC cluster which consists of 32 computers connected over
1000BASE-T Gigabit Ethernet. Each computer has
dual 2.4 GHz Intel Xeon processors and runs Linux
2.4.19. The Java runtime is HotSpot Server VM ofJava 2 SDK 1.4.2. The JXTA implementation is version
2.1 of the J2SE reference implementation. We ensured
that JXTA uses TCP as the communication protocol
by prohibiting use of HTTP.
Bandwidth on the Gigabit Ethernet LAN is muchbroader, and latency on it is smaller than that of thecurrent Internet. But such a rich environment can bringperformance, limitations, and overhead of the middleware itself, to light.

6.1

Communication
Throughput

LatencyandWe measured the communication latency and throughput of the message passing library of P3 and compared
the results with the latency and throughput of raw
TCP. The comparisons illustrate the overhead introduced by JXTA and the message passing library.
Table 1 shows one-way latency which was measured
by 1000 round trips of a 1 byte message. The JXTAbased message passing library took about 4 or 5 msec
processing time on computers involved in the communication. The latency was introduced mainly by JXTA
and the parallel programming libraries on it, not fromthe network itself, because the underlying TCP communication costs only 0.06 msec.
Throughput shown in Figure 10 is measured by 100
round trips of a variously sized message between 2 computers. In this paper, kilo (K) means 1024, not 1000,
mega (M) represents 10242 and so on. The highest

30

27.1

25

22.1

20.9

（msec）

20

20.2

15.4

15

13.8

10

13.4

5
0

0

4

8

12
16
20
Number of workers

24

28

32

Figure 12: Workunit handling time.
Figure 10: Throughput of the message passing libraryon JXTA.

Figure 11: TCP throughput.
throughput near 100 Mbps was achieved with 128 KB
sized messages. The same throughput can be achieved
if a message is larger than 128 KB because such a message can be divided into smaller chunks.
Raw TCP throughput reaches about 90% of the physical bandwidth of Gigabit Ethernet as shown in Figure
11. Compared to this, the JXTA-based message passing library could achieve only about 9% of the physical bandwidth. It is natural to conclude that such low
throughput is due to JXTA because the library is a thinlayer which just packs a Java object into a JXTA message and send it. A report [6] shows that JXTA 2.2.1
achieves 136.78 MB/s on a high-speed network Myrinet.
This result indicates that JXTA can potentially fulﬁll
the bandwidth of Gigabit Ethernet with appropriate
settings of underlying network layers. Anyway, Figure
10 demonstrates that the JXTA-based message passing
library could fulﬁll the bandwidth of today’s Internet
connection to homes and small oﬃces, which is currently up to about 100 × 106 Mbps.

6.2

Throughput of Workunit Passing

In master-worker-style parallel processing, a master isprone to be the bottleneck of the whole parallel com-putation as the number of workers increases. It is important to prevent this for eﬃcient parallel processing.
The work of a master consists of preparation of workunits, distribution of them, collection of processed results for each workunit, and post-processing of the results. Two processes, workunit distribution and resultcollection, are performed by the master-worker library,
not an application. Performance of the two processes
can be limiting factors of the entire parallel processing
eﬀort. They should be as eﬃcient as possible.
We measured the throughput represented by the
number of workunits (results) a master could distributeand collect in a unit of time. The time for a pair of distributing and collecting operations was measured by
distributing 200 workunits and then collecting calculated results for them. Workers do not perform any
work on a workunit and just return a result.
Figure 12 shows the results. A pair consisting of a
distribution and a collection took 28 msec in the worst
case and 13 msec in the best case. In other words, 35
workunits were processed a second in the worst case and76 workunits a second in the best case. This number
would be improved by increasing workers if the latency
was caused by the network, but unfortunately this is
not the case because the cause is message processing
time, not the network (section 6.1).
In an Internet-wide project operated by United Devices, the throughput has been adjusted to 120 workunits a second by adjustment of the size of the workunit[7]. The project involves tens of thousands of computers. It is natural to expect that the peak performanceof that system is several times as high as the averagethroughput of 120 workunits per second. It was foundthat JXTA and the master-worker library based on it
have to be improved several times if it hosts tens of
thousands computers with a single master. A P3 system with many computers have respective masters foreach job, though.

imbalance and limited speedup.
Speedup ratios shown in Figure 13 indicate that the
JXTA-based master-worker library can achieve about
a speedup of 20 fold with 32 workers even though aworkunit is adequately ﬁne grained as it completes ina second. Note that such ﬁne and severe granularity is
not realistic in an Internet-wide project. The granularity is usually adjusted to several or dozens of minutes.

7
Figure 13: Parallel eﬃciency in an RC5 key search according to the granularity of workunits.
Table 2: Calculation time per workunit.
Number of keys
in a workunit
Processing time (sec)
0x80001.40x40000.69
0x20000.36

6.3

Tolerance to Fine Grain Workunits

In a master-worker-style application, it becomes easy togain performance improvement as the granularity getscoarse because communication overhead is then hidden
by calculation time. We measured the speedup according the number of workers. The purpose of this experiment is estimation of tolerance to ﬁne-grain workunits.
The application used in this experiment is a bruteforce key search on the RC5 cryptosystem, which isthe same computation as that of Project RC5 of distributed.net [8]. It was implemented on P3’s masterworker library. The granularity of a workunit is adjusted using the number of key candidates in a workunit, which is set at 0x8000, 0x4000 and 0x2000 (hexadecimal notation). The number of workunits is 200
and the number of workers is varied from 1 to 32. The
performance is represented by the number of workunits
processed in a unit of time.
Figure 13 shows the speedup ratios according to the
granularity of workunits. The ideal speedup ratio is
not the same as the number of workers because thenumber of workunits is not a multiple of the numberof workers. Table 2 shows the calculation time of aworkunit. Load imbalance is the cause of the limited
speedup ratios with 0x2000-sized workunits. In the caseof 0x2000 and 24 workers, the total processing time wasonly 6.13 sec, and it takes about 1 sec for a worker
to start running from the time a master instructs theworkers to start. This varying delay caused the load

Related WorkP3 has the following features because its goal is mutualand equal transfer of computational resources.
• Anyone can use others’ resources by submitting ajob.
• A resource (PC) provider can choose jobs to which
his/her computer contributes.
P3 is compared with other distributed computing
middleware in this two respects in Table 3. At least,
job submission requires an application to be independent of the middleware. Table 3 shows application independence of middleware in place of the job submission
feature. Job selection, the latter feature, means thata calculating software (i.e. the Host of P3) can accept
multiple jobs simultaneously and can also reject a job.
JNGI [9] is a distributed computing framework. It isalso based on JXTA as P3 is. JNGI manages a large
number of peers eﬃciently by dividing peers into peergroups which have a limited number of peers each, while
P3 utilizes a peer group to wrap activities of an application into it. A JNGI paper [9] could not evaluate
JXTA’s feasibility for distributed computation because
the paper does not show the standard of speedup ratios obtained even though the experiment is performed
with heterogeneous computers. And the experiment
did not impose much of a load on JXTA. 150 workers
were involved in the experiment but the granularity ofa workunit is as coarse as 130 sec. The master deals
with only about one (150/130) workunit a second inthat situation.
BOINC [10] is middleware that helps creationand operation of public-resource computing projects.
BOINC is application-independent and provides a false
results detecting mechanism as P3 does. A computing
client of BOINC can accept multiple projects (jobs) simultaneously as P3 can, though a project originator
has to prepare a computer to host the project.
A number of Internet-wide distributed computing
middleware [11, 12, 13, 14] have been developed, andthey each have respective characteristics, like productlevel quality and special programming models. P3 canTable 3: Comparison between P3 and other Internet-wide distributed computing software.
Applicationindependent
middleware

Job selection
by resource
providerCommunication
protocolProgramming
Languages

P3

yes

yes

JXTA

Java

JNGI [9]BOINC [10]

yes
yes

no
yes

Java

XtremWeb [11]

yes

no

SETI@home [1]

no

no

JXTA
HTTP andoriginal
choosable(RMI, etc.)
HTTP

C, C++, etc.

Parallelprogramming
model
Master-worker,
Message passing
Master-worker
FileC, C++, etc.

File

C, C++, etc.

File

Detectionof false
results
yes
no
yes

yes

be diﬀerentiated by the job selection feature, automatic
false result detection, and support of message passing
programming.

[3] Project JXTA, “jxta.org.”
http://www.jxta.org/.

8[5] L. F. G. Sarmenta, “Sabotage-tolerance mechanisms for volunteer computing systems,” Future Generation Computer
Systems (FGCS), vol. 18, pp. 561–572, Mar. 2002.

Conclusion

We have presented middleware for mutual and equaltransfer of computing power between individuals. Another and traditional goal of the middleware is largescale distributed computing. We applied P2P functions, such as discovery and peer groups, provided by
JXTA, a general-purpose P2P library, to the middleware. Utilizing these functions, computers can construct a group ad-hoc, and the group can process a
submitted parallel job.
Performance measurement showed that P3 can ﬁll
100 Mbps bandwidth. Workunit handling time cameup to about 30 msec in the worst case and it should be
improved to host tens of thousands of computers in ajob. A master-worker-style job could achieve a 20 foldspeedup with 32 workers even with ﬁne grain workunits.
Future work includes conﬁrmation and improvementof quality and feasibility for real world use, while realapplications, including protein folding [15], have already been implemented. It would also be interesting to integrate P3 with Grid middleware which harnesses multiple PC clusters. In that case, P3 would
take charge of cluster management software like PBS
or LSF.

Acknowledgments
This work was partly supported by the Informationtechnology Promotion Agency (IPA) “Next Generation
Software Development” project.

References[1] E. Korpela, D. Werthimer, D. Anderson, J. Cobb, andM. Lebofsky, “SETI@home: Massively distributed computing for SETI,” in Computing in Science and Engineering,
vol. 3, pp. 78–83, January/February 2001.
[2] distributed.net, “distributed.net: Node zero.”
http://www.distributed.net/.

[4] Message Passing Interface Forum, MPI-2: Extensions to the
Message-Passing Interface, July 1997.

[6] M. Jan and D. A. Noblet, “Performance evaluation of JXTA
communication layers,” Tech. Rep. RR-5350, INRIA, Oct.
2004. http://www.inria.fr/rrrt/rr-5350.html.
[7] K. Ueno, “Personal communication,” June 2003.
[8] distributed.net, “Project RC5.”
http://www.distributed.net/rc5/.
[9] J. Verbeke, N. Nadgir, G. Ruetsch, and I. Sharapov,“Framework for peer-to-peer distributed computing in a heterogeneous, decentralized environment,” in Proc. of Third
International Workshop on Grid Computing (GRID 2002),
pp. 1–12, Nov. 2002.
[10] D. P. Anderson, “BOINC: A system for public-resource computing and storage,” in Proc. Fifth International Workshop
of Grid Computing (GRID 2004), pp. 4–10, Nov. 2004.
[11] G. Fedak, C. Germain, V. Néri, and F. Cappello,“XtremWeb: A generic global computing system,” in CCGrid2001 Special Session Global Computing on Personal
Devices, May 2001.
[12] GreenTea Technologies, Inc., “GreenTea Platform Whitepaper,” 2002.
[13] M. O. Neary, A. Phipps, S. Richman, and P. Cappello,“Javelin 2.0: Java-based parallel computing on the internet,” in Lecture Notes in Computer Science (LNCS) for
6th Int’l Euro-Par Conference (Euro-Par 2000), vol. 1900,
pp. 1231–1238, Springer Verlag, Aug. 2000.
[14] L. F. G. Sarmenta and S. Hirano, “Bayanihan: Building
and studying web-based volunteer computing systems using Java,” Future Generation Computer Systems (FGCS),
vol. 15, pp. 675–686, Oct. 1999.
[15] I. Ono, H. Fujiki, M. Ootsuka, N. Nakashima, N. Ono,and S. Tate, “Global optimization of protein 3-dimensional
structures in NMR by a genetic algorithm,” in Proc. of 2002
Congress on Evolutionary Computation, pp. 303–308, 2002.