Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Create your own supercomputer with Java

By combining Java with the Web's collection of computers, you too can have the processing power you crave -- without buying a Cray

By Laurence Vanhelsuwé, JavaWorld.com, 01/01/97

Page 3 of 6

Since Web users don't surf the Web for days on end, the applet knows it's living on borrowed time. At any moment the user can decide that surfing real waves is more exciting than surfing cyberwaves, and so kill his browser along with our poor applet. Worker applets therefore are designed to be dispensible, thus conforming nicely to our current throw-away consumer society <sigh>. DAMPP is designed to cope with applets being killed prematurely; all it does is eventually re-issue the same job to another applet on another surfer's computer.

Whenever an applet does manage to complete its calculations, it contacts the JobMaster again to hand over its results (Step 3) - and then, like the male bee for which there is no more use, commits suicide.

If we switch our perspective to that of the JobMaster, we see two types of incoming communications: job requests and returned results. To simplify implementation and enhance performance, these two very different streams will use separate channels and both rely on UDP (User Datagram Protocol) for the underlying communication protocol. UDP is one of the TCP/IP protocols, sitting between IP and TCP as far as complexity and capabilities are concerned. I chose the UDP protocol over the more-frequently used TCP protocol for three reasons:

• UDP's connectionless communication mode is perfectly suited to our design
• UDP consumes less Internet bandwidth than TCP for the same amount of information transferred
• UDP is faster

UDP has one disadvantage: It does not guarantee delivery of information. (That is why TCP, which does guarantee delivery, is used more often.) But since the number of applet hosts on the Internet is, in all practicality, limitless, any lost results or any applet-server rendezvous gone wrong can be safely ignored. This is analoguous to your body not blinking an eyelid at the death of one of its own cells: Statistically and practically, it is a meaningless event. The design of the DAMPP computation engine can therefore rely, in a similar vein as our bodies, on massive built-in redundancy to achieve its goals with a very high degree of probability.

The overall picture is now clear: A swarm of applets passively and invisibly are being executed by client machines all over the world, contacting their home server to request jobs, executing those jobs and returning results to the server.

DAMPP implementation details

We are now ready to talk Java code!

The whole DAMPP system consists of just five classes: three classes for the applet and three for the server (one class is shared by both). These classes are, for the applet:

• WorkerApplet
• RayTrace (which extends WorkerApplet, instead of java.applet.Applet)

for the server:

• JobMaster
• ResultsReceiver

and shared by both:

• UDPUtils
  
  

At this proof-of-concept stage, the applet side already has been decomposed into a generic platform for parallel processing (WorkerApplet) and the application-specific code (RayTrace). Since this article is all about the distributed parallel processing, and not about raytracing, I shall not go into detail of how RayTrace works. So let's look at WorkerApplet's implementation instead.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.