Starting DJFractal

DJFractal uses several concepts:

Fractal computers and the fcs collection

A fractal computer takes djfractal.FractalData and returns a djfractal.FractalResult. FractalData are produced by the djfractal.Distributer following the algorithm describes in the Mandelbrot applet. When a FractalResult is returned, it is drawn on the screen. The algorithm try to draw most interesting areas first.

In order to distribute several FractalDatas to many FractalComputers, the distributer uses a collection of fractal computers called fcs. This collection is an implementation of the standard java.util.Collection.

To run DJFractal, two options are currently available (may change in the future):


Only one scheduler is used for a computation in order to distribute generated fractal datas to fractal computers. Choosing a good scheduler (and of course implementing them) is an art!

DJFractal uses Mandala

In fact, DJFractal uses Mandala to invoke methods of fractal computers asynchronously. Hence, DJFractal deals with a semi-transparent asynchronous proxy of a FractalComputer implementation (see Mandala Web Site for documentation).


Local examples

Distributed examples

  1. Creation of a remote active container which will receive our fractal computers:
    java mandala.jacob.remote.protocols.rmi.ServerRunner ActiveMap JNDI_ActiveMap_BindName

    Note 1: replace JNDI_ActiveMap_BindName by the name JNDI must bind the active map to.

    Note 2: replace rmi by udp or tcp for other protocols.

    Note 3: several properties may be defined when using JNDI. See JNDI documentation for details. If the protocol is rmi, then Mandala uses default properties so you don't have to specify any. An rmiregistry is also automatically started (if none are found).

  2. FCS instantiation: creation of the remote fcs collection used by DJFractal
    java mandala.jacob.remote.protocols.rmi.ServerRunner Collection JNDI_FCS_BindName

    (Same notes as above).
  3. Insertion of some fractal computers into a remote active container and addition of their semi-transparent asynchronous proxy into the remote fcs collection
    java FractalComputerClassName JNDI_FCS_URI JNDI_AciveMap_URI

    Note 1: CLASSPATH problems may happened here. Both the remote active container and the fcs remote collection must kwow where the FractalComputerClassName are available. Several solutions are possible:

    • Use the same CLASSPATH for each JVM (local or remote). This CLASSPATH must at least contain mandala.jar and djfractal.jar files;
    • Use a web server and specify a codebase such as java.rmi.server.codebase for the rmi protocol. Such a server is delivered in Mandala in the mandala.util.HTTPServer class.

    Note 2: Security Policies problems may happened here due to remote class loading. Ensure you've a well formed .java.policy file (see the policytool utility shipped with the JRE). See the Mandala FAQ and the Java documentation for details.

  4. Starting DJFractal:
    java djfractal.Main JNDI_FCS_URI

    (same notes as above)

SmartCard Grid specific examples

The CardProxy.main() method already runs an RMI active map in which she stores semi-transparent proxy of fractal computers running in smartcards. Hence, only the remote fcs collection needs to be instantiated (see FCS instantiation above).

  1. Runs the CardProxy:
    $ #CLASSPATH already contains "mandala.jar:djfractal.jar"
    $ export CLASSPATH=$CLASSPATH:$PCSC_DIR/lib/jpcsc.jar
    $ java samples.CardProxy JNDI_FCS_URI RMIActiveMapBindName

    (see notes on CLASSPATH problems above)
  2. Starting DJFractal:
    java djfractal.Main JNDI_FCS_URI

    (same notes as above)

    Back to the main page

    Last modified: Tue Feb 17 11:01:39 CET 2004