Main Page

From Web Computing Documentation
Jump to: navigation, search


The GridBee Framework

These are the documentation pages of the GridBee web computing framework. Here you can find information about how to create JavaScript and Native Client applications that can be executed by our framework. We also provide some information about setting up a BOINC server to handle such workunits.

For more general information please visit our main website


The idea behind Web Computing is to make distributed computing accessible to as many people as possible. Browsers today have powerful and highly optimized JavaScript engines that in many cases are capable of providing computing capabilities comparable to native solutions.

The Web Computing framework is a JavaScript library that provides client functionality required by distributed computing solutions. Web applications based on Web Computing are capable of requesting jobs from a number of work sources, downloading and executing them, uploading the results and handling various messages. All within a single browser not requiring any additional plugins. Such web applications can be conventional clients like the BOINC client except they will run in a browser, or they can be seamlessly integrated into any website that wants to offer the users the chance to participate in volunteer computing projects.

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.


The framework implements all functions required to participate in grids based on BOINC. Web applications using the framework could connect to the same BOINC servers that are already managing numerous popular projects like SETI@home. These projects already contain jobs intended for different platforms. Currently the framework can download jobs written for the javascript platform, but later on Flash or Java solutions might be used as well. The web application can be hosted on any server and once its downloaded into our browser it can connect to multiple work sources.



Currently we use a BOINC server to distribute work to clients. For that purpose we are developing a BOINC module. You can see its classes here.

The framework is written in HaXe, a high-level programming language offering feature rich development tools. The HaXe code is then compiled to JavaScript. Currently the stable versions of Firefox and Chrome are fully supported browsers. The core functions has been successfully tested on Internet Explorer 10 Platform Preview 2. You can see a list of classes here. The framework relies on the elements of the HTML5 standard and Web Workers.

Currently jobs written in JavaScript and Native Client are supported. JavaScript jobs have the advantage that a single browser without any additional plugins is capable of handling them. Thanks to the continuous development of the JavaScript engines Chrome is now capable of executing calculations with a performance comparable to native solutions. Though a little slower Firefox is also a potent contender in executing calculations written in JavaScript.

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

Web Workers offers a very limited form of multithreaded JavaScript code execution that serves three main purposes in the framework.

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.

Unlike cookies the Web Storage content is not sent during each HTTP request thus it won't introduce an overhead to the communication. Its contents can be read using JavaScript functions and handled according to actual needs.

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 ( 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.

Developing distributed applications in JavaScript

The Web Computing framework enables browsers to participate in distributed computing projects. These projects contain executables and input data. The framework downloads the executables and runs them with the input data, then uploads the output data. The executable itself is a JavaScript code file, which is executed on a separate worker thread. Using BOINC terminology this executable is called the application of the distributed computing project.

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.

You can read more about this in the main article. We also have a guide about enabling a BOINC server to handle JavaScript workunits.

Personal tools