Application demonstrates major benefits of ProActive PDC like ease of distributed programming (using "Active Objects"), speedup through parallel calculation, flexibility in terms of choosing nodes [see note 1] and ease of synchronization. Several users can collaboratively view and manipulate a 3D scene, which involves election and synchronization issues. The image for the scene is calculated in parallel by a dynamic set of rendering engines using a ray tracing algorithm, everything being controlled by a central dispatcher.

We will discuss briefly about the C3D application with intent of contrasting Proactive PDC and RMI.

Dispatcher, Client frame and Rendering Engines can run on the same machine or any machine on the network (you can make any machine on the internet to act as a node). Dispatcher, Client and Engine are instantiated as an "Active Object" which allows it to transparently reside on a remote machine. After the initial set up which involves starting rmi registry and registering name of the engines on every node. We can then start the dispatcher. Dispatcher accepts file with addresses of the rendering engines as the argument and waits for user to register.

[1] First user registering decides which scene to be rendered. When user registers dispatcher would create a new scene and export rendering engines to every node where rmi registry is running. Dispatcher divides scene created into intervals using formula No of Intervals = No of Engines * 3. Rendering Engines are now ready to server any requests from the Dispatcher.

[2] Dispatcher assigns Intervals one by one to the rendering engines. It does by making an asynchronous call to the render method of the rendering engine. Dispatcher continues execution in its own thread while engines are rendering the scene.

[3] Whenever Engine is done with rendering it returns the results to Dispatcher by invoking a method "set pixel". Since all rendering engines would return values to the Dispatcher, return calls have to be synchronized. The Active Object can handle return calls implicitly or explicitly. Default policy of handling calls on methods of an Active Object is FIFO. Various methods [See Note 2]are available in the class Proactive of Proactive PDC to formulate a strategy for handling calls.

[4] Upon receiving rendered interval from the engines it does two things. It forwards the Interval to all user frames (again it is asynchronous call) by calling setpixel method of all the C3Duser classes. Rendered Intervals are displayed on the all the User screens. Again a policy can be formulated to handle simultaneous invocations on the methods of C3Duser class. And secondly it assigns next Interval if there are any left to the some engine.

[5] Once scenes are displayed on the user screens Dispatcher waits for client requests. For eg If say it receives a request to rotate left Dispatcher would start election if there are other requests by other users and decision would be made based on majority opinion, if there are none it rotates the scene left. Again it accomplishes by dividing the scene into Intervals and assigning each Interval to each engines, basically repeating steps 1 to 4.

I feel developing the functionality of the above application with RMI is extremely difficult if not impossible. Due to following reasons

.

RMI does not directly support callbacks. With respect to above application after assigning an Interval to one of the engines dispatcher has to wait until engine responds after rendering the scene. Then dispatcher can go on to assign the next interval to other engine and again wait for the response. Basically we are talking about synchronous communication. Thus applications, which require to use power of multiple machines RMI, would be useless.

ProActive PDC in contrast supports Asynchronous communication implicitly as well as explicitly using Active Objects. Active Objects can be compared to the object providing services in RMI, it is composed of two objects the body and standard body. Body object handles the asynchronous communication. It has a queue, which holds method invocations on the Active Object, which by default, are handled through FIFO.

With reference to diagram of the previous page we will try to understand callback handling in ProActive PDC. Above shows a pictorial representation of the state of queue in the body, assuming due to network delays all the callbacks from the rendering engines come at the same time. If there is no explicit policy for handling callbacks then invocations are handled FIFO manner thereby saying SetPixel method is invoked with Interval object rendered by engine0, then the Interval is sent to the client which displays that interval and a new interval is assigned to the engine0. Then next method invocation (engine1) is handled.

In applications where processing power of multiple machines have to be tapped, RMI miserably fails. Since it does not support seamless migration of objects from one JVM to another. C3D is designed using ProActive PDC in a way that it can dynamically add and remove engines. Also location of engines is not a constraint since any connected machine (via local network or internet) can be declared as a node. Only thing required is to set classpath pointing to the ProActive PDC on the machine and binding a name of the engine to rmi registry.

Programming with RMI becomes very difficult when client also has to serve as server. This is because of the restrictions with RMI, which dictates server has to implement all the methods, declared by interface extending remote. Also this might entails changing inheritance hierarchy of the object. With ProActive PDC making a client to act, as server is simple as instantiating a new object and invoking methods of the object. In C3D Dispatcher act as a client to engines and as a server to Client object at the same time.

Running C3D was not "icing on the cake" partly due to misleading instructions provided on the website. So I thought for those who are interested I will give some pointers.

My Comments:

Automatically created folder proactive-tmp to hold stubs is located in different directories for different machines. In case of win 98 it was created under C:\Windows and in case win 2000 it was created under C:\Documents and Settings\Administrator. We don’t have the control over selecting the location for this folder. Make sure your classpath is modified to point to classes of ProActive PDC library and also to proactive-tmp wherever it is located.

My comments:

Don’t download C3D application from the Download and run page that is old version of C3D. You will get source code of C3D with the library you download. You need to compile all the classes manually and place them in a proper folder. Also make sure you set your classpath points to the ProActive PDC library in the console you run the rmi registry. Other then that the instructions provided are adequate to make you run the application.

• You can make your rendering engines run anywhere. Even on a machine located in Alaska provided it is connected to Internet and has JVM and ProActive library installed properly with rmi registry running. Though it might defeat the purpose of designing an distributed application, since network delays would nullify gains due to extra processing power.
• Anytime you get "stub not found …." error more likely libraries run time environment is not able to find proactive-tmp folder on the machine(where the Dispatcher is running).
• All the class files for the rendering engines just has to be present on the machine where dispatcher is running. The remote machine where rendering engine is suppose to run just needs to have the JVM and Proactive Library Installed.
• I feel it would be very good exercise for the begineers in Distributed systems to understand the source code of a application created for distributed environment. It greatly helps in understanding the "problems" that are faced by distributed applications.

Above shows a screen shot of an dispatcher with one rendering engines on the localnode and another rendering engine on the other remote node connected via internet. The next screen shot shows the screen as seen by user.It was hard to compare the processing power gains since some of gains of running the application on multiple machines would be nullified by network delays.

User Screen