The GridBee Framework
For more general information please visit our main website webcomputing.iit.bme.hu
Altough the framework is developed in a general fashion using modules to communicate with specific work distributors, the required functionality was derived from BOINC. Because of its important role in the world of distributed computing we are also developing a BOINC module for the framework as well as a BOINC web client. Throughout the development we have been using a BOINC server for testing and demonstrational purposes, which you can also try out by visiting our main website.
Using native client limits you to a single browser but lets you use more disk space and slightly more computational power. It also makes porting existing native applications much easier.
Multithreading in browsers
Firstly it allows us to do some massive computing in a worker thread while the browsers thread can run unaffected so the user interface remains responsive. Secondly this separation makes foreign code execution safer because the worker cannot access the main thread or the actual websites DOM. The worker can only communicate with the main thread through messages. Finally by creating multiple workers we can utilize all cores in a multicore system.
HTML5's Web Storage presents a tool that allows us to store user settings and checkpoint data. Web Storage provides a domain specific persistent storage in which data can be stored as key-value pairs. Storage size is between 2 and 10 MB depending on the browser implementation, which should be sufficient for storing temporary data of compute-intensive applications.
Communication between the client and work sources
Generally the same origin policy would prevent the framework from accessing work sources outside the application's own domain (client.com in the above example). For this reason the framework uses CORS connections to overcome this limitation. The servers providing worksources need to be set up for such connections by adding a certain HTTP header. You can read more about the specifics in the BOINC section.
To create these applications you need to use a handful of simple functions that signify certain stages in the life of a distributed computation. These include retrieving inputs, reporting progress, saving checkpoints or restoring checkpoints and writing results. These functions make up the workunit API. These functions are the workunit's only connection to the environment outside their thread. They don't have access to the DOM and can't call any functions outside their own namespace. This makes running workunits safe even when they are not verified.